Re: [PATCH 10/10] cpufreq: dt: Add support for r8a7744
On 11-09-18, 11:12, Biju Das wrote:
> Add the compatible strings for supporting the generic cpufreq driver on
> the Renesas RZ/G1N (R8A7744) SoC.
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index fe14c57..805f8a0 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -58,6 +58,7 @@ static const struct of_device_id whitelist[] __initconst = {
> { .compatible = "renesas,r8a73a4", },
> { .compatible = "renesas,r8a7740", },
> { .compatible = "renesas,r8a7743", },
> + { .compatible = "renesas,r8a7744", },
> { .compatible = "renesas,r8a7745", },
> { .compatible = "renesas,r8a7778", },
> { .compatible = "renesas,r8a7779", },
Acked-by: Viresh Kumar
--
viresh
RE: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration
On Tuesday, September 11, 2018 1, Rob Herring wrote: > Well before we get to initcalls, the kernel calls the arch specific > time_init() which (on ARM) calls of_clk_init (for all the reasons > above) and then timer_probe(). When timer_probe returns, it is > expected that you have setup a clocksource and clockevent. If you > haven't, then at some point before we get to initcalls we should hang > because we're not getting any timer interrupts and time is not > advancing. What I get now is: [0.00] timer_probe: no matching timers found ... ... [0.00] clocksource: jiffies: mask: 0x max_cycles: 0x, max_idle_ns: 1911260446275 ns ... ... But then later on in boot, I'll get (with my subsys_initcall timer fix) ... ... [0.00] SCSI subsystem initialized [0.00] usbcore: registered new interface driver usbfs [0.00] usbcore: registered new interface driver hub [0.00] usbcore: registered new device driver usb [0.00] clocksource: ostm: mask: 0x max_cycles: 0x, max_idle_ns: 28958491609 ns [0.000619] sched_clock: 32 bits at 66MHz, resolution 15ns, wraps every 32537631224ns [0.008599] ostm: used for clocksource [0.018926] ostm: used for clock events [0.19] clocksource: Switched to clocksource ostm [0.821474] NET: Registered protocol family 2 [0.840624] tcp_listen_portaddr_hash hash table entries: 512 (order: 0, 4096 bytes) [0.850549] TCP established hash table entries: 1024 (order: 0, 4096 bytes) ... ... > Maybe you > just get lucky and it works as long as no thread blocks (e.g. on a > msleep). You're right. If I put in a msleep() before my timer is up and running, it hangs. As far as I can tell, nothing before device_initcall seems to call anything like msleep. > If things changed and you can setup a timer in an initcall, > then why are folks still trying to do things like early platform > drivers. Regular drivers would work and we should be able to > completely remove CLK_OF_DECLARE and TIMER_OF_DECLARE. I wonder if the reason is because you can't assign a priority to your driver when you declare it with xxx_initcall( ). So, your driver ends up in the same table as all the other drivers and you are not guaranteed the order in which they probe. So, the answer was to make a NEW table and register it using TIMER_OF_DECLARE and CLOCK_OF_DECLARE. I wonder they just didn't make a clock_initcall() and timer_initcall() instead. Chris
Re: [PATCH] arm64: dts: renesas: r8a779{7|8}0: add TMU support
Hello!
On 09/11/2018 04:36 PM, Simon Horman 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)
>>
>>There are only 3 channels per TMU according to the beginning of the TMU
>> chapter.
>>
>>> 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.
>>
>>Right!
>>
+ 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) ?
>>
>>I don't think it should be pesent in either place, and I thought I had
>> removed
>> the 4th IRQ from every node before posting... :-/
>>
>>> As per my note above, the documentation seems inconsistent here.
>>
>>Yes.
>
> Lets go with no 4th IRQ anywhere :)
After having studied the manual, 4th IRQ might have sometging to do with the
input capture channel capability which uses an extra IRQ output.
> Could you send an updated patch?
Sure. I'll verify and repost.
[...]
MBR, Sergei
Re: [PATCH] dt-bindings: timer: renesas: tmu: document R8A779{7|8}0 bindings
On 09/10/2018 05:24 PM, Geert Uytterhoeven 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?
The only difference between TMUs is the input capture capability on the 3rd
channel in each TMU -- that includes TCPR register and extra interrupt output
TICPI (perhaps has to do with 4th TMU IRQ?). The driver is blissfully unaware
of this extra capability. :-)
> In addition, the V3H TMU seems to differ from the TMU in other R-Car Gen3
> variants?
Yes, but they only differ in the number of channels capable of input
capture.
> How is this handled?
Nohow. And I'm not sure we should care about this difference...
> Gr{oetje,eeting}s,
>
> Geert
MBR, Sergei
Re: [PATCH 1/2] clocksource/drivers/ostm: Delay driver registration
On Mon, Sep 10, 2018 at 12:20 PM Chris Brandt wrote: > > 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. Yes, I read the thread and understand all of this part. Well before we get to initcalls, the kernel calls the arch specific time_init() which (on ARM) calls of_clk_init (for all the reasons above) and then timer_probe(). When timer_probe returns, it is expected that you have setup a clocksource and clockevent. If you haven't, then at some point before we get to initcalls we should hang because we're not getting any timer interrupts and time is not advancing. At least that's how it used to be and maybe something has changed (It's been a while since I've looked at this area). Maybe you just get lucky and it works as long as no thread blocks (e.g. on a msleep). If things changed and you can setup a timer in an initcall, then why are folks still trying to do things like early platform drivers. Regular drivers would work and we should be able to completely remove CLK_OF_DECLARE and TIMER_OF_DECLARE. Rob
[PATCH] arm64: dts: renesas: Remove unneeded status from thermal nodes
The thermal device is supposed to be always enabled. As the default
value of the status property is "okay", there is no need to make this
explicit in SoC-specific .dtsi files where no override is involved.
Signed-off-by: Geert Uytterhoeven
---
arch/arm64/boot/dts/renesas/r8a774a1.dtsi | 1 -
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 1 -
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 1 -
arch/arm64/boot/dts/renesas/r8a77965.dtsi | 1 -
4 files changed, 4 deletions(-)
diff --git a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
index 046fc937da1441dc..012cbb64246ec144 100644
--- a/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a774a1.dtsi
@@ -358,7 +358,6 @@
power-domains = < 32>;
resets = < 522>;
#thermal-sensor-cells = <1>;
- status = "okay";
};
intc_ex: interrupt-controller@e61c {
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index 0c6d8859cae397c9..c74ef669a354d68e 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -455,7 +455,6 @@
power-domains = < R8A7795_PD_ALWAYS_ON>;
resets = < 522>;
#thermal-sensor-cells = <1>;
- status = "okay";
};
intc_ex: interrupt-controller@e61c {
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 93a76109882c9fe7..303504f3a5be4158 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -434,7 +434,6 @@
power-domains = < R8A7796_PD_ALWAYS_ON>;
resets = < 522>;
#thermal-sensor-cells = <1>;
- status = "okay";
};
intc_ex: interrupt-controller@e61c {
diff --git a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
index 77fb909cc83985c5..22dca901182e577c 100644
--- a/arch/arm64/boot/dts/renesas/r8a77965.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a77965.dtsi
@@ -350,7 +350,6 @@
power-domains = < R8A77965_PD_ALWAYS_ON>;
resets = < 522>;
#thermal-sensor-cells = <1>;
- status = "okay";
};
intc_ex: interrupt-controller@e61c {
--
2.17.1
Re: [PATCH] arm64: dts: renesas: r8a779{7|8}0: add TMU support
On Tue, Sep 11, 2018 at 3:36 PM Simon Horman wrote:
> On Mon, Sep 10, 2018 at 03:04:56PM +0300, Sergei Shtylyov wrote:
> > On 09/10/2018 12:23 PM, Simon Horman 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
> Lets go with no 4th IRQ anywhere :)
> Could you send an updated patch?
Please consider my comments on the bindings first:
https://patchwork.kernel.org/patch/10592517/
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-drivers-2018-09-11-v4.19-rc3
I have pushed renesas-drivers-2018-09-11-v4.19-rc3 to
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git
This tree is meant to ease development of platform support and drivers
for Renesas ARM SoCs. It is created by merging (a) the for-next branches
of various subsystem trees and (b) branches with driver code submitted
or planned for submission to maintainers into the development branch of
Simon Horman's renesas.git tree.
Today's version is based on renesas-devel-20180910-v4.19-rc3.
Included branches with driver code:
- clk-renesas
- sh-pfc
- git://linuxtv.org/pinchartl/media.git#drm-du-iommu-v1-20171115
- git://git.ragnatech.se/linux#for-renesas-drivers
-
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#tags/vsp1/du/interlaced/v6
-
git://git.kernel.org/pub/scm/linux/kernel/git/kbingham/rcar.git#gmsl/for-renesas-drivers
Included fixes:
- Revert "serial: sh-sci: Remove SCIx_RZ_SCIFA_REGTYPE"
- Revert "serial: sh-sci: Allow for compressed SCIF address"
- [LOCAL] arm64: defconfig: Update renesas_defconfig
Included subsystem trees:
- git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git#linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux.git#clk-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git#for-next
- git://git.infradead.org/users/dedekind/l2-mtd-2.6.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git#tty-next
- git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#i2c/for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git#usb-next
- git://git.freedesktop.org/git/drm/drm.git#drm-next
- git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
- git://linuxtv.org/media_tree.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/thierry.reding/linux-pwm.git#for-next
- git://git.linaro.org/people/daniel.lezcano/linux.git#clockevents/next
- git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git#testing/next
- git://git.infradead.org/users/vkoul/slave-dma.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git#staging-next
- git://git.armlinux.org.uk/~rmk/linux-arm.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap.git#for-next
- git://git.infradead.org/users/jcooper/linux.git#irqchip/for-next
- git://github.com/bzolnier/linux.git#fbdev-for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
-
git://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-power-supply.git#for-next
- git://www.linux-watchdog.org/linux-watchdog-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git#for-next/core
- git://anongit.freedesktop.org/drm/drm-misc#for-linux-next
- git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git#next
-
git://git.kernel.org/pub/scm/linux/kernel/git/evalenti/linux-soc-thermal.git#next
- git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git#for-mfd-next
- git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git#for-next
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: [RFC PATCH] mmc: sdhi: sys_dmac: check for all Gen3 types when whitelisting
On Tue, Sep 11, 2018 at 03:29:14PM +0200, Ulf Hansson wrote:
> On 11 September 2018 at 15:06, Wolfram Sang wrote:
> > From: Wolfram Sang
> >
> > Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
> > Signed-off-by: Wolfram Sang
> > ---
> >
> > So, adding HS400 support broke the detection here. I suggest we discuss
> > internally, if this kind of white listing is still needed, at all. Until
> > then, this patch makes things work again on H3 and M3-W.
>
> As this is tagged "RFC PATCH", does it mean that you want the
> discussion to happen before I apply this for fixes?
Yes, exactly. This is more "to talk over code".
Thanks!
signature.asc
Description: PGP signature
Re: [PATCH 5/5] arm64: dts: renesas: r8a774a1: Add VIN and CSI-2 nodes
On Mon, Sep 10, 2018 at 03:31:18PM +0100, Biju Das wrote: > Add VIN and CSI-2 nodes to RZ/G2M SoC dtsi. > > Signed-off-by: Biju Das > Reviewed-by: Fabrizio Castro Thanks, I would value a review of this entire series before I apply this patch.
Re: [PATCH 3/3] soc: renesas: Identify RZ/G2E
On Mon, Sep 10, 2018 at 04:36:14PM +0200, Geert Uytterhoeven wrote: > 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 Thanks, applied for v4.20.
Re: [PATCH 2/3] arm64: Add Renesas R8A774C0 support
On Mon, Sep 10, 2018 at 04:34:45PM +0200, Geert Uytterhoeven wrote: > 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 Thanks, applied.
Re: [PATCH 1/3] dt-bindings: arm: Document RZ/G2E SoC DT bindings
On Mon, Sep 10, 2018 at 04:34:14PM +0200, Geert Uytterhoeven wrote: > 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 Thanks, applied for v4.20.
Re: [PATCH] soc: renesas: convert to SPDX identifiers
On Mon, Sep 10, 2018 at 04:11:48PM +0200, Geert Uytterhoeven wrote: > 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 Thanks, applied for v4.20.
Re: [PATCH] ARM: shmobile: convert to SPDX identifiers
On Mon, Sep 10, 2018 at 03:12:36PM +0200, Geert Uytterhoeven wrote: > 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 Thanks, applied for v4.20.
Re: [PATCH] pinctrl: sh-pfc: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 02:13:29AM +, 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] arm64: dts: renesas: r8a779{7|8}0: add TMU support
On Mon, Sep 10, 2018 at 03:04:56PM +0300, Sergei Shtylyov wrote:
> Hello!
>
> On 09/10/2018 12:23 PM, Simon Horman 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)
>
>There are only 3 channels per TMU according to the beginning of the TMU
> chapter.
>
> > 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.
>
>Right!
>
> >> + 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) ?
>
>I don't think it should be pesent in either place, and I thought I had
> removed
> the 4th IRQ from every node before posting... :-/
>
> > As per my note above, the documentation seems inconsistent here.
>
>Yes.
Lets go with no 4th IRQ anywhere :)
Could you send an updated patch?
>
> >> + 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";
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.
>
> 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: [RFC PATCH] mmc: sdhi: sys_dmac: check for all Gen3 types when whitelisting
On 11 September 2018 at 15:06, Wolfram Sang wrote:
> From: Wolfram Sang
>
> Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
> Signed-off-by: Wolfram Sang
> ---
>
> So, adding HS400 support broke the detection here. I suggest we discuss
> internally, if this kind of white listing is still needed, at all. Until
> then, this patch makes things work again on H3 and M3-W.
As this is tagged "RFC PATCH", does it mean that you want the
discussion to happen before I apply this for fixes?
Kind regards
Uffe
>
> drivers/mmc/host/renesas_sdhi_sys_dmac.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> index f5fcbb5dc8cd..f027f66fe0c1 100644
> --- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> +++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
> @@ -495,7 +495,8 @@ static const struct soc_device_attribute
> gen3_soc_whitelist[] = {
>
> static int renesas_sdhi_sys_dmac_probe(struct platform_device *pdev)
> {
> - if (of_device_get_match_data(>dev) == _rcar_gen3_compatible
> &&
> + if ((of_device_get_match_data(>dev) == _rcar_gen3_compatible
> ||
> + of_device_get_match_data(>dev) ==
> _rcar_r8a7795_compatible) &&
> !soc_device_match(gen3_soc_whitelist))
> return -ENODEV;
>
> --
> 2.18.0
>
Re: [PATCH] watchdog: rza_wdt: convert to SPDX identifiers
On Fri, Sep 07, 2018 at 02:11:17AM +, 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
[RFC PATCH] mmc: sdhi: sys_dmac: check for all Gen3 types when whitelisting
From: Wolfram Sang
Fixes: 26eb2607fa28 ("mmc: renesas_sdhi: add eMMC HS400 mode support")
Signed-off-by: Wolfram Sang
---
So, adding HS400 support broke the detection here. I suggest we discuss
internally, if this kind of white listing is still needed, at all. Until
then, this patch makes things work again on H3 and M3-W.
drivers/mmc/host/renesas_sdhi_sys_dmac.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
index f5fcbb5dc8cd..f027f66fe0c1 100644
--- a/drivers/mmc/host/renesas_sdhi_sys_dmac.c
+++ b/drivers/mmc/host/renesas_sdhi_sys_dmac.c
@@ -495,7 +495,8 @@ static const struct soc_device_attribute
gen3_soc_whitelist[] = {
static int renesas_sdhi_sys_dmac_probe(struct platform_device *pdev)
{
- if (of_device_get_match_data(>dev) == _rcar_gen3_compatible &&
+ if ((of_device_get_match_data(>dev) == _rcar_gen3_compatible ||
+ of_device_get_match_data(>dev) ==
_rcar_r8a7795_compatible) &&
!soc_device_match(gen3_soc_whitelist))
return -ENODEV;
--
2.18.0
Re: [PATCH] gpiolib: use better errno if get_direction is not available
Hi Linus,
On Sun, Jul 29, 2018 at 11:33 PM Linus Walleij wrote:
> On Wed, Jul 25, 2018 at 10:20 PM Wolfram Sang wrote:
> > > That all being said, I think this patch is still useful as is.
> >
> > Linus, do you have time to comment on this?
>
> This looks like a good solution to me.
> Reviewed-by: Linus Walleij
Any plans to apply it? drivers/gpio/gpiolib.c is your territory, I believe ;-)
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
RE: [PATCH 10/10] cpufreq: dt: Add support for r8a7744
Hi Rafael,
Thanks for the feedback.
> -Original Message-
> From: Rafael J. Wysocki
> Sent: 11 September 2018 11:59
> To: Biju Das
> Cc: Rafael J. Wysocki ; Viresh Kumar
> ; Linux PM ; Simon
> Horman ; Geert Uytterhoeven
> ; Chris Paterson
> ; Fabrizio Castro
> ; Linux-Renesas s...@vger.kernel.org>
> Subject: Re: [PATCH 10/10] cpufreq: dt: Add support for r8a7744
>
> On Tue, Sep 11, 2018 at 12:20 PM Biju Das
> wrote:
> >
> > Add the compatible strings for supporting the generic cpufreq driver
> > on the Renesas RZ/G1N (R8A7744) SoC.
> >
> > Signed-off-by: Biju Das
> > Reviewed-by: Fabrizio Castro
> > ---
> > drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> > b/drivers/cpufreq/cpufreq-dt-platdev.c
> > index fe14c57..805f8a0 100644
> > --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> > +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> > @@ -58,6 +58,7 @@ static const struct of_device_id whitelist[] __initconst
> = {
> > { .compatible = "renesas,r8a73a4", },
> > { .compatible = "renesas,r8a7740", },
> > { .compatible = "renesas,r8a7743", },
> > + { .compatible = "renesas,r8a7744", },
> > { .compatible = "renesas,r8a7745", },
> > { .compatible = "renesas,r8a7778", },
> > { .compatible = "renesas,r8a7779", },
> > --
>
> Since this is the last patch in a series of 10, do you want me to apply it or
> should it go in along with the rest?
Please apply the patch. Already binding patch is available with cfb9f93437eb
("ARM: shmobile: Document RZ/G1N SoC DT binding").
Regards,
Biju
Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End,
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered
No. 04586709.
Re: [PATCH 10/10] cpufreq: dt: Add support for r8a7744
On Tue, Sep 11, 2018 at 12:20 PM Biju Das wrote:
>
> Add the compatible strings for supporting the generic cpufreq driver on
> the Renesas RZ/G1N (R8A7744) SoC.
>
> Signed-off-by: Biju Das
> Reviewed-by: Fabrizio Castro
> ---
> drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
> b/drivers/cpufreq/cpufreq-dt-platdev.c
> index fe14c57..805f8a0 100644
> --- a/drivers/cpufreq/cpufreq-dt-platdev.c
> +++ b/drivers/cpufreq/cpufreq-dt-platdev.c
> @@ -58,6 +58,7 @@ static const struct of_device_id whitelist[] __initconst = {
> { .compatible = "renesas,r8a73a4", },
> { .compatible = "renesas,r8a7740", },
> { .compatible = "renesas,r8a7743", },
> + { .compatible = "renesas,r8a7744", },
> { .compatible = "renesas,r8a7745", },
> { .compatible = "renesas,r8a7778", },
> { .compatible = "renesas,r8a7779", },
> --
Since this is the last patch in a series of 10, do you want me to
apply it or should it go in along with the rest?
Thanks,
Rafael
[PATCH 0/2] Add RZ/G1N PFC driver.
This patch series aims to add support for RZ/G1N (R8A7744) PFC driver. RZ/G1N SoC is similar to RZ/G1M and R-Car Gen2 M2-W/M2-N SoC. This patchset is based on renesas-devel-20180906-v4.19-rc2. Biju Das (2): dt-bindings: pinctrl: sh-pfc: Document r8a7744 PFC support pinctrl: sh-pfc: r8a7791: Add r8a7744 support .../bindings/pinctrl/renesas,pfc-pinctrl.txt | 1 + drivers/pinctrl/sh-pfc/Kconfig | 5 + drivers/pinctrl/sh-pfc/Makefile| 1 + drivers/pinctrl/sh-pfc/core.c | 6 ++ drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 22 ++ drivers/pinctrl/sh-pfc/sh_pfc.h| 1 + 6 files changed, 36 insertions(+) -- 2.7.4
[PATCH 2/2] pinctrl: sh-pfc: r8a7791: Add r8a7744 support
Renesas RZ/G1N (R8A7744) is pin compatible with R-Car M2-W/N (R8A7791/3)
and RZ/G1M.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
drivers/pinctrl/sh-pfc/Kconfig | 5 +
drivers/pinctrl/sh-pfc/Makefile | 1 +
drivers/pinctrl/sh-pfc/core.c| 6 ++
drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 22 ++
drivers/pinctrl/sh-pfc/sh_pfc.h | 1 +
5 files changed, 35 insertions(+)
diff --git a/drivers/pinctrl/sh-pfc/Kconfig b/drivers/pinctrl/sh-pfc/Kconfig
index 6a7254c..5fad61c 100644
--- a/drivers/pinctrl/sh-pfc/Kconfig
+++ b/drivers/pinctrl/sh-pfc/Kconfig
@@ -39,6 +39,11 @@ config PINCTRL_PFC_R8A7743
depends on ARCH_R8A7743
select PINCTRL_SH_PFC
+config PINCTRL_PFC_R8A7744
+ def_bool y
+ depends on ARCH_R8A7744
+ select PINCTRL_SH_PFC
+
config PINCTRL_PFC_R8A7745
def_bool y
depends on ARCH_R8A7745
diff --git a/drivers/pinctrl/sh-pfc/Makefile b/drivers/pinctrl/sh-pfc/Makefile
index 9510a48..b14cf6a 100644
--- a/drivers/pinctrl/sh-pfc/Makefile
+++ b/drivers/pinctrl/sh-pfc/Makefile
@@ -5,6 +5,7 @@ obj-$(CONFIG_PINCTRL_PFC_EMEV2) += pfc-emev2.o
obj-$(CONFIG_PINCTRL_PFC_R8A73A4) += pfc-r8a73a4.o
obj-$(CONFIG_PINCTRL_PFC_R8A7740) += pfc-r8a7740.o
obj-$(CONFIG_PINCTRL_PFC_R8A7743) += pfc-r8a7791.o
+obj-$(CONFIG_PINCTRL_PFC_R8A7744) += pfc-r8a7791.o
obj-$(CONFIG_PINCTRL_PFC_R8A7745) += pfc-r8a7794.o
obj-$(CONFIG_PINCTRL_PFC_R8A77470) += pfc-r8a77470.o
obj-$(CONFIG_PINCTRL_PFC_R8A774A1) += pfc-r8a7796.o
diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 0122471..74c533a 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -497,6 +497,12 @@ static const struct of_device_id sh_pfc_of_table[] = {
.data = _pinmux_info,
},
#endif
+#ifdef CONFIG_PINCTRL_PFC_R8A7744
+ {
+ .compatible = "renesas,pfc-r8a7744",
+ .data = _pinmux_info,
+ },
+#endif
#ifdef CONFIG_PINCTRL_PFC_R8A7745
{
.compatible = "renesas,pfc-r8a7745",
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
index 5811784..0371ef1 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
@@ -6634,6 +6634,28 @@ const struct sh_pfc_soc_info r8a7743_pinmux_info = {
};
#endif
+#ifdef CONFIG_PINCTRL_PFC_R8A7744
+const struct sh_pfc_soc_info r8a7744_pinmux_info = {
+ .name = "r8a77440_pfc",
+ .ops = _pinmux_ops,
+ .unlock_reg = 0xe606, /* PMMR */
+
+ .function = { PINMUX_FUNCTION_BEGIN, PINMUX_FUNCTION_END },
+
+ .pins = pinmux_pins,
+ .nr_pins = ARRAY_SIZE(pinmux_pins),
+ .groups = pinmux_groups.common,
+ .nr_groups = ARRAY_SIZE(pinmux_groups.common),
+ .functions = pinmux_functions.common,
+ .nr_functions = ARRAY_SIZE(pinmux_functions.common),
+
+ .cfg_regs = pinmux_config_regs,
+
+ .pinmux_data = pinmux_data,
+ .pinmux_data_size = ARRAY_SIZE(pinmux_data),
+};
+#endif
+
#ifdef CONFIG_PINCTRL_PFC_R8A7791
const struct sh_pfc_soc_info r8a7791_pinmux_info = {
.name = "r8a77910_pfc",
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 1d491d1..353f4af 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -273,6 +273,7 @@ extern const struct sh_pfc_soc_info emev2_pinmux_info;
extern const struct sh_pfc_soc_info r8a73a4_pinmux_info;
extern const struct sh_pfc_soc_info r8a7740_pinmux_info;
extern const struct sh_pfc_soc_info r8a7743_pinmux_info;
+extern const struct sh_pfc_soc_info r8a7744_pinmux_info;
extern const struct sh_pfc_soc_info r8a7745_pinmux_info;
extern const struct sh_pfc_soc_info r8a77470_pinmux_info;
extern const struct sh_pfc_soc_info r8a774a1_pinmux_info;
--
2.7.4
Re: [PATCH] pinctrl: rza1: 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
[PATCH 10/10] cpufreq: dt: Add support for r8a7744
Add the compatible strings for supporting the generic cpufreq driver on
the Renesas RZ/G1N (R8A7744) SoC.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
drivers/cpufreq/cpufreq-dt-platdev.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cpufreq/cpufreq-dt-platdev.c
b/drivers/cpufreq/cpufreq-dt-platdev.c
index fe14c57..805f8a0 100644
--- a/drivers/cpufreq/cpufreq-dt-platdev.c
+++ b/drivers/cpufreq/cpufreq-dt-platdev.c
@@ -58,6 +58,7 @@ static const struct of_device_id whitelist[] __initconst = {
{ .compatible = "renesas,r8a73a4", },
{ .compatible = "renesas,r8a7740", },
{ .compatible = "renesas,r8a7743", },
+ { .compatible = "renesas,r8a7744", },
{ .compatible = "renesas,r8a7745", },
{ .compatible = "renesas,r8a7778", },
{ .compatible = "renesas,r8a7779", },
--
2.7.4
[PATCH 05/10] soc: renesas: rcar-rst: Add support for RZ/G1N
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
drivers/soc/renesas/rcar-rst.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/soc/renesas/rcar-rst.c b/drivers/soc/renesas/rcar-rst.c
index a447873..1e11776 100644
--- a/drivers/soc/renesas/rcar-rst.c
+++ b/drivers/soc/renesas/rcar-rst.c
@@ -43,6 +43,7 @@ static const struct rst_config rcar_rst_gen3 __initconst = {
static const struct of_device_id rcar_rst_matches[] __initconst = {
/* RZ/G1 is handled like R-Car Gen2 */
{ .compatible = "renesas,r8a7743-rst", .data = _rst_gen2 },
+ { .compatible = "renesas,r8a7744-rst", .data = _rst_gen2 },
{ .compatible = "renesas,r8a7745-rst", .data = _rst_gen2 },
{ .compatible = "renesas,r8a77470-rst", .data = _rst_gen2 },
/* RZ/G2 is handled like R-Car Gen3 */
--
2.7.4
[PATCH 09/10] ARM: shmobile: r8a7744: Basic SoC support
Add minimal support for the RZ/G1N (R8A7744) SoC.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
arch/arm/mach-shmobile/Kconfig | 5 +
arch/arm/mach-shmobile/setup-rcar-gen2.c | 2 ++
2 files changed, 7 insertions(+)
diff --git a/arch/arm/mach-shmobile/Kconfig b/arch/arm/mach-shmobile/Kconfig
index 94e9431..34aedd2 100644
--- a/arch/arm/mach-shmobile/Kconfig
+++ b/arch/arm/mach-shmobile/Kconfig
@@ -78,6 +78,11 @@ config ARCH_R8A7743
select ARCH_RCAR_GEN2
select ARM_ERRATA_798181 if SMP
+config ARCH_R8A7744
+ bool "RZ/G1N (R8A77440)"
+ select ARCH_RCAR_GEN2
+ select ARM_ERRATA_798181 if SMP
+
config ARCH_R8A7745
bool "RZ/G1E (R8A77450)"
select ARCH_RCAR_GEN2
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c
b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index 013acc9..eea60b2 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -25,6 +25,7 @@
static const struct of_device_id cpg_matches[] __initconst = {
{ .compatible = "renesas,rcar-gen2-cpg-clocks", },
{ .compatible = "renesas,r8a7743-cpg-mssr", .data = "extal" },
+ { .compatible = "renesas,r8a7744-cpg-mssr", .data = "extal" },
{ .compatible = "renesas,r8a7790-cpg-mssr", .data = "extal" },
{ .compatible = "renesas,r8a7791-cpg-mssr", .data = "extal" },
{ .compatible = "renesas,r8a7793-cpg-mssr", .data = "extal" },
@@ -193,6 +194,7 @@ MACHINE_END
static const char * const rz_g1_boards_compat_dt[] __initconst = {
"renesas,r8a7743",
+ "renesas,r8a7744",
"renesas,r8a7745",
"renesas,r8a77470",
NULL,
--
2.7.4
[PATCH 02/10] dt-bindings: power: rcar-sysc: Add r8a7744 power domain index macros
Add power domain indices for RZ/G1N (R8A7744) SoC. Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro --- include/dt-bindings/power/r8a7744-sysc.h | 24 1 file changed, 24 insertions(+) create mode 100644 include/dt-bindings/power/r8a7744-sysc.h diff --git a/include/dt-bindings/power/r8a7744-sysc.h b/include/dt-bindings/power/r8a7744-sysc.h new file mode 100644 index 000..8b65297 --- /dev/null +++ b/include/dt-bindings/power/r8a7744-sysc.h @@ -0,0 +1,24 @@ +/* SPDX-License-Identifier: GPL-2.0 + * + * Copyright (C) 2018 Renesas Electronics Corp. + */ +#ifndef __DT_BINDINGS_POWER_R8A7744_SYSC_H__ +#define __DT_BINDINGS_POWER_R8A7744_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) + * + * Note that RZ/G1N is identical to RZ/G2M w.r.t. power domains. + */ + +#define R8A7744_PD_CA15_CPU00 +#define R8A7744_PD_CA15_CPU11 +#define R8A7744_PD_CA15_SCU12 +#define R8A7744_PD_SGX 20 + +/* Always-on power area */ +#define R8A7744_PD_ALWAYS_ON 32 + +#endif /* __DT_BINDINGS_POWER_R8A7744_SYSC_H__ */ -- 2.7.4
[PATCH 03/10] soc: renesas: rcar-sysc: Add r8a7744 support
Add support for RZ/G1N (R8A7744) SoC power areas to the R-Car SYSC driver.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
drivers/soc/renesas/Kconfig | 2 +-
drivers/soc/renesas/rcar-sysc.c | 2 ++
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/soc/renesas/Kconfig b/drivers/soc/renesas/Kconfig
index 00d4c9d..a3a34d2 100644
--- a/drivers/soc/renesas/Kconfig
+++ b/drivers/soc/renesas/Kconfig
@@ -6,7 +6,7 @@ config SOC_RENESAS
ARCH_R8A774A1 || ARCH_R8A7795 || ARCH_R8A7796 || \
ARCH_R8A77965 || ARCH_R8A77970 || ARCH_R8A77980 || \
ARCH_R8A77990 || ARCH_R8A77995
- select SYSC_R8A7743 if ARCH_R8A7743
+ select SYSC_R8A7743 if ARCH_R8A7743 || ARCH_R8A7744
select SYSC_R8A7745 if ARCH_R8A7745
select SYSC_R8A77470 if ARCH_R8A77470
select SYSC_R8A774A1 if ARCH_R8A774A1
diff --git a/drivers/soc/renesas/rcar-sysc.c b/drivers/soc/renesas/rcar-sysc.c
index fe32f7a..4d8eee4 100644
--- a/drivers/soc/renesas/rcar-sysc.c
+++ b/drivers/soc/renesas/rcar-sysc.c
@@ -268,6 +268,8 @@ static int __init rcar_sysc_pd_setup(struct rcar_sysc_pd
*pd)
static const struct of_device_id rcar_sysc_matches[] __initconst = {
#ifdef CONFIG_SYSC_R8A7743
{ .compatible = "renesas,r8a7743-sysc", .data = _sysc_info },
+ /* RZ/G1N is identical to RZ/G2M w.r.t. power domains. */
+ { .compatible = "renesas,r8a7744-sysc", .data = _sysc_info },
#endif
#ifdef CONFIG_SYSC_R8A7745
{ .compatible = "renesas,r8a7745-sysc", .data = _sysc_info },
--
2.7.4
[PATCH 04/10] dt-bindings: reset: rcar-rst: Document r8a7744 reset module
Document bindings for the RZ/G1N (R8A7744) reset module. Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro --- 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..d0edd4677 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rst.txt +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt @@ -16,6 +16,7 @@ Required properties: - "renesas,-rst" for R-Car Gen2 and Gen3, and RZ/G Examples with soctypes are: - "renesas,r8a7743-rst" (RZ/G1M) + - "renesas,r8a7744-rst" (RZ/G1N) - "renesas,r8a7745-rst" (RZ/G1E) - "renesas,r8a77470-rst" (RZ/G1C) - "renesas,r8a774a1-rst" (RZ/G2M) -- 2.7.4
[PATCH 06/10] dt-bindings: clock: renesas: cpg-mssr: Document r8a7744 binding
Add binding documentation for the RZ/G1N (R8A7744) Clock Pulse Generator driver. Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro --- Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt index 42d0f83..1b8d484 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-mssr.txt @@ -14,6 +14,7 @@ They provide the following functionalities: Required Properties: - compatible: Must be one of: - "renesas,r8a7743-cpg-mssr" for the r8a7743 SoC (RZ/G1M) + - "renesas,r8a7744-cpg-mssr" for the r8a7744 SoC (RZ/G1N) - "renesas,r8a7745-cpg-mssr" for the r8a7745 SoC (RZ/G1E) - "renesas,r8a77470-cpg-mssr" for the r8a77470 SoC (RZ/G1C) - "renesas,r8a774a1-cpg-mssr" for the r8a774a1 SoC (RZ/G2M) @@ -36,12 +37,12 @@ Required Properties: - clocks: References to external parent clocks, one entry for each entry in clock-names - clock-names: List of external parent clock names. Valid names are: - - "extal" (r8a7743, r8a7745, r8a77470, r8a774a1, r8a7790, r8a7791, -r8a7792, r8a7793, r8a7794, r8a7795, r8a7796, r8a77965, -r8a77970, r8a77980, r8a77990, r8a77995) + - "extal" (r8a7743, r8a7744, r8a7745, r8a77470, r8a774a1, r8a7790, +r8a7791, r8a7792, r8a7793, r8a7794, r8a7795, r8a7796, +r8a77965, r8a77970, r8a77980, r8a77990, r8a77995) - "extalr" (r8a774a1, r8a7795, r8a7796, r8a77965, r8a77970, r8a77980) - - "usb_extal" (r8a7743, r8a7745, r8a77470, r8a7790, r8a7791, r8a7793, -r8a7794) + - "usb_extal" (r8a7743, r8a7744, r8a7745, r8a77470, r8a7790, r8a7791, +r8a7793, r8a7794) - #clock-cells: Must be 2 - For CPG core clocks, the two clock specifier cells must be "CPG_CORE" -- 2.7.4
[PATCH 08/10] clk: renesas: r8a7743: Add r8a7744 support
Add RZ/G1N (R8A7744) Clock Pulse Generator / Module Standby and Software
Reset support.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
drivers/clk/renesas/Kconfig| 2 +-
drivers/clk/renesas/r8a7743-cpg-mssr.c | 13 -
drivers/clk/renesas/renesas-cpg-mssr.c | 5 +
3 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index fd36f18..96e714c 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -5,7 +5,7 @@ config CLK_RENESAS
select CLK_RZA1 if ARCH_R7S72100
select CLK_R8A73A4 if ARCH_R8A73A4
select CLK_R8A7740 if ARCH_R8A7740
- select CLK_R8A7743 if ARCH_R8A7743
+ select CLK_R8A7743 if ARCH_R8A7743 || ARCH_R8A7744
select CLK_R8A7745 if ARCH_R8A7745
select CLK_R8A77470 if ARCH_R8A77470
select CLK_R8A774A1 if ARCH_R8A774A1
diff --git a/drivers/clk/renesas/r8a7743-cpg-mssr.c
b/drivers/clk/renesas/r8a7743-cpg-mssr.c
index 011c170..ab994f4 100644
--- a/drivers/clk/renesas/r8a7743-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7743-cpg-mssr.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
@@ -37,7 +38,7 @@ enum clk_ids {
MOD_CLK_BASE
};
-static const struct cpg_core_clk r8a7743_core_clks[] __initconst = {
+static struct cpg_core_clk r8a7743_core_clks[] __initdata = {
/* External Clock Inputs */
DEF_INPUT("extal", CLK_EXTAL),
DEF_INPUT("usb_extal", CLK_USB_EXTAL),
@@ -238,6 +239,8 @@ static const struct rcar_gen2_cpg_pll_config
cpg_pll_configs[8] __initconst = {
static int __init r8a7743_cpg_mssr_init(struct device *dev)
{
const struct rcar_gen2_cpg_pll_config *cpg_pll_config;
+ struct device_node *np = dev->of_node;
+ unsigned int i;
u32 cpg_mode;
int error;
@@ -247,6 +250,14 @@ static int __init r8a7743_cpg_mssr_init(struct device *dev)
cpg_pll_config = _pll_configs[CPG_PLL_CONFIG_INDEX(cpg_mode)];
+ if (of_device_is_compatible(np, "renesas,r8a7744-cpg-mssr")) {
+ /* RZ/G1N uses a 1/5 divider for ZG */
+ for (i = 0; i < ARRAY_SIZE(r8a7743_core_clks); i++)
+ if (r8a7743_core_clks[i].id == R8A7743_CLK_ZG) {
+ r8a7743_core_clks[i].div = 5;
+ break;
+ }
+ }
return rcar_gen2_cpg_init(cpg_pll_config, 2, cpg_mode);
}
diff --git a/drivers/clk/renesas/renesas-cpg-mssr.c
b/drivers/clk/renesas/renesas-cpg-mssr.c
index f90b0d0..35a7a72 100644
--- a/drivers/clk/renesas/renesas-cpg-mssr.c
+++ b/drivers/clk/renesas/renesas-cpg-mssr.c
@@ -651,6 +651,11 @@ static const struct of_device_id cpg_mssr_match[] = {
.compatible = "renesas,r8a7743-cpg-mssr",
.data = _cpg_mssr_info,
},
+ /* RZ/G1N is (almost) identical to RZ/G1M w.r.t. clocks. */
+ {
+ .compatible = "renesas,r8a7744-cpg-mssr",
+ .data = _cpg_mssr_info,
+ },
#endif
#ifdef CONFIG_CLK_R8A7745
{
--
2.7.4
[PATCH 07/10] clk: renesas: Add r8a7744 CPG Core Clock Definitions
Add all RZ/G1N Clock Pulse Generator Core Clock Outputs, as listed in
Table 7.2b ("List of Clocks [RZ/G1M/N]") of the RZ/G1 Hardware User's
Manual.
Signed-off-by: Biju Das
Reviewed-by: Fabrizio Castro
---
include/dt-bindings/clock/r8a7744-cpg-mssr.h | 39
1 file changed, 39 insertions(+)
create mode 100644 include/dt-bindings/clock/r8a7744-cpg-mssr.h
diff --git a/include/dt-bindings/clock/r8a7744-cpg-mssr.h
b/include/dt-bindings/clock/r8a7744-cpg-mssr.h
new file mode 100644
index 000..2690be0
--- /dev/null
+++ b/include/dt-bindings/clock/r8a7744-cpg-mssr.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2018 Renesas Electronics Corp.
+ */
+#ifndef __DT_BINDINGS_CLOCK_R8A7744_CPG_MSSR_H__
+#define __DT_BINDINGS_CLOCK_R8A7744_CPG_MSSR_H__
+
+#include
+
+/* r8a7744 CPG Core Clocks */
+#define R8A7744_CLK_Z 0
+#define R8A7744_CLK_ZG 1
+#define R8A7744_CLK_ZTR2
+#define R8A7744_CLK_ZTRD2 3
+#define R8A7744_CLK_ZT 4
+#define R8A7744_CLK_ZX 5
+#define R8A7744_CLK_ZS 6
+#define R8A7744_CLK_HP 7
+#define R8A7744_CLK_B 9
+#define R8A7744_CLK_LB 10
+#define R8A7744_CLK_P 11
+#define R8A7744_CLK_CL 12
+#define R8A7744_CLK_M2 13
+#define R8A7744_CLK_ZB315
+#define R8A7744_CLK_ZB3D2 16
+#define R8A7744_CLK_DDR17
+#define R8A7744_CLK_SDH18
+#define R8A7744_CLK_SD019
+#define R8A7744_CLK_SD220
+#define R8A7744_CLK_SD321
+#define R8A7744_CLK_MMC0 22
+#define R8A7744_CLK_MP 23
+#define R8A7744_CLK_QSPI 26
+#define R8A7744_CLK_CP 27
+#define R8A7744_CLK_RCAN 28
+#define R8A7744_CLK_R 29
+#define R8A7744_CLK_OSC30
+
+#endif /* __DT_BINDINGS_CLOCK_R8A7744_CPG_MSSR_H__ */
--
2.7.4
[PATCH 01/10] dt-bindings: power: rcar-sysc: Document r8a7744 SYSC binding
Add binding documentation for the RZ/G1N (R8A7744) SYSC block. Signed-off-by: Biju Das Reviewed-by: Fabrizio Castro --- 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..9c3fdd8 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt @@ -8,6 +8,7 @@ and various coprocessors. Required properties: - compatible: Must contain exactly one of the following: - "renesas,r8a7743-sysc" (RZ/G1M) + - "renesas,r8a7744-sysc" (RZ/G1N) - "renesas,r8a7745-sysc" (RZ/G1E) - "renesas,r8a77470-sysc" (RZ/G1C) - "renesas,r8a774a1-sysc" (RZ/G2M) -- 2.7.4
[PATCH 00/10] Add RZ/G1N support.
This patch series aims to add support for Renesas RZ/G1N (r8a7744) SoC. RZ/G1N SoC is similar to RZ/G1M and R-Car Gen2 M2-W/M2-N SoC. This patch set is based on renesas-devel-20180906-v4.19-rc2. Biju Das (10): dt-bindings: power: rcar-sysc: Document r8a7744 SYSC binding dt-bindings: power: rcar-sysc: Add r8a7744 power domain index macros soc: renesas: rcar-sysc: Add r8a7744 support dt-bindings: reset: rcar-rst: Document r8a7744 reset module soc: renesas: rcar-rst: Add support for RZ/G1N dt-bindings: clock: renesas: cpg-mssr: Document r8a7744 binding clk: renesas: Add r8a7744 CPG Core Clock Definitions clk: renesas: r8a7743: Add r8a7744 support ARM: shmobile: r8a7744: Basic SoC support cpufreq: dt: Add support for r8a7744 .../devicetree/bindings/clock/renesas,cpg-mssr.txt | 11 +++--- .../bindings/power/renesas,rcar-sysc.txt | 1 + .../devicetree/bindings/reset/renesas,rst.txt | 1 + arch/arm/mach-shmobile/Kconfig | 5 +++ arch/arm/mach-shmobile/setup-rcar-gen2.c | 2 ++ drivers/clk/renesas/Kconfig| 2 +- drivers/clk/renesas/r8a7743-cpg-mssr.c | 13 +++- drivers/clk/renesas/renesas-cpg-mssr.c | 5 +++ drivers/cpufreq/cpufreq-dt-platdev.c | 1 + drivers/soc/renesas/Kconfig| 2 +- drivers/soc/renesas/rcar-rst.c | 1 + drivers/soc/renesas/rcar-sysc.c| 2 ++ include/dt-bindings/clock/r8a7744-cpg-mssr.h | 39 ++ include/dt-bindings/power/r8a7744-sysc.h | 24 + 14 files changed, 101 insertions(+), 8 deletions(-) create mode 100644 include/dt-bindings/clock/r8a7744-cpg-mssr.h create mode 100644 include/dt-bindings/power/r8a7744-sysc.h -- 2.7.4
Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi again,
I actually noticed I'm handling VIN4 and VIN5 un-consistently
here...
On Tue, Sep 11, 2018 at 09:44:48AM +0200, jacopo mondi wrote:
> Hi Simon,
>thanks for looking into this patch
>
> On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> > 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.
> >
>
> On R-Car E3 only pins [0-7] of VIN4 interface have an '_a' and '_b'
> options. Pins from [8-23] are "shared".
>
> We can discuss how we want this to be handled, but according to Table
> 6D.5 (pag. 383 of R-Car chip manual revision 1.00) this table is
> correct.
>
> Currently there are two open questions on this PFC patch:
> 1) This one here you reported
It does not end here, I'm sorry.
VIN4 and VIN5 are described differently, it seems to me that we have
vin4_data[0-7]_[a|b]
vin4_data[8-23]
vin4_sync
vin5_data[0-7]_[a|b]
vin5_data[8-15]_a
vin5_sync_a
So I handled it differently, as I've registered the following data groups
for VIN4
> > > + "vin4_data8_a",
> > > + "vin4_data10_a",
> > > + "vin4_data12_a",
> > > + "vin4_data16_a",
> > > + "vin4_data20_a",
> > > + "vin4_data24_a",
> > > + "vin4_data8_b",
> > > + "vin4_data10_b",
> > > + "vin4_data12_b",
> > > + "vin4_data16_b",
> > > + "vin4_data20_b",
> > > + "vin4_data24_b",
And the following ones for VIN5
> > > + "vin5_data8_a",
> > > + "vin5_data10_a",
> > > + "vin5_data12_a",
> > > + "vin5_data16_a",
> > > + "vin5_data8_b",
If I would have been doing the same as I did for VIN4, I should have
had "vin5_data10_b", "vin5_data12_b" and so on, with only the first 8
pin being different between all _a and _b groups.
I didn't do that because the VIN5 pins in the [8-15] range have a clear _a
indications, but the more I think about this, the more I think that's
a typographical mistake in the chip manual, and the VIN5 groups should
not have any _a suffix, except for the first 8 pins, where a
corresponding _b group actually exists. Or there is maybe an
explanation why VIN4 and VIN5 are different, but I don't see it right
now...
Thanks
j
> ... (see below)
>
> > > + 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),
Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi Geert,
On Tue, Sep 11, 2018 at 10:15:23AM +0200, Geert Uytterhoeven wrote:
> Hi Jacopo,
>
> On Tue, Sep 11, 2018 at 9:44 AM jacopo mondi wrote:
> > On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> > > 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.
>
> > Currently there are two open questions on this PFC patch:
>
> > 2) VIN5 synchronism signals (V/HSYNC, CLKENB, FIELD) are marked as
> >"_A" only, while VIN4 ones have not _A or _B extensions and are
> >shared between _A and _B group. The VIN5_#_A extension is an
> >indication that synchronism signals for group _B are not
> >multiplexed but active be default according to Morimoto-san, that
> >is about to confirm this with HW team. In that case, we need to
> >decide if to provide an 'vin5_sync_b' group anyway to let user
> >select it from DTS. Otherwise it won't be possible to select
> >synchronism pins for VIN5_B group (which is maybe fine if they're
> >not multiplexed at all).
>
> If the a "B" sync group exists, the pins are probably configurable as GPIOs,
> too, so we probably do need a group for them in the driver.
>
The chip manual does not report any _b group, and I don't have any E3
pin-related documentation like I have for M3-W/N
(r01uh0802ej0100-r-car-3rd-pin.pdf,
ASOM-C18-201_R-CarM3_pinfunction.xls etc etc)
How to find it out? Morimoto-san have you heard any news from HW team?
Thanks
j
> 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
signature.asc
Description: PGP signature
Re: [PATCH] dma: sh: convert to SPDX identifiers
Hi Vinod
> > > From: Kuninori Morimoto
> > >
> > > This patch updates license to use SPDX-License-Identifier
> > > instead of verbose license text.
> >
> > Thanks but the style is not consistent in files :(
> >
> > Can we use one only?
>
> Please read
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst#n69
>
> 2. Style:
>
>The SPDX license identifier is added in form of a comment. The comment
>style depends on the file type::
>
> C source: // SPDX-License-Identifier:
> C header: /* SPDX-License-Identifier: */
>
> Gr{oetje,eeting}s,
And this, too
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst#n15
GPL-1.0+ : GNU General Public License v1.0 or later
GPL-2.0+ : GNU General Public License v2.0 or later
LGPL-2.0 : GNU Library General Public License v2 only
LGPL-2.0+ : GNU Library General Public License v2 or later
LGPL-2.1 : GNU Lesser General Public License v2.1 only
LGPL-2.1+ : GNU Lesser General Public License v2.1 or later
Best regards
---
Kuninori Morimoto
Re: [PATCH] dma: sh: convert to SPDX identifiers
Hi Vinod,
On Tue, Sep 11, 2018 at 9:48 AM Vinod wrote:
> On 07-09-18, 01:58, Kuninori Morimoto wrote:
> > From: Kuninori Morimoto
> >
> > This patch updates license to use SPDX-License-Identifier
> > instead of verbose license text.
>
> Thanks but the style is not consistent in files :(
>
> Can we use one only?
Please read
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/license-rules.rst#n69
2. Style:
The SPDX license identifier is added in form of a comment. The comment
style depends on the file type::
C source: // SPDX-License-Identifier:
C header: /* SPDX-License-Identifier: */
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 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi Jacopo,
On Tue, Sep 11, 2018 at 9:44 AM jacopo mondi wrote:
> On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> > 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.
> Currently there are two open questions on this PFC patch:
> 2) VIN5 synchronism signals (V/HSYNC, CLKENB, FIELD) are marked as
>"_A" only, while VIN4 ones have not _A or _B extensions and are
>shared between _A and _B group. The VIN5_#_A extension is an
>indication that synchronism signals for group _B are not
>multiplexed but active be default according to Morimoto-san, that
>is about to confirm this with HW team. In that case, we need to
>decide if to provide an 'vin5_sync_b' group anyway to let user
>select it from DTS. Otherwise it won't be possible to select
>synchronism pins for VIN5_B group (which is maybe fine if they're
>not multiplexed at all).
If the a "B" sync group exists, the pins are probably configurable as GPIOs,
too, so we probably do need a group for them in the driver.
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] dma: sh: convert to SPDX identifiers
On 07-09-18, 01:58, Kuninori Morimoto wrote: > > From: Kuninori Morimoto > > This patch updates license to use SPDX-License-Identifier > instead of verbose license text. Thanks but the style is not consistent in files :( Can we use one only? > diff --git a/drivers/dma/sh/shdma-arm.h b/drivers/dma/sh/shdma-arm.h > index a1b0ef4..30bcfe3 100644 > --- a/drivers/dma/sh/shdma-arm.h > +++ b/drivers/dma/sh/shdma-arm.h > @@ -1,11 +1,8 @@ > -/* > +/* SPDX-License-Identifier: GPL-2.0 this is one > #ifndef SHDMA_ARM_H > diff --git a/drivers/dma/sh/shdma-base.c b/drivers/dma/sh/shdma-base.c > index 6b5626e..c51de49 100644 > --- a/drivers/dma/sh/shdma-base.c > +++ b/drivers/dma/sh/shdma-base.c > @@ -1,3 +1,4 @@ > +// SPDX-License-Identifier: GPL-2.0 different > diff --git a/drivers/dma/sh/shdma.h b/drivers/dma/sh/shdma.h > index 2c0a969..73aec72 100644 > --- a/drivers/dma/sh/shdma.h > +++ b/drivers/dma/sh/shdma.h > @@ -1,14 +1,9 @@ > -/* > +/* SPDX-License-Identifier: GPL-2.0+ this and so on.. -- ~Vinod
Re: [PATCH v2 5/8] pinctrl: sh-pfc: r8a77990: Add VIN pins, groups and functions
Hi Simon,
thanks for looking into this patch
On Mon, Sep 10, 2018 at 03:01:15PM +0200, Simon Horman wrote:
> 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.
>
On R-Car E3 only pins [0-7] of VIN4 interface have an '_a' and '_b'
options. Pins from [8-23] are "shared".
We can discuss how we want this to be handled, but according to Table
6D.5 (pag. 383 of R-Car chip manual revision 1.00) this table is
correct.
Currently there are two open questions on this PFC patch:
1) This one here you reported
... (see below)
> > + 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[] = {
> > +
