Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree
Hi Sergei,
On Tue, Jun 7, 2016 at 12:26 AM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
>> With regards to SMP. Have you checked to make sure CPU hotplug works
>> on all CPUs?
>
>How to test the CPU hotplug? I've now added the SMP support and made sure
> both CPUs are online and serve IRQs...
Off/online all CPUs:
for i in /sys/*/*/cpu/cpu[0-9]*; do echo 0 > $i/online; echo 1 >
$i/online; done
Offline all CPUs:
for i in /sys/*/*/cpu/cpu[0-9]*; do echo 0 > $i/online; done; cat
/proc/cpuinfo
Online all CPUs:
for i in /sys/*/*/cpu/cpu[0-9]*; do echo 1 > $i/online; done; cat
/proc/cpuinfo
>> And that the system behaves sanely on suspend/resume.
>
>I'd be thankful if you told me how to test that. :-)
System suspend:
echo mem > /sys/power/state
System resume: You're gonna need a "wakeup-source" in your DTS, e.g. gpio-keys.
Serial should work too, echo "enabled" to the corresponding wakeup
file in /sys first.
In case of issues, try "echo 0 > /sys/module/printk/parameters/console_suspend".
Good luck!
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 0/3] iommu/ipmmu-vmsa: Initial r8a7796 support
Hi Magnus,
On Tue, Jun 7, 2016 at 5:39 AM, Magnus Damm <magnus.d...@gmail.com> wrote:
> iommu/ipmmu-vmsa: Initial r8a7796 support
>
> [PATCH 1/3] iommu/ipmmu-vmsa: Add r8a7796 DT binding
> [PATCH 2/3] iommu/ipmmu-vmsa: Increase maximum micro-TLBS to 48
> [PATCH 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
>
> This series adds r8a7796 support to the IPMMU driver. The DT binding
> gets updated, maximum number of micro-TLBs are increased and the
> driver is adjusted to match on the new DT binding.
Thanks for your series!
For your convenience, I've queued it up in topic/r8a7796-ipmmu-v1 at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git, and
will include it in next renesas-drivers release.
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 0/9] clocksource/drivers/clksrc-of: Improve error handling
Hi Daniel,
On Wed, Jun 8, 2016 at 4:10 PM, Daniel Lezcano
<daniel.lezc...@linaro.org> wrote:
> On 06/07/2016 11:54 AM, Geert Uytterhoeven wrote:
>
> [ ... ]
>
>> in clockevents/clockevents/next breaks the boot on e.g. r8a7791/koelsch
>> (arm32) and r8a7795/salvator-x (arm64).
>>
>> Using "earlycon keep_bootcon" on koelsch (this doesn't help on arm64)
>> reveals it's stuck at:
>>
>> clocksource_probe: no matching clocksources found
>> sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every
>> 2147483647500ns
>> Calibrating delay loop...
>>
>> With the above commit reverted, it works again:
>>
>> Architected cp15 timer(s) running at 10.00MHz (virt).
>> clocksource: arch_sys_counter: mask: 0xff max_cycles:
>> 0x24e6a1710, max_idle_ns: 440795202120 ns
>> sched_clock: 56 bits at 10MHz, resolution 100ns, wraps every
>> 4398046511100ns
>> Switching to timer-based delay loop, resolution 100ns
>> Calibrating delay loop (skipped), value calculated using timer
>> frequency.. 20.00 BogoMIPS (lpj=10)
>
> I think it is fixed now and pushed on my tree. Is it possible to confirm
> your boards are working correctly again after the linux-next is updated with
> my latest changes ?
I can confirm the issue is fixed in today's clockevents/next
(52be039599e1339e).
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 v3 06/12] ARM: dts: r8a7792: initial SoC device tree
Hi Sergei,
On Wed, Jun 8, 2016 at 11:17 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> The initial R8A7792 SoC device tree including CPU cores, GIC, timer, SYSC,
> and the required clock descriptions.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>
> ---
> Changes in version 3:
Thanks for the update!
> --- /dev/null
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> @@ -0,0 +1,180 @@
> +/*
> + * Device Tree Source for the r8a7792 SoC
> + *
> + * Copyright (C) 2016 Cogent Embedded Inc.
> + *
> + * This file is licensed under the terms of the GNU General Public License
> + * version 2. This program is licensed "as is" without any warranty of any
> + * kind, whether express or implied.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +/ {
> + compatible = "renesas,r8a7792";
> + #address-cells = <2>;
> + #size-cells = <2>;
> +
> + cpus {
> + #address-cells = <1>;
> + #size-cells = <0>;
This is gonna need
enable-method = "renesas,apmu";
soon.
> + soc {
> + p_clk: p {
> + compatible = "fixed-factor-clock";
Missing TAB.
> + clocks = <_clocks R8A7792_CLK_PLL1>;
> + #clock-cells = <0>;
> + clock-div = <24>;
> + clock-mult = <1>;
> + };
> + cp_clk: cp {
> + compatible = "fixed-factor-clock";
> + clocks = <_clocks R8A7792_CLK_PLL1>;
> + #clock-cells = <0>;
> + clock-div = <3>;
48
(did you check /sys/kernel/debug/clk/clk_summary matches Table 7.2c?)
> + clock-mult = <1>;
> + };
> +
> + /* Gate clocks */
> + mstp7_clks: mstp7_clks@e615014c {
> + compatible = "renesas,r8a7792-mstp-clocks",
> +"renesas,cpg-mstp-clocks";
> + reg = <0 0xe615014c 0 4>, <0 0xe61501c4 0 4>;
> + clocks = <_clk>, <_clk>, <_clk>, <_clk>,
> +<_clk>, <_clk>;
> + #clock-cells = <1>;
> + clock-indices = <
> + R8A7792_CLK_HSCIF1 R8A7792_CLK_HSCIF0
> + R8A7792_CLK_SCIF3 R8A7792_CLK_SCIF2
> + R8A7792_CLK_SCIF1 R8A7792_CLK_SCIF0
> + >;
> + clock-output-names = "hscif1", "hscif0", "scif3",
> +"scif2", "scif1", "scif0",
> +"du1", "du0";
You forgot to drop "du1" and "du0".
> + };
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: R-Car3: PFC: Where to do the pinmux/drvctrl?
Hi Dirk,
On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
> with the R-Car3, the pinmux/drvctrl is done at 3 places:
>
> 1. ARM trusted firmware / IPL:
>
> https://github.com/renesas-rcar/meta-renesas/blob/jethro/meta-rcar-gen3/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware/0001-add-bl2-bl31-R-Car-support.patch#L8428
>
>
> 2. U-Boot:
>
> https://github.com/renesas-rcar/u-boot/blob/v2015.04/rcar-3.2.x/board/renesas/salvator-x/salvator-x.c#L116
>
>
> 3. Linux kernel
>
> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/drivers/pinctrl/sh-pfc/pfc-r8a7795.c?h=topic/gen3-latest
>
>
> Now, the issue we see is that (of course?) this is not necessarily
> consistent.
>
> Therefore: What's supposed to be the correct place to do this (once)?
IMHO the kernel should take care of making sure pinctrl is configured correctly,
independent of earlier stages in the boot process. This is the same stance as
for module clocks.
Note that if the kernel takes care of it, doing it once is not an option, as
earlier stages may need pinctrl configuration depending on boot method
(e.g. TFTP over Ethernet needs RAVB setup).
> The example is the RAVB ethernet: We found that on the Salvator-X the
> kernel's ethernet doesn't work without being initialized by U-Boot. I.e.
> without running U-Boot doing the drvctrl [1] ethernet fails in the Linux
> kernel.
This is a missing/incorrect drive strength configuration?
The pfc-r8a7795 does have support for drive strength, but only for pins that
also have GPIO capabilities. (At least some of) the RAVB pins don't seem
to be handled (e.g. DRVCTRL2).
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 2/4] clk: renesas: Add r8a7796 CPG Core Clock Definitions
Hi Dirk,
On Thu, Jun 9, 2016 at 10:31 AM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
> On 07.06.2016 10:17, Geert Uytterhoeven wrote:
>> On Tue, Jun 7, 2016 at 9:53 AM, Dirk Behme <dirk.be...@de.bosch.com>
>> wrote:
>>>
>>> I think I just want to discuss if we have a clever idea to further
>>> improve
>>> one detail. That is, if we have a clever idea to avoid the copy & paste
>>> between the family members using anything like a hierarchical way of
>>> defining the clocks in r8a779x-cpg-mssr.h.
>>>
>>>> Given the small amount of work needed to bootstrap r8a7796, I
>>>> think they still hold on their promises.
>>>
>>> Well, regarding the r8a779x-cpg-mssr.h the small amount of work needed
>>> isn't
>>> a really good argument if you are good with cp & sed for the copy & paste
>>> done ;)
>>
>> They're not really created by cp & sed, as they must match the table in
>> the
>> datasheet (the latter may have been created by copy & paste though :-)
>>
>>> What I fear we end up the way we are doing the copy & paste
>>> r8a779x-cpg-mssr.h is having 5 or 6 or even more of these files, all >
>>> 90%
>>> identical. And once you have to change anything, you either have to
>>> change
>>> all these files. Or you miss anything, ending up with subtle bugs when
>>> one
>>> SoC does behave differently than an other one.
>>
>> The point is these files are stable ABI: no single value can be changed.
>> No value can be reused. Only new values can be appended at the bottom
>> (if a newer revision of the datasheet documents more clocks than the old
>> version, which happens from time to time).
>>
>> IMHO a hierarchical way of defining the clocks has more opportunity of
>> accidentally referring to a clock that doesn't exist on a particular SoC.
>>
>> Furthermore, r8a779x-cpg-mssr.h is not a good name to be part of a DT
>> binding,
>> due to the wildcard.
>> A future SoC may will match r8a779x and even be called (R-Car
>> 3?),
>> while using a completely different CPG block.
>
> Just to give an example about what we are talking, I've done [1] below. This
> should just be an *example*, though. I'm sure that we might need a more
> clever way.
Thanks, it matches with what I had in mind what you wanted to do ;-)
> --- a/include/dt-bindings/clock/r8a7796-cpg-mssr.h
> +++ b/include/dt-bindings/clock/r8a7796-cpg-mssr.h
> +#include
> +#define R8A7796_CLK_ZB3D4 47
> +#define R8A7796_CLK_S0D2 48
> +#define R8A7796_CLK_S0D3 49
> +#define R8A7796_CLK_S0D6 50
> +#define R8A7796_CLK_S0D8 51
> +#define R8A7796_CLK_S0D12 53
This means on M3-W, clocks may have different prefixes:
- RCAR3_CLK_* if they are defined as common R-Car Gen3 clocks,
- R8A7796_CLK_* if they are defined as M3-W-specific clocks.
Not such a big issue, it that can be worked around using
#define R8A7796_CLK_Z RCAR3_CLK_Z
[...]
> +++ b/include/dt-bindings/clock/rcar3-cpg-mssr.h
> @@ -0,0 +1,63 @@
> +/*
> + * Copyright (C) 2015 Renesas Electronics Corp.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#ifndef __DT_BINDINGS_CLOCK_RCAR3_CPG_MSSR_H__
> +#define __DT_BINDINGS_CLOCK_RCAR3_CPG_MSSR_H__
> +
> +#include
> +
> +/* RCar3 CPG Core Clocks */
> +#define RCAR3_CLK_Z 0
> +#define RCAR3_CLK_Z2 1
> +#define RCAR3_CLK_ZR 2
> +#define RCAR3_CLK_ZG 3
> +#define RCAR3_CLK_ZTR 4
> +#define RCAR3_CLK_ZTRD25
While this approach allows to add SoC-specific clocks to the family-specific
base list, it does not allow to remove family-specific clocks that are not
present on unknown future species of the family.
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: R-Car3: PFC: Where to do the pinmux/drvctrl?
Hi Dirk,
On Thu, Jun 9, 2016 at 10:58 AM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
> On 09.06.2016 10:22, Geert Uytterhoeven wrote:
>> On Thu, Jun 9, 2016 at 8:56 AM, Dirk Behme <dirk.be...@de.bosch.com>
>> wrote:
>>> with the R-Car3, the pinmux/drvctrl is done at 3 places:
>>> 1. ARM trusted firmware / IPL:
>>>
>>> https://github.com/renesas-rcar/meta-renesas/blob/jethro/meta-rcar-gen3/recipes-bsp/arm-trusted-firmware/arm-trusted-firmware/0001-add-bl2-bl31-R-Car-support.patch#L8428
>>>
>>> 2. U-Boot:
>>>
>>> https://github.com/renesas-rcar/u-boot/blob/v2015.04/rcar-3.2.x/board/renesas/salvator-x/salvator-x.c#L116
>>>
>>> 3. Linux kernel
>>>
>>> https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/drivers/pinctrl/sh-pfc/pfc-r8a7795.c?h=topic/gen3-latest
>>>
>>> Now, the issue we see is that (of course?) this is not necessarily
>>> consistent.
>>>
>>> Therefore: What's supposed to be the correct place to do this (once)?
>>
>> IMHO the kernel should take care of making sure pinctrl is configured
>> correctly,
>> independent of earlier stages in the boot process.
>
> From previous discussions with kernel people I expected this answer ;)
>
> In my opinion, to be able to keep the pinctrl consistent, you have to do it
> in one place. To avoid issues like discussed below. And to be able to
> maintain it. The consequence of this "one place" would be that the main
> place is the boot loader, then. In case of the Salvator-X this would be the
> ARM trusted firmware (IPL), then.
>
> Yes, I know, kernel people see this differently, as the kernel is the only
> place they have under control. From that point of view only the kernel can
> "fix" broken or not updated boot loaders.
>
> So it depends whether you have only the kernel or everything under your
> control, including the boot loader.
>
>> Note that if the kernel takes care of it, doing it once is not an option,
>> as
>> earlier stages may need pinctrl configuration depending on boot method
>> (e.g. TFTP over Ethernet needs RAVB setup).
>
> How will the kernel handle different boards needing different pinctrl
> configuration?
>
> I.e. how is pfc-r8a7795 supposed to cover different boards?
Pinctrl for devices is described in the board's DTS (e.g.
r8a7795-salvator-x.dts).
Or in a DT overlay, if you use the EXIO connectors.
>>> The example is the RAVB ethernet: We found that on the Salvator-X the
>>> kernel's ethernet doesn't work without being initialized by U-Boot. I.e.
>>> without running U-Boot doing the drvctrl [1] ethernet fails in the Linux
>>> kernel.
>>
>> This is a missing/incorrect drive strength configuration?
>
> Yes, I think so.
>
>> The pfc-r8a7795 does have support for drive strength, but only for pins
>> that
>> also have GPIO capabilities. (At least some of) the RAVB pins don't seem
>> to be handled (e.g. DRVCTRL2).
>
> So your proposal would be to fix/correct/extend Linux kernel's pfc-r8a7795
> to correctly support the drive strength needed for the RAVB on the
> Salvator-X?
No, you need more steps.
1. Add non-GPIO drive strength support to pfc-r8a7795,
2. Describe correct RAVB pinctrl config in r8a7795-salvator-x.dts.
3. Profit!
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 v3 01/12] ARM: shmobile: r8a7792: add clock index macros
On Wed, Jun 8, 2016 at 11:04 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> Add macros usable by the device tree sources to reference the R8A7792
> clocks by index.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
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 v3 05/12] ARM: shmobile: r8a7792: add SMP support
Hi Sergei,
On Wed, Jun 8, 2016 at 11:15 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> Add R8A7792 SMP support using the shared APMU code. This SoC has 2 ARM
> Cortex-A15 CPU cores.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>
> ---
> Changes in version 3:
> - new patch.
>
> arch/arm/mach-shmobile/Makefile|1
> arch/arm/mach-shmobile/r8a7792.h |6 +++
> arch/arm/mach-shmobile/setup-r8a7792.c |2 +
> arch/arm/mach-shmobile/smp-r8a7792.c | 62
> +
> 4 files changed, 71 insertions(+)
>
> Index: renesas/arch/arm/mach-shmobile/Makefile
> ===
> --- renesas.orig/arch/arm/mach-shmobile/Makefile
> +++ renesas/arch/arm/mach-shmobile/Makefile
> @@ -35,6 +35,7 @@ smp-$(CONFIG_ARCH_SH73A0) += smp-sh73a0.
> smp-$(CONFIG_ARCH_R8A7779) += smp-r8a7779.o headsmp-scu.o platsmp-scu.o
> smp-$(CONFIG_ARCH_R8A7790) += smp-r8a7790.o
> smp-$(CONFIG_ARCH_R8A7791) += smp-r8a7791.o
> +smp-$(CONFIG_ARCH_R8A7792) += smp-r8a7792.o
> smp-$(CONFIG_ARCH_EMEV2) += smp-emev2.o headsmp-scu.o platsmp-scu.o
>
> # PM objects
> Index: renesas/arch/arm/mach-shmobile/r8a7792.h
> ===
> --- /dev/null
> +++ renesas/arch/arm/mach-shmobile/r8a7792.h
> @@ -0,0 +1,6 @@
> +#ifndef __ASM_R8A7792_H__
> +#define __ASM_R8A7792_H__
> +
> +extern const struct smp_operations r8a7792_smp_ops;
For new SMP support, you should no longer add an SoC-specific struct
smp_operations, but rely on the DT "enable-method" property, cfr.
"[PATCH v3 00/09] ARM: shmobile: APMU DT support via SMP Enable method V3"
(http://www.spinics.net/lists/linux-sh/msg45229.html).
That series will no longer apply, but I've been carrying (and rebasing) it in
my local tree for quite a while, as it was related to SYSC cleanup (avoiding
your r8a7792_ca15_scu). But unfortunately that depends on the SYSC node always
be present in DT.
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: sh-pfc: fix warnings by include core.h
Hi Linus, Ben,
On Wed, Jun 8, 2016 at 2:08 PM, Linus Walleij <linus.wall...@linaro.org> wrote:
> On Tue, Jun 7, 2016 at 7:33 PM, Ben Dooks <ben.do...@codethink.co.uk> wrote:
>
>> Fix warnings about emev2_pinmux_info and r8a7779_pinmux_info
>> by using core.h instead of sh_pfc.h in these files. This gives
>> the declarations of the two structures and removes the following
>> warnings:
>>
>> drivers/pinctrl/sh-pfc/pfc-emev2.c:1695:30: warning: symbol
>> 'emev2_pinmux_info' was not declared. Should it be static?
>> drivers/pinctrl/sh-pfc/pfc-r8a7779.c:3888:30: warning: symbol
>> 'r8a7779_pinmux_info' was not declared. Should it be static?
>>
>> Signed-off-by: Ben Dooks <ben.do...@codethink.co.uk>
Ben: Thanks for your patch!
>
> Geert/Laurent:
>
> - take a look at this patch
These are fixes for sparse warnings, and look fine to me.
However, it seems "core.h" should be included by all the remaining
drivers/pinctrl/sh-pfc/pfc-sh* files for ARCH=sh, too.
At which point I start to question: why not merge core.h with sh_pfc.h?
> - shall I apply this directly?
i could take it through sh-pfc-for-v4.8.
I expect more pfc stuff to follow soon anyway.
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 2/4] clk: renesas: Add r8a7796 CPG Core Clock Definitions
Hi Dirk,
On Tue, Jun 7, 2016 at 9:53 AM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
> I think I just want to discuss if we have a clever idea to further improve
> one detail. That is, if we have a clever idea to avoid the copy & paste
> between the family members using anything like a hierarchical way of
> defining the clocks in r8a779x-cpg-mssr.h.
>
>> Given the small amount of work needed to bootstrap r8a7796, I
>> think they still hold on their promises.
>
> Well, regarding the r8a779x-cpg-mssr.h the small amount of work needed isn't
> a really good argument if you are good with cp & sed for the copy & paste
> done ;)
They're not really created by cp & sed, as they must match the table in the
datasheet (the latter may have been created by copy & paste though :-)
> What I fear we end up the way we are doing the copy & paste
> r8a779x-cpg-mssr.h is having 5 or 6 or even more of these files, all > 90%
> identical. And once you have to change anything, you either have to change
> all these files. Or you miss anything, ending up with subtle bugs when one
> SoC does behave differently than an other one.
The point is these files are stable ABI: no single value can be changed.
No value can be reused. Only new values can be appended at the bottom
(if a newer revision of the datasheet documents more clocks than the old
version, which happens from time to time).
IMHO a hierarchical way of defining the clocks has more opportunity of
accidentally referring to a clock that doesn't exist on a particular SoC.
Furthermore, r8a779x-cpg-mssr.h is not a good name to be part of a DT binding,
due to the wildcard.
A future SoC may will match r8a779x and even be called (R-Car 3?),
while using a completely different CPG block.
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 0/9] clocksource/drivers/clksrc-of: Improve error handling
Hi Daniel,
On Wed, Jun 1, 2016 at 10:34 AM, Daniel Lezcano
<daniel.lezc...@linaro.org> wrote:
> The macro CLOCKSOURCE_OF_DECLARE is widely used in the timer drivers.
>
> Basically, this macro is defined to insert in a table a tuple name,function.
> This function is an init function called when the name matches the DT node and
> its signature is:
>
> typedef void (*of_init_fn_1)(struct device_node *);
>
> It does not return an error code.
>
> That results in the clocksource-probe not being able to figure out if the
> driver
> was correctly initialized or not, the different drivers to act as they were
> the
> only ones on the system (panic, instead of failing gracefully), and duplicated
> code for error reporting.
>
> This series initiates the logic change and centralize the error handling in
> the
> clocksource probe code.
>
> In order to do the changes little by little, a new macro was introduced:
>
> CLOCKSOURCE_OF_DECLARE_RET()
As I have no other thread to reply to, I'm using this related one.
commit bcbe219f9306da478b77e705a7273843c2660d7b
Author: Daniel Lezcano <daniel.lezc...@linaro.org>
Date: Tue Jun 7 00:27:44 2016 +0200
clocksources: Switch back to the clksrc table
Signed-off-by: Daniel Lezcano <daniel.lezc...@linaro.org>
in clockevents/clockevents/next breaks the boot on e.g. r8a7791/koelsch
(arm32) and r8a7795/salvator-x (arm64).
Using "earlycon keep_bootcon" on koelsch (this doesn't help on arm64)
reveals it's stuck at:
clocksource_probe: no matching clocksources found
sched_clock: 32 bits at 100 Hz, resolution 1000ns, wraps every
2147483647500ns
Calibrating delay loop...
With the above commit reverted, it works again:
Architected cp15 timer(s) running at 10.00MHz (virt).
clocksource: arch_sys_counter: mask: 0xff max_cycles:
0x24e6a1710, max_idle_ns: 440795202120 ns
sched_clock: 56 bits at 10MHz, resolution 100ns, wraps every 4398046511100ns
Switching to timer-based delay loop, resolution 100ns
Calibrating delay loop (skipped), value calculated using timer
frequency.. 20.00 BogoMIPS (lpj=10)
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 2/3] pinctrl: sh-pfc: r8a7795: add support for voltage switching
Hi Wolfram,
On Mon, Jun 6, 2016 at 8:50 AM, Wolfram Sang <w...@the-dreams.de> wrote:
> From: Wolfram Sang <wsa+rene...@sang-engineering.com>
>
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
> ---
> drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24 ++--
> 1 file changed, 22 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> index 44632b1a5c978c..8e068d8534de00 100644
> --- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
> @@ -17,8 +17,8 @@
> PORT_GP_CFG_16(0, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
> PORT_GP_CFG_28(1, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
> PORT_GP_CFG_15(2, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
> - PORT_GP_CFG_16(3, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
> - PORT_GP_CFG_18(4, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
> + PORT_GP_CFG_16(3, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH |
> SH_PFC_PIN_CFG_IO_VOLTAGE), \
Shouldn't this be split in PORT_GP_CFG_12() with SH_PFC_PIN_CFG_IO_VOLTAGE,
and PORT_GP_CFG_4() without?
> + PORT_GP_CFG_18(4, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH |
> SH_PFC_PIN_CFG_IO_VOLTAGE), \
Apart from that:
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
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 1/3] pinctrl: sh-pfc: refactor voltage setting
On Mon, Jun 6, 2016 at 8:50 AM, Wolfram Sang <w...@the-dreams.de> wrote:
> From: Wolfram Sang <wsa+rene...@sang-engineering.com>
>
> All known hardware being able to switch voltages has the same POCCTRL
> register. So, factor out the common code to the core and keep only
> the pin-to-bit mapping SoC specific. Convert the only user, r8a7790.
> In case POCCTRL should ever get more complex (more voltages to select?),
> we should probably switch over to a describing array like drive strength
> does currently.
>
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
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 2/3] pinctrl: sh-pfc: r8a7795: add support for voltage switching
Hi Wolfram,
On Mon, Jun 6, 2016 at 1:03 PM, Wolfram Sang <w...@the-dreams.de> wrote:
> On Mon, Jun 06, 2016 at 09:23:35AM +0200, Geert Uytterhoeven wrote:
>> On Mon, Jun 6, 2016 at 8:50 AM, Wolfram Sang <w...@the-dreams.de> wrote:
>> > From: Wolfram Sang <wsa+rene...@sang-engineering.com>
>> >
>> > Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
>> > ---
>> > drivers/pinctrl/sh-pfc/pfc-r8a7795.c | 24 ++--
>> > 1 file changed, 22 insertions(+), 2 deletions(-)
>> >
>> > diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
>> > b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
>> > index 44632b1a5c978c..8e068d8534de00 100644
>> > --- a/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
>> > +++ b/drivers/pinctrl/sh-pfc/pfc-r8a7795.c
>> > @@ -17,8 +17,8 @@
>> > PORT_GP_CFG_16(0, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
>> > PORT_GP_CFG_28(1, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
>> > PORT_GP_CFG_15(2, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
>> > - PORT_GP_CFG_16(3, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
>> > - PORT_GP_CFG_18(4, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH), \
>> > + PORT_GP_CFG_16(3, fn, sfx, SH_PFC_PIN_CFG_DRIVE_STRENGTH |
>> > SH_PFC_PIN_CFG_IO_VOLTAGE), \
>>
>> Shouldn't this be split in PORT_GP_CFG_12() with SH_PFC_PIN_CFG_IO_VOLTAGE,
>> and PORT_GP_CFG_4() without?
>
> Right. However, PORT_GP_CFG_4 doesn't allow to set an offset for the pin
> numbers. Options I see:
> a) keep it as is and rely on the checks in pin_to_pocctrl()
> b) use PORT_GP_CFG_12 and 4 times PORT_GP_CFG_1 which allow setting the
>pin number
> c) introduce (yet another) macro like PORT_GP_CFG_4_OFS
>
> So far, I thought a) was good enough. Now I tend to option b) because it
> is indeed more precise. We still can do c) if demand for such a macro
> increases.
>
> What do you think?
Option b is fine for me.
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/RFC 0/1] soc: renesas: Add DT fixup code for backwards compatibility
On Thu, Jun 2, 2016 at 11:24 PM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > On Wednesday 01 Jun 2016 15:27:59 Rob Herring wrote: >> On Wed, Jun 1, 2016 at 2:50 PM, Geert Uytterhoeven wrote: >> > When moving functionality from C code to DT, we're regularly faced with >> > stable DT issues: old DTBs should keep on working. This requires keeping >> > workaround code in the kernel. >> > >> > An alternative solution to having workaround C code, would be to >> > dynamically modify the DT, to add missing device nodes and phandle links. >> > >> > This has several advantages: >> > - All workarounds are kept together, >> > - Workarounds can be enabled/disabled using a single Kconfig option, >> > - Individual driver code is not polluted by workaround code. >> > >> > Examples of missing support in DT are: >> > - A device node for the R-Car RST (Reset Controller), which a.o. >> > provides access to the Mode Pins (currently handled using an >> > hardcoded address in platform/driver code), cfr. the series >> > "[PATCH/RFC v3 00/22] soc: renesas: Add R-Car RST driver for >> > obtaining mode pin state" I've just sent >> > (http://www.spinics.net/lists/linux-renesas-soc/msg04289.html), >> > >> > - A device node for the R-Car SYSC (System Controller), to link CPUs >> > to their respective power domains (On R-Car Gen2 CPUs can be >> > auto-detected, as there's a register indicating which CPU cores are >> > present), >> > >> > - Add a device node for the R-Car Gen2 APMU (Advanced Power >> > >> > Management Unit), for modern CPU bringup using "enable-method". >> > Note that the method from this RFC doesn't work for >> > "enable-method", as that is parsed in arm_dt_init_cpu_maps(), >> > immediately after unflatten_device_tree(), long before initcalls >> > run. >> > >> > However, there are other possible uses: >> > - Workarounds for hardware bugs: early engineering samples of an SoC >> > >> > may have non-functional devices. This would allow to describe the >> > latest (functional) hardware in the .dtsi, knowing that the fixup >> > code will disable non-functional devices when running on an early >> > engineering sample, based on reading the PRR (Product Revision >> > Register). >> > >> > - Handle other differences between SoC versions, e.g. change >> > >> > compatible values for an early engineering sample that needs special >> > handling, or limit the features of a device. >> > >> > - Add SoC-specific compatible values to all device nodes (e.g. add >> > >> > "renesas,r8a7795-wdt" to a node already having >> > "renesas,rcar-gen3-wdt" when running on r8a7795). This would make >> > it easier to share .dtsi files within the same SoC family, without >> > relying on e.g. C preprocessor tricks. >> > >> > This proof-of-concept implements this for the missing R-Car RST (Reset >> > Controller) node. This poc is not suitable for all of the above, as some >> > DT structures (e.g. the CPU's "enable-method) are parsed long before >> > early_initcall(), and would need a different workaround. >> > >> > What do you think? >> >> I have no objection to this method of dealing with compatibility. >> However your handling is still C code. What I would like to see here >> is using overlays to apply updates. I would like to be able to take 2 >> dts files and create an overlay dts based on their diff (or you could >> do this step manually). Then build the overlay dtb into the kernel and >> apply it on boot based on some match. Then thru the magic of linker >> sections, it becomes a matter of just adding the dtbo into the build >> and a one line declaration: >> >> DT_QUIRK(my_quirk_dtbo, "vendor,board"); >> >> BTW, I'd also like to see tools to apply overlays offline into a new >> dtb or compile dts files and overlays to a dtb. > > We need to keep the use case in mind. The main (and possibly only) reason why > we want to patch DT this way is to support systems whose DTB can't be updated > (otherwise we could just update the DTB) and isn't fully known in advance to > the kernel (otherwise we would just bundle an updated full DTB with the > kernel). We thus need a heuristic-based approach at runtime to identif
Re: [PATCH v2 00/11] iommu/ipmmu-vmsa: r8a7795 support V2
Hi Magnus,
On Mon, Jun 6, 2016 at 5:57 AM, Magnus Damm <magnus.d...@gmail.com> wrote:
> iommu/ipmmu-vmsa: r8a7795 support V2
>
> [PATCH v2 01/11] iommu/ipmmu-vmsa: Introduce features, break out alias
> [PATCH v2 02/11] iommu/ipmmu-vmsa: Add optional root device feature
> [PATCH v2 03/11] iommu/ipmmu-vmsa: Enable multi context support
> [PATCH v2 04/11] iommu/ipmmu-vmsa: Reuse iommu groups
> [PATCH v2 05/11] iommu/ipmmu-vmsa: Make use of IOMMU_OF_DECLARE()
> [PATCH v2 06/11] iommu/ipmmu-vmsa: Teach xlate() to skip disabled iommus
> [PATCH v2 07/11] iommu/ipmmu-vmsa: IPMMU device is 64-bit bus master
> [PATCH v2 08/11] iommu/ipmmu-vmsa: Write IMCTR twice
> [PATCH v2 09/11] iommu/ipmmu-vmsa: Make IMBUSCTR setup optional
> [PATCH v2 10/11] iommu/ipmmu-vmsa: Allow two bit SL0
> [PATCH v2 11/11] iommu/ipmmu-vmsa: Hook up r8a7795 DT matching code
Thanks for your series!
For your convenience, I've queued it up in topic/r8a7795-ipmmu-v2 at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git, and
will include it in next renesas-drivers release.
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 3/3] arm64: dts: r8a7795: salvator: enable UHS for SDHI 0 & 3
On Mon, Jun 6, 2016 at 8:50 AM, Wolfram Sang <w...@the-dreams.de> wrote:
> From: Wolfram Sang <wsa+rene...@sang-engineering.com>
>
> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
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-2016-06-07-v4.7-rc2
I have pushed renesas-drivers-2016-06-07-v4.7-rc2 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-20160606-v4.7-rc2.
Included branches with driver code:
- clk-renesas-for-v4.8
- topic/rcar-dmac-residue-v1
- topic/rcar-dmac-hamza-v3
- topic/ipmmu-multi-arch-v3
- topic/r8a7795-ipmmu-v2
- topic/r8a7796-ipmmu-v1
- topic/salvator-x-ipmmu-rfc-v3-rebased4
- topic/scif-hwflow-v3
- topic/scif-fifo-v1
-
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/r8a7796-v3
- topic/r8a7796-sysc-dt-v1
-
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-v3
- git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#staging/ks7010
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#renesas/topic/pretimeout
- topic/h3-pfc-set-voltage-v1-rebased1
- https://git.ragnatech.se/linux#rcar-vin-for-renesas-drivers
- git://linuxtv.org/pinchartl/media.git#for/renesas-drivers
- git://linuxtv.org/pinchartl/media.git#vsp1/functions
- topic/fcpf-v1-rebased1
Included fixes:
- Revert "clocksources: Switch back to the clksrc table"
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://people.freedesktop.org/~airlied/linux#drm-next
- git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
- git://linuxtv.org/mchehab/media-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git#mmc-next
- git://git.linaro.org/people/ulf.hansson/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.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine.git#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://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/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://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
- git://git.infradead.org/battery-2.6.git#master
- 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-intel#topic/drm-misc
- 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
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 v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3
Hi Magnus,
On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm <magnus.d...@gmail.com> wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V3
>
> [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for
> context
> [PATCH v3 03/06] iommu/ipmmu-vmsa: Break out utlb parsing code
> [PATCH v3 04/06] iommu/ipmmu-vmsa: Break out domain allocation code
> [PATCH v3 05/06] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
> [PATCH v3 06/06] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency
>
> These patches update the IPMMU driver with a couple of changes
> to support build on multiple architectures. In the process of
> doing so the interrupt code gets reworked and the foundation
> for supporting multiple contexts are added.
>
> In this version of the series the patch order has been reworked
> to make simplify review. Thanks to Laurent for his suggestions!
>
> The 32-bit ARM logic has intentionally been changed as little as possible
> to avoid breakage. Once CONFIG_IOMMU_DMA can be used it may be good time
> to revisit the init ordering for the 32-bit SoCs. There is room for
> improvement for sure like Robin Murphy kindly pointed out.
When IPMMU_VMSA is enabled on 32-bit ARM, the system crashes during boot.
I saw this first on r8a73a4/ape6evm, where my local config had it enabled.
After enabling IOMMU support and IPMMU_VMSA in my config for r8a7791/koelsch,
koelsch crashes during boot, too, although the failure mode is different.
Unfortunately I've lost all collected crash logs in a power failure due to the
bad weather. So you may beat me to reproduce this.
I did verify in time that the crashes do not happen with a similar config on
renesas-drivers-2016-05-31-v4.7-rc1, which contained the previous version of
your patch set.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/3] iommu/ipmmu-vmsa: Hook up r8a7796 DT matching code
Hi Laurent,
On Wed, Jun 8, 2016 at 2:18 AM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
>> --- 0031/drivers/iommu/ipmmu-vmsa.c
>> +++ work/drivers/iommu/ipmmu-vmsa.c 2016-06-06 11:19:40.210607110 +0900
>> @@ -1074,7 +1074,7 @@ static const struct ipmmu_features ipmmu
>> .twobit_imttbcr_sl0 = false,
>> };
>>
>> -static const struct ipmmu_features ipmmu_features_r8a7795 = {
>> +static const struct ipmmu_features ipmmu_features_rcar_gen3 = {
>> .use_ns_alias_offset = false,
>> .has_cache_leaf_nodes = true,
>> .has_eight_ctx = true,
>> @@ -1088,7 +1088,10 @@ static const struct of_device_id ipmmu_o
>> .data = _features_default,
>> }, {
>> .compatible = "renesas,ipmmu-r8a7795",
>> - .data = _features_r8a7795,
>> + .data = _features_rcar_gen3,
>> + }, {
>> + .compatible = "renesas,ipmmu-r8a7796",
>> + .data = _features_rcar_gen3,
>> }, {
>> /* Terminator */
>> },
>> @@ -1268,6 +1271,8 @@ IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "r
>>ipmmu_vmsa_iommu_of_setup);
>> IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795",
>>ipmmu_vmsa_iommu_of_setup);
>> +IOMMU_OF_DECLARE(ipmmu_r8a7796_iommu_of, "renesas,ipmmu-r8a7796",
>> + ipmmu_vmsa_iommu_of_setup);
>
> How about a Gen3 generic compatible string in addition to the SoC-specific
> ones ?
Do we want to specify the number of utlbs here?
Does it differ between r8a7795, r8a7796, and future members?
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 05/11] ARM: dts: r8a7792: initial SoC device tree
Hi Sergei,
On Fri, Jun 3, 2016 at 11:26 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> The initial R8A7792 SoC device tree including CPU core, GIC, timer, SYSC,
> and the required clock descriptions.
>
> Signed-off-by: Sergei Shtylyov <sergei.shtyl...@cogentembedded.com>
>
> ---
> Changes in version 2:
> - created the "soc" subnode, moving the SoC device nodes there;
> - removed the "clocks" node, moving its fixed clock subnodes to the root and
> the MSTP subnodes into the "soc" node.
>
> arch/arm/boot/dts/r8a7792.dtsi | 171
> +
> 1 file changed, 171 insertions(+)
>
> Index: renesas/arch/arm/boot/dts/r8a7792.dtsi
> ===
> --- /dev/null
> +++ renesas/arch/arm/boot/dts/r8a7792.dtsi
> + /* Fixed factor clocks */
> + zs_clk: zs {
> + compatible = "fixed-factor-clock";
> + clocks = <_clocks R8A7792_CLK_PLL1>;
> + #clock-cells = <0>;
> + clock-div = <6>;
> + clock-mult = <1>;
> + };
> + p_clk: p {
> + compatible = "fixed-factor-clock";
> + clocks = <_clocks R8A7792_CLK_PLL1>;
> + #clock-cells = <0>;
> + clock-div = <24>;
> + clock-mult = <1>;
> + };
> + cp_clk: cp {
> + compatible = "fixed-factor-clock";
> + clocks = <_clocks R8A7792_CLK_PLL1>;
> + #clock-cells = <0>;
> + clock-div = <3>;
> + clock-mult = <1>;
> + };
I think the above 3 fixed factor clocks should be children of the "soc" node,
as they're generated on-SoC.
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 2/4] clk: renesas: Add r8a7796 CPG Core Clock Definitions
Hi Dirk,
On Mon, Jun 6, 2016 at 2:03 PM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
> On 30.05.2016 18:36, Dirk Behme wrote:
>> On 30.05.2016 18:28, Geert Uytterhoeven wrote:
>>> Add all R-Car M3-W Clock Pulse Generator Core Clock Outputs, as listed
>>> in Table 8.2b ("List of Clocks [R-Car M3-W]") of the R-Car Gen3
>>> datasheet (rev. 0.51 + Errata for Rev051 Mar 31 2016).
>>>
>>> Note that internal CPG clocks (S0, S1, S2, S3, SDSRC, and SSPSRC) are
>>> not included, as they are used as internal clock sources only, and never
>>> referenced from DT.
>>>
>>> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
>>> Tested-by: Simon Horman <horms+rene...@verge.net.au>
>>> ---
>>> v2:
>>>- Add Tested-by.
>>> ---
>>> include/dt-bindings/clock/r8a7796-cpg-mssr.h | 69
>>>
>>> 1 file changed, 69 insertions(+)
>>> create mode 100644 include/dt-bindings/clock/r8a7796-cpg-mssr.h
>>>
>>> diff --git a/include/dt-bindings/clock/r8a7796-cpg-mssr.h
>>> b/include/dt-bindings/clock/r8a7796-cpg-mssr.h
>>> new file mode 100644
>>> index ..1e5942695f0dd057
>>> --- /dev/null
>>> +++ b/include/dt-bindings/clock/r8a7796-cpg-mssr.h
>>> @@ -0,0 +1,69 @@
>>> +/*
>>> + * Copyright (C) 2016 Renesas Electronics Corp.
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License as published by
>>> + * the Free Software Foundation; either version 2 of the License, or
>>> + * (at your option) any later version.
>>> + */
>>> +#ifndef __DT_BINDINGS_CLOCK_R8A7796_CPG_MSSR_H__
>>> +#define __DT_BINDINGS_CLOCK_R8A7796_CPG_MSSR_H__
>>> +
>>> +#include
>>> +
>>> +/* r8a7796 CPG Core Clocks */
>>> +#define R8A7796_CLK_Z0
[...]
>> I think we recently started a discussion to find a more clever way to
>> avoid re-defining (copy & paste) all this R-Car3 clocks (compare [1])
>> where they are the same over the R-Car3 family while still being able to
>> deal with the differences.
>>
>> Best regards
>>
>> Dirk
>>
>> [1]
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/dt-bindings/clock/r8a7795-cpg-mssr.h
>
> What's the status of the discussion I mentioned above?
As mentioned in that thread,the CPGs in r8a7795 and r8a7796 provide
slightly different sets of clocks. Future members of the R-Car Gen3
family may provide the same or different sets of clocks, we don't know.
As Magnus already mentions, we try to stay as close as possible to the
datasheet (which is unfortunately a moving target, too).
For CPG Core Clocks, the datasheet only provides us with a list of named
clocks. There are no fixed numbers. So either we refer to clocks by
name, or by coming up with our own numbering scheme (which has to be a
stable set of numbers, i.e. append only).
For MSSR (Module) Clocks, the datasheet does provide us with numbers
(MSTP register index + bit index inside the register).
The way the CPG/MSSR drivers handles these clocks was heavily influenced
by the experience we gained with the Common Clock Framework and DT on
R-Car Gen2.
R-Car Gen2 described all clocks and their registers in DT. The goal
(utopia?) here was to handle all SoCs from the family with a single
driver, provided it was fed with the right description in DT.
For CPG Core Clocks, this lead to a mix of:
- Nodes for fixed factor clocks,
- Nodes for variable factor clocks, specifying a register to operate
on,
- Special CPG clocks that couldn't be handled by the above, using a
common (family-specific) list of definitions for clocks, that had to
be extended constantly.
For MSSR Clocks (called "MSTP" for historical reasons), each set of 32
clocks had its own node, with multiple registers, and three separate
arrays for parent clocks, clock indices, and clock names, that had to be
kept in sync. The clock indices were defines, using numbers from the
datasheet, but they were still easy to abuse (which register does the
define apply to?).
As the CCF was quite new and best practices were still under
development, all of this was difficult to define up-front.
Due to the complexity, it was also hard to review and maintain, leading
to many errors.
The arbitrary (grown organically) offsets for the various MSSR-related
registers also made it hard to ever add module reset support.
Hence the call for a new framework, designed in close collaboration with the
clock maintainer, and implemented in the CPG/MSSR
[PATCH 19/19] ARM: dts: kzm9g: Name serial port pfc subnode after device name
Name the Pin Function Controller subnode for SCIFA4 after its device
name, instead of after the serial port alias.
This avoids conflicts when adding support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/sh73a0-kzm9g.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g.dts
b/arch/arm/boot/dts/sh73a0-kzm9g.dts
index 36567cbf2e1c32dd..1df68b1670339491 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
@@ -352,7 +352,7 @@
};
};
- scifa4_pins: serial4 {
+ scifa4_pins: scifa4 {
groups = "scifa4_data", "scifa4_ctrl";
function = "scifa4";
};
--
1.9.1
[PATCH 16/19] ARM: dts: alt: Name spi pfc subnode after device name
Name the Pin Function Controller subnode for QSPI after its device name,
instead of after the spi interface alias.
This avoids conflicts when enabl support for more spi interfaces later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7794-alt.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts
b/arch/arm/boot/dts/r8a7794-alt.dts
index 1335664b2f886a17..1ad37d431a2a3bfc 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -147,7 +147,7 @@
};
{
- qspi_pins: spi0 {
+ qspi_pins: qspi {
groups = "qspi_ctrl", "qspi_data4";
function = "qspi";
};
--
1.9.1
[PATCH 00/19] ARM: dts: renesas: Name pfc subnodes after device names
Hi Simon, Magnus,
Currently board DTS files use various naming conventions for the Pin
Function Controller subnodes. This may cause conflicts when enabling
support for more instances later, either directly in board DT files, or
in DT overlays. These conflicts are most likely to happen for devices
that use/require aliases (e.g. "serial1"), or when using generic and
indexless names (e.g. "mmc"). Hence this series changes the names of
(most of) the submodes, to match the corresponding device names, which
are unique on a specific SoC.
I did not change the following node names:
- "sdX", as they always matched the corresponding "sdhiX" name,
- "touchscreen", as there's not much opportunity for conflicts,
- "mmc", for "mmcif_pins" on sh73a0/kzm9g (which has a single mmc
instance),
- "sounda" for fsia_pins on SH-Mobile,
If you think these should be changed too, please let me know.
This series is against renesas-devel-20160606-v4.7-rc2.
Thanks!
Geert Uytterhoeven (19):
ARM: dts: ape6evm: Name serial port pfc subnode after device name
ARM: dts: ape6evm: Name mmc pfc subnode after device name
ARM: dts: armadillo800eva: Name serial port pfc subnode after device
name
ARM: dts: bockw: Name serial port pfc subnode after device name
ARM: dts: marzen: Name serial port pfc subnodes after device names
ARM: dts: lager: Name serial port pfc subnodes after device names
ARM: dts: lager: Name spi pfc subnodes after device names
ARM: dts: lager: Name vin pfc subnode after device name
ARM: dts: koelsch: Name serial port pfc subnodes after device names
ARM: dts: koelsch: Name spi pfc subnodes after device names
ARM: dts: porter: Name serial port pfc subnode after device name
ARM: dts: porter: Name spi pfc subnode after device name
ARM: dts: gose: Name serial port pfc subnodes after device names
ARM: dts: gose: Name spi pfc subnode after device name
ARM: dts: alt: Name serial port pfc subnode after device name
ARM: dts: alt: Name spi pfc subnode after device name
ARM: dts: silk: Name serial port pfc subnode after device name
ARM: dts: silk: Name spi pfc subnode after device name
ARM: dts: kzm9g: Name serial port pfc subnode after device name
arch/arm/boot/dts/r8a73a4-ape6evm.dts | 4 ++--
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 +-
arch/arm/boot/dts/r8a7778-bockw.dts | 2 +-
arch/arm/boot/dts/r8a7779-marzen.dts | 4 ++--
arch/arm/boot/dts/r8a7790-lager.dts | 10 +-
arch/arm/boot/dts/r8a7791-koelsch.dts | 8
arch/arm/boot/dts/r8a7791-porter.dts | 4 ++--
arch/arm/boot/dts/r8a7793-gose.dts| 6 +++---
arch/arm/boot/dts/r8a7794-alt.dts | 4 ++--
arch/arm/boot/dts/r8a7794-silk.dts| 4 ++--
arch/arm/boot/dts/sh73a0-kzm9g.dts| 2 +-
11 files changed, 25 insertions(+), 25 deletions(-)
--
1.9.1
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 11/19] ARM: dts: porter: Name serial port pfc subnode after device name
Name the Pin Function Controller subnode for SCIF0 after its device
name, instead of after the serial port alias.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7791-porter.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
index e9151e946da8099b..85d109a5f43c4017 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -142,7 +142,7 @@
};
{
- scif0_pins: serial0 {
+ scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
};
--
1.9.1
[PATCH 01/19] ARM: dts: ape6evm: Name serial port pfc subnode after device name
Name the Pin Function Controller subnode for SCIFA0 after its device
name, instead of after the serial port alias.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a73a4-ape6evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a73a4-ape6evm.dts
b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
index 740e5d23f7c70843..5bccc7d229d766c7 100644
--- a/arch/arm/boot/dts/r8a73a4-ape6evm.dts
+++ b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
@@ -188,7 +188,7 @@
};
{
- scifa0_pins: serial0 {
+ scifa0_pins: scifa0 {
groups = "scifa0_data";
function = "scifa0";
};
--
1.9.1
[PATCH 12/19] ARM: dts: porter: Name spi pfc subnode after device name
Name the Pin Function Controller subnode for QSPI after its device name,
instead of after the spi interface alias.
This avoids conflicts when enabling support for more spi interfaces
later, either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7791-porter.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7791-porter.dts
b/arch/arm/boot/dts/r8a7791-porter.dts
index 85d109a5f43c4017..6761d11d3f9e1317 100644
--- a/arch/arm/boot/dts/r8a7791-porter.dts
+++ b/arch/arm/boot/dts/r8a7791-porter.dts
@@ -167,7 +167,7 @@
function = "sdhi2";
};
- qspi_pins: spi0 {
+ qspi_pins: qspi {
groups = "qspi_ctrl", "qspi_data4";
function = "qspi";
};
--
1.9.1
[PATCH 18/19] ARM: dts: silk: Name spi pfc subnode after device name
Name the Pin Function Controller subnode for QSPI after its device name,
instead of after the spi interface alias.
This avoids conflicts when enabling support for more spi interfaces
later, either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7794-silk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts
b/arch/arm/boot/dts/r8a7794-silk.dts
index 7e88f6fe55cdcc02..488de730bee89f42 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -164,7 +164,7 @@
function = "sdhi1";
};
- qspi_pins: spi0 {
+ qspi_pins: qspi {
groups = "qspi_ctrl", "qspi_data4";
function = "qspi";
};
--
1.9.1
[PATCH 08/19] ARM: dts: lager: Name vin pfc subnode after device name
Name the Pin Function Controller subnode for VIN1 after its device name,
instead of using the generic and indexless "vin".
This avoids conflicts when enabling support for more video inputs later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7790-lager.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 2d72c75ba4cb9c97..5e43763cec6575d3 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -427,7 +427,7 @@
function = "usb2";
};
- vin1_pins: vin {
+ vin1_pins: vin1 {
groups = "vin1_data8", "vin1_clk";
function = "vin1";
};
--
1.9.1
[PATCH 09/19] ARM: dts: koelsch: Name serial port pfc subnodes after device names
Name the Pin Function Controller subnodes for SCIF0 and SCIF1 after
their device names, instead of after the serial port aliases.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 20fbc8c36a785bd3..73e5ecf036e1b968 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -332,12 +332,12 @@
function = "du";
};
- scif0_pins: serial0 {
+ scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
};
- scif1_pins: serial1 {
+ scif1_pins: scif1 {
groups = "scif1_data_d";
function = "scif1";
};
--
1.9.1
[PATCH 07/19] ARM: dts: lager: Name spi pfc subnodes after device names
Name the Pin Function Controller subnodes for QSPI and MSIOF1 after
their device names, instead of after the spi interface aliases.
This avoids conflicts when enabling support for more spi interfaces
later, either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7790-lager.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7790-lager.dts
b/arch/arm/boot/dts/r8a7790-lager.dts
index 9cb055a932edabc7..2d72c75ba4cb9c97 100644
--- a/arch/arm/boot/dts/r8a7790-lager.dts
+++ b/arch/arm/boot/dts/r8a7790-lager.dts
@@ -371,12 +371,12 @@
function = "mmc1";
};
- qspi_pins: spi0 {
+ qspi_pins: qspi {
groups = "qspi_ctrl", "qspi_data4";
function = "qspi";
};
- msiof1_pins: spi2 {
+ msiof1_pins: msiof1 {
groups = "msiof1_clk", "msiof1_sync", "msiof1_rx",
"msiof1_tx";
function = "msiof1";
--
1.9.1
[PATCH 04/19] ARM: dts: bockw: Name serial port pfc subnode after device name
Name the Pin Function Controller subnode for SCIF0 after its device
name, instead of after the serial port alias.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7778-bockw.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7778-bockw.dts
b/arch/arm/boot/dts/r8a7778-bockw.dts
index 0a0bd3b6bb401ce2..211d239d9041a886 100644
--- a/arch/arm/boot/dts/r8a7778-bockw.dts
+++ b/arch/arm/boot/dts/r8a7778-bockw.dts
@@ -129,7 +129,7 @@
pinctrl-0 = <_clk_pins>;
pinctrl-names = "default";
- scif0_pins: serial0 {
+ scif0_pins: scif0 {
groups = "scif0_data_a", "scif0_ctrl";
function = "scif0";
};
--
1.9.1
[PATCH 15/19] ARM: dts: alt: Name serial port pfc subnode after device name
Name the Pin Function Controller subnode for SCIF2 after its device
name, instead of using some arbitrary name that looks like a serial port
alias, but differs from the actual alias.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7794-alt.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794-alt.dts
b/arch/arm/boot/dts/r8a7794-alt.dts
index 383ad791f1db3151..1335664b2f886a17 100644
--- a/arch/arm/boot/dts/r8a7794-alt.dts
+++ b/arch/arm/boot/dts/r8a7794-alt.dts
@@ -111,7 +111,7 @@
function = "du";
};
- scif2_pins: serial2 {
+ scif2_pins: scif2 {
groups = "scif2_data";
function = "scif2";
};
--
1.9.1
[PATCH 17/19] ARM: dts: silk: Name serial port pfc subnode after device name
Name the Pin Function Controller subnode for SCIF2 after its device
name, instead of using some arbitrary name that looks like a serial port
alias, but differs from the actual alias.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7794-silk.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7794-silk.dts
b/arch/arm/boot/dts/r8a7794-silk.dts
index b8c7a63c5ec456bc..7e88f6fe55cdcc02 100644
--- a/arch/arm/boot/dts/r8a7794-silk.dts
+++ b/arch/arm/boot/dts/r8a7794-silk.dts
@@ -129,7 +129,7 @@
pinctrl-0 = <_clk_pins>;
pinctrl-names = "default";
- scif2_pins: serial2 {
+ scif2_pins: scif2 {
groups = "scif2_data";
function = "scif2";
};
--
1.9.1
[PATCH 02/19] ARM: dts: ape6evm: Name mmc pfc subnode after device name
Name the Pin Function Controller subnode for MMC0 after its device name,
instead of using the generic and indexless "mmc".
This avoids conflicts when enabling support for more MMC interfaces
later, either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a73a4-ape6evm.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a73a4-ape6evm.dts
b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
index 5bccc7d229d766c7..ec7c86e06538677a 100644
--- a/arch/arm/boot/dts/r8a73a4-ape6evm.dts
+++ b/arch/arm/boot/dts/r8a73a4-ape6evm.dts
@@ -193,7 +193,7 @@
function = "scifa0";
};
- mmc0_pins: mmc {
+ mmc0_pins: mmc0 {
groups = "mmc0_data8", "mmc0_ctrl";
function = "mmc0";
};
--
1.9.1
[PATCH 03/19] ARM: dts: armadillo800eva: Name serial port pfc subnode after device name
Name the Pin Function Controller subnode for SCIFA1 after its device
name, instead of after the serial port alias.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
index 1620495166851971..6866f61a350c7cc3 100644
--- a/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
+++ b/arch/arm/boot/dts/r8a7740-armadillo800eva.dts
@@ -232,7 +232,7 @@
function = "gether";
};
- scifa1_pins: serial1 {
+ scifa1_pins: scifa1 {
groups = "scifa1_data";
function = "scifa1";
};
--
1.9.1
[PATCH 14/19] ARM: dts: gose: Name spi pfc subnode after device name
Name the Pin Function Controller subnode for QSPI after its device name,
instead of after the spi interface alias.
This avoids conflicts when enabl support for more spi interfaces later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7793-gose.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
b/arch/arm/boot/dts/r8a7793-gose.dts
index 995e1e0fb1ff4f57..90af18600124e119 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -360,7 +360,7 @@
renesas,function = "sdhi2";
};
- qspi_pins: spi0 {
+ qspi_pins: qspi {
groups = "qspi_ctrl", "qspi_data4";
function = "qspi";
};
--
1.9.1
[PATCH 10/19] ARM: dts: koelsch: Name spi pfc subnodes after device names
Name the Pin Function Controller subnodes for QSPI and MSIOF0 after
their device names, instead of after the spi interface aliases.
This avoids conflicts when enabling support for more spi interfaces
later, either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7791-koelsch.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7791-koelsch.dts
b/arch/arm/boot/dts/r8a7791-koelsch.dts
index 73e5ecf036e1b968..f8a7d090fd017deb 100644
--- a/arch/arm/boot/dts/r8a7791-koelsch.dts
+++ b/arch/arm/boot/dts/r8a7791-koelsch.dts
@@ -372,12 +372,12 @@
function = "sdhi2";
};
- qspi_pins: spi0 {
+ qspi_pins: qspi {
groups = "qspi_ctrl", "qspi_data4";
function = "qspi";
};
- msiof0_pins: spi1 {
+ msiof0_pins: msiof0 {
groups = "msiof0_clk", "msiof0_sync", "msiof0_rx",
"msiof0_tx";
function = "msiof0";
--
1.9.1
[PATCH 05/19] ARM: dts: marzen: Name serial port pfc subnodes after device names
Name the Pin Function Controller subnodes for SCIF2 and SCIF4 after
their device names, instead of using some arbitrary names that look like
serial port aliases, but differ from the actual aliases.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7779-marzen.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts
b/arch/arm/boot/dts/r8a7779-marzen.dts
index cec79a6347c036f7..013e6f510b0faae4 100644
--- a/arch/arm/boot/dts/r8a7779-marzen.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -195,12 +195,12 @@
};
};
- scif2_pins: serial2 {
+ scif2_pins: scif2 {
groups = "scif2_data_c";
function = "scif2";
};
- scif4_pins: serial4 {
+ scif4_pins: scif4 {
groups = "scif4_data";
function = "scif4";
};
--
1.9.1
[PATCH 13/19] ARM: dts: gose: Name serial port pfc subnodes after device names
Name the Pin Function Controller subnodes for SCIF0 and SCIF1 after
their device names, instead of after the serial port aliases.
This avoids conflicts when enabling support for more serial ports later,
either here or in a DT overlay.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm/boot/dts/r8a7793-gose.dts | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/r8a7793-gose.dts
b/arch/arm/boot/dts/r8a7793-gose.dts
index f748360ee85712f1..995e1e0fb1ff4f57 100644
--- a/arch/arm/boot/dts/r8a7793-gose.dts
+++ b/arch/arm/boot/dts/r8a7793-gose.dts
@@ -320,12 +320,12 @@
function = "du";
};
- scif0_pins: serial0 {
+ scif0_pins: scif0 {
groups = "scif0_data_d";
function = "scif0";
};
- scif1_pins: serial1 {
+ scif1_pins: scif1 {
groups = "scif1_data_d";
function = "scif1";
};
--
1.9.1
Re: [PATCH 2/3] dt-bindings: Document Renesas R-Car FCP power-domains usage
Hi Rob,
On Fri, Jun 10, 2016 at 7:39 PM, Rob Herring <r...@kernel.org> wrote:
> On Thu, Jun 09, 2016 at 02:41:33PM +0100, Kieran Bingham wrote:
>> The power domain must be specified to bring the device out of module
>> standby. Document this in the example provided, so that new additions
>> are not missed.
>>
>> Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
>> ---
>> Documentation/devicetree/bindings/media/renesas,fcp.txt | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt
>> b/Documentation/devicetree/bindings/media/renesas,fcp.txt
>> index 271dcfdb5a76..6a55f5215221 100644
>> --- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
>> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
>> @@ -31,4 +31,5 @@ Device node example
>> compatible = "renesas,r8a7795-fcpv", "renesas,fcpv";
>> reg = <0 0xfea2f000 0 0x200>;
>> clocks = < CPG_MOD 602>;
>> + power-domains = < R8A7795_PD_A3VP>;
>
> This needs to be documented above too, not just the example.
Why? Power domains are an optional feature, whose presence depends
on the platform, not on the device.
Hence "power-domains" properties may appear in any device node.
Having to document them in every single binding document is overkill.
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] pinctrl: sh-pfc: sh7757: Fix duplicate initializer in GPIO pinmux data
With C=1:
drivers/pinctrl/sh-pfc/pfc-sh7757.c:1613:9: warning: Initializer entry
defined twice
drivers/pinctrl/sh-pfc/pfc-sh7757.c:1628:9: also defined here
Remove the duplicate initializer to fix this.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
Based on the comment near the definition of A16_MARK, which states A16
belongs to the "PTV" section.
I do not have a sh7757 datasheet.
---
drivers/pinctrl/sh-pfc/pfc-sh7757.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/pinctrl/sh-pfc/pfc-sh7757.c
b/drivers/pinctrl/sh-pfc/pfc-sh7757.c
index 0555a1fe076ed353..6d8c31caefc105e0 100644
--- a/drivers/pinctrl/sh-pfc/pfc-sh7757.c
+++ b/drivers/pinctrl/sh-pfc/pfc-sh7757.c
@@ -1625,7 +1625,6 @@ static const struct pinmux_func pinmux_func_gpios[] = {
GPIO_FN(VBIOS_CS),
/* PTW (mobule: LBSC, EVC, SCIF) */
- GPIO_FN(A16),
GPIO_FN(A15),
GPIO_FN(A14),
GPIO_FN(A13),
--
1.9.1
[PATCH 0/3] pinctrl: sh-pfc: Cleanups
Hi,
This series contains various cleanups for the Renesas Pin Function
Controller driver subsystem.
This has been tested on r8a7791/koelsch, and compile-tested for other
ARM and SH platforms.
I plan to queue this in sh-pfc-for-v4.8.
Thanks for your comments!
Geert Uytterhoeven (3):
pinctrl: sh-pfc: Move SoC-specific forward declarations to sh_pfc.h
pinctrl: sh-pfc: Improve core and user separation
pinctrl: sh-pfc: Convert to devm_gpiochip_add_data()
drivers/pinctrl/sh-pfc/core.c| 10 ---
drivers/pinctrl/sh-pfc/core.h| 58
drivers/pinctrl/sh-pfc/gpio.c| 13 +---
drivers/pinctrl/sh-pfc/pfc-r8a73a4.c | 1 -
drivers/pinctrl/sh-pfc/pfc-r8a7740.c | 1 -
drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 2 +-
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 1 -
drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 1 -
drivers/pinctrl/sh-pfc/sh_pfc.h | 51 ++-
9 files changed, 52 insertions(+), 86 deletions(-)
--
1.9.1
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 1/3] pinctrl: sh-pfc: Move SoC-specific forward declarations to sh_pfc.h
With C=1:
drivers/pinctrl/sh-pfc/pfc-emev2.c:1695:30: warning: symbol
'emev2_pinmux_info' was not declared. Should it be static?
drivers/pinctrl/sh-pfc/pfc-r8a7779.c:3888:30: warning: symbol
'r8a7779_pinmux_info' was not declared. Should it be static?
Note that there are more warnings on SH.
The sh_pfc_soc_info structure is defined in sh_pfc.h, while all forward
declarations for the SoC-specific versions are in core.h.
Move the forward declarations from core.h to sh_pfc.h to fix this.
Reported-by: Ben Dooks <ben.do...@codethink.co.uk>
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/pinctrl/sh-pfc/core.h | 24
drivers/pinctrl/sh-pfc/sh_pfc.h | 24
2 files changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/core.h b/drivers/pinctrl/sh-pfc/core.h
index dc1b2adb24c5c588..539ec7dc0b644dbe 100644
--- a/drivers/pinctrl/sh-pfc/core.h
+++ b/drivers/pinctrl/sh-pfc/core.h
@@ -67,28 +67,4 @@ void sh_pfc_write_reg(struct sh_pfc *pfc, u32 reg, unsigned
int width,
int sh_pfc_get_pin_index(struct sh_pfc *pfc, unsigned int pin);
int sh_pfc_config_mux(struct sh_pfc *pfc, unsigned mark, int pinmux_type);
-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 r8a7778_pinmux_info;
-extern const struct sh_pfc_soc_info r8a7779_pinmux_info;
-extern const struct sh_pfc_soc_info r8a7790_pinmux_info;
-extern const struct sh_pfc_soc_info r8a7791_pinmux_info;
-extern const struct sh_pfc_soc_info r8a7793_pinmux_info;
-extern const struct sh_pfc_soc_info r8a7794_pinmux_info;
-extern const struct sh_pfc_soc_info r8a7795_pinmux_info;
-extern const struct sh_pfc_soc_info sh7203_pinmux_info;
-extern const struct sh_pfc_soc_info sh7264_pinmux_info;
-extern const struct sh_pfc_soc_info sh7269_pinmux_info;
-extern const struct sh_pfc_soc_info sh73a0_pinmux_info;
-extern const struct sh_pfc_soc_info sh7720_pinmux_info;
-extern const struct sh_pfc_soc_info sh7722_pinmux_info;
-extern const struct sh_pfc_soc_info sh7723_pinmux_info;
-extern const struct sh_pfc_soc_info sh7724_pinmux_info;
-extern const struct sh_pfc_soc_info sh7734_pinmux_info;
-extern const struct sh_pfc_soc_info sh7757_pinmux_info;
-extern const struct sh_pfc_soc_info sh7785_pinmux_info;
-extern const struct sh_pfc_soc_info sh7786_pinmux_info;
-extern const struct sh_pfc_soc_info shx3_pinmux_info;
-
#endif /* __SH_PFC_CORE_H__ */
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index ea3a527514558add..332d379b302cba70 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -225,6 +225,30 @@ struct sh_pfc_soc_info {
u32 unlock_reg;
};
+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 r8a7778_pinmux_info;
+extern const struct sh_pfc_soc_info r8a7779_pinmux_info;
+extern const struct sh_pfc_soc_info r8a7790_pinmux_info;
+extern const struct sh_pfc_soc_info r8a7791_pinmux_info;
+extern const struct sh_pfc_soc_info r8a7793_pinmux_info;
+extern const struct sh_pfc_soc_info r8a7794_pinmux_info;
+extern const struct sh_pfc_soc_info r8a7795_pinmux_info;
+extern const struct sh_pfc_soc_info sh7203_pinmux_info;
+extern const struct sh_pfc_soc_info sh7264_pinmux_info;
+extern const struct sh_pfc_soc_info sh7269_pinmux_info;
+extern const struct sh_pfc_soc_info sh73a0_pinmux_info;
+extern const struct sh_pfc_soc_info sh7720_pinmux_info;
+extern const struct sh_pfc_soc_info sh7722_pinmux_info;
+extern const struct sh_pfc_soc_info sh7723_pinmux_info;
+extern const struct sh_pfc_soc_info sh7724_pinmux_info;
+extern const struct sh_pfc_soc_info sh7734_pinmux_info;
+extern const struct sh_pfc_soc_info sh7757_pinmux_info;
+extern const struct sh_pfc_soc_info sh7785_pinmux_info;
+extern const struct sh_pfc_soc_info sh7786_pinmux_info;
+extern const struct sh_pfc_soc_info shx3_pinmux_info;
+
/*
-
* Helper macros to create pin and port lists
*/
--
1.9.1
[PATCH 3/3] pinctrl: sh-pfc: Convert to devm_gpiochip_add_data()
This allows to remove the .remove() callback, and all functions and data
it needed for its own bookkeeping.
Suggested-by: Laxman Dewangan <ldewan...@nvidia.com>
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/pinctrl/sh-pfc/core.c | 10 --
drivers/pinctrl/sh-pfc/core.h | 1 -
drivers/pinctrl/sh-pfc/gpio.c | 13 +
drivers/pinctrl/sh-pfc/sh_pfc.h | 3 ---
4 files changed, 1 insertion(+), 26 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/core.c b/drivers/pinctrl/sh-pfc/core.c
index 9b9cee06ec59aad3..a3b82041b6a22b13 100644
--- a/drivers/pinctrl/sh-pfc/core.c
+++ b/drivers/pinctrl/sh-pfc/core.c
@@ -598,15 +598,6 @@ static int sh_pfc_probe(struct platform_device *pdev)
return 0;
}
-static int sh_pfc_remove(struct platform_device *pdev)
-{
-#ifdef CONFIG_PINCTRL_SH_PFC_GPIO
- sh_pfc_unregister_gpiochip(platform_get_drvdata(pdev));
-#endif
-
- return 0;
-}
-
static const struct platform_device_id sh_pfc_id_table[] = {
#ifdef CONFIG_PINCTRL_PFC_SH7203
{ "pfc-sh7203", (kernel_ulong_t)_pinmux_info },
@@ -650,7 +641,6 @@ static const struct platform_device_id sh_pfc_id_table[] = {
static struct platform_driver sh_pfc_driver = {
.probe = sh_pfc_probe,
- .remove = sh_pfc_remove,
.id_table = sh_pfc_id_table,
.driver = {
.name = DRV_NAME,
diff --git a/drivers/pinctrl/sh-pfc/core.h b/drivers/pinctrl/sh-pfc/core.h
index 9dde6ea5e28f3a1b..0bbdea5849f41713 100644
--- a/drivers/pinctrl/sh-pfc/core.h
+++ b/drivers/pinctrl/sh-pfc/core.h
@@ -20,7 +20,6 @@ struct sh_pfc_pin_range {
};
int sh_pfc_register_gpiochip(struct sh_pfc *pfc);
-int sh_pfc_unregister_gpiochip(struct sh_pfc *pfc);
int sh_pfc_register_pinctrl(struct sh_pfc *pfc);
diff --git a/drivers/pinctrl/sh-pfc/gpio.c b/drivers/pinctrl/sh-pfc/gpio.c
index 97dff6a09ff08115..6b5422766f13d7f8 100644
--- a/drivers/pinctrl/sh-pfc/gpio.c
+++ b/drivers/pinctrl/sh-pfc/gpio.c
@@ -318,7 +318,7 @@ sh_pfc_add_gpiochip(struct sh_pfc *pfc, int(*setup)(struct
sh_pfc_chip *),
if (ret < 0)
return ERR_PTR(ret);
- ret = gpiochip_add_data(>gpio_chip, chip);
+ ret = devm_gpiochip_add_data(pfc->dev, >gpio_chip, chip);
if (unlikely(ret < 0))
return ERR_PTR(ret);
@@ -399,18 +399,7 @@ int sh_pfc_register_gpiochip(struct sh_pfc *pfc)
chip = sh_pfc_add_gpiochip(pfc, gpio_function_setup, NULL);
if (IS_ERR(chip))
return PTR_ERR(chip);
-
- pfc->func = chip;
#endif /* CONFIG_SUPERH */
return 0;
}
-
-int sh_pfc_unregister_gpiochip(struct sh_pfc *pfc)
-{
- gpiochip_remove(>gpio->gpio_chip);
-#ifdef CONFIG_SUPERH
- gpiochip_remove(>func->gpio_chip);
-#endif
- return 0;
-}
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 5732752667e2654a..5e966c09434d969c 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -207,9 +207,6 @@ struct sh_pfc {
unsigned int nr_gpio_pins;
struct sh_pfc_chip *gpio;
-#ifdef CONFIG_SUPERH
- struct sh_pfc_chip *func;
-#endif
};
struct sh_pfc_soc_operations {
--
1.9.1
[PATCH 2/3] pinctrl: sh-pfc: Improve core and user API separation
The Renesas Pin Function Controller uses two header files:
- sh_pfc.h, for use by both core code and SoC-specific drivers,
- core.h, for internal use by the core code only.
Several SoC-specific drivers include core.h, as they need the sh_pfc
structure, which is passed explicitly to the various SoC-specific
callbacks, and used there.
Hence move its definition from core.h to sh_pfc.h, and remove the
inclusion of core.h from all SoC-specific files.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/pinctrl/sh-pfc/core.h| 33 -
drivers/pinctrl/sh-pfc/pfc-r8a73a4.c | 1 -
drivers/pinctrl/sh-pfc/pfc-r8a7740.c | 1 -
drivers/pinctrl/sh-pfc/pfc-r8a7778.c | 2 +-
drivers/pinctrl/sh-pfc/pfc-r8a7790.c | 1 -
drivers/pinctrl/sh-pfc/pfc-r8a7791.c | 1 -
drivers/pinctrl/sh-pfc/sh_pfc.h | 30 +-
7 files changed, 30 insertions(+), 39 deletions(-)
diff --git a/drivers/pinctrl/sh-pfc/core.h b/drivers/pinctrl/sh-pfc/core.h
index 539ec7dc0b644dbe..9dde6ea5e28f3a1b 100644
--- a/drivers/pinctrl/sh-pfc/core.h
+++ b/drivers/pinctrl/sh-pfc/core.h
@@ -10,48 +10,15 @@
#ifndef __SH_PFC_CORE_H__
#define __SH_PFC_CORE_H__
-#include
-#include
#include
#include "sh_pfc.h"
-struct sh_pfc_window {
- phys_addr_t phys;
- void __iomem *virt;
- unsigned long size;
-};
-
-struct sh_pfc_chip;
-struct sh_pfc_pinctrl;
-
struct sh_pfc_pin_range {
u16 start;
u16 end;
};
-struct sh_pfc {
- struct device *dev;
- const struct sh_pfc_soc_info *info;
- spinlock_t lock;
-
- unsigned int num_windows;
- struct sh_pfc_window *windows;
- unsigned int num_irqs;
- unsigned int *irqs;
-
- struct sh_pfc_pin_range *ranges;
- unsigned int nr_ranges;
-
- unsigned int nr_gpio_pins;
-
- struct sh_pfc_chip *gpio;
-#ifdef CONFIG_SUPERH
- struct sh_pfc_chip *func;
-#endif
-
-};
-
int sh_pfc_register_gpiochip(struct sh_pfc *pfc);
int sh_pfc_unregister_gpiochip(struct sh_pfc *pfc);
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
index d9d9228b15faf6f3..ff5655dee67e5649 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a73a4.c
@@ -21,7 +21,6 @@
#include
#include
-#include "core.h"
#include "sh_pfc.h"
#define CPU_ALL_PORT(fn, pfx, sfx) \
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
index 7f7c8a6e76e88f29..35f436bcb849185a 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7740.c
@@ -22,7 +22,6 @@
#include
#include
-#include "core.h"
#include "sh_pfc.h"
#define CPU_ALL_PORT(fn, pfx, sfx) \
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
index 411d0887ba19bae6..18ef7042b3d1b047 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7778.c
@@ -23,7 +23,7 @@
#include
#include
#include
-#include "core.h"
+
#include "sh_pfc.h"
#define PORT_GP_PUP_1(bank, pin, fn, sfx) \
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
index 1537a0779399772f..b769c05480da681e 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7790.c
@@ -24,7 +24,6 @@
#include
#include
-#include "core.h"
#include "sh_pfc.h"
/*
diff --git a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
index 01abbd5b4e49a783..0c1a60c9a844c7ee 100644
--- a/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
+++ b/drivers/pinctrl/sh-pfc/pfc-r8a7791.c
@@ -11,7 +11,6 @@
#include
-#include "core.h"
#include "sh_pfc.h"
#define CPU_ALL_PORT(fn, sfx) \
diff --git a/drivers/pinctrl/sh-pfc/sh_pfc.h b/drivers/pinctrl/sh-pfc/sh_pfc.h
index 332d379b302cba70..5732752667e2654a 100644
--- a/drivers/pinctrl/sh-pfc/sh_pfc.h
+++ b/drivers/pinctrl/sh-pfc/sh_pfc.h
@@ -13,6 +13,7 @@
#include
#include
+#include
#include
enum {
@@ -182,7 +183,34 @@ struct pinmux_range {
u16 force;
};
-struct sh_pfc;
+struct sh_pfc_window {
+ phys_addr_t phys;
+ void __iomem *virt;
+ unsigned long size;
+};
+
+struct sh_pfc_pin_range;
+
+struct sh_pfc {
+ struct device *dev;
+ const struct sh_pfc_soc_info *info;
+ spinlock_t lock;
+
+ unsigned int num_windows;
+ struct sh_pfc_window *windows;
+ unsigned int num_irqs;
+ unsigned int *irqs;
+
+ struct sh_pfc_pin_range *ranges;
+ unsigned int nr_ranges;
+
+ unsigned int nr_gpio_pins;
+
+ struct sh_pfc_chip *gpio;
+#ifdef CONFIG_SUPERH
+ struct sh_pfc_chip *func;
+#endif
+};
struct sh_pfc_soc_operations {
int (*init)(struct sh_pfc *pfc);
--
1.9.1
[PATCH] arm64: dts: r8a7795: Add missing blank lines between cpu nodes
For consistency with a57_0/a57_1 cpu nodes, and all other nodes.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm64/boot/dts/renesas/r8a7795.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
index fca68d7b047dfa1d..2edc38a0d0ae7f38 100644
--- a/arch/arm64/boot/dts/renesas/r8a7795.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7795.dtsi
@@ -53,6 +53,7 @@
next-level-cache = <_CA57>;
enable-method = "psci";
};
+
a57_2: cpu@2 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x2>;
@@ -61,6 +62,7 @@
next-level-cache = <_CA57>;
enable-method = "psci";
};
+
a57_3: cpu@3 {
compatible = "arm,cortex-a57","arm,armv8";
reg = <0x3>;
--
1.9.1
Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree
Hi Sergei,
On Fri, Jun 10, 2016 at 9:29 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
>The only problem I'm seeing (again) is the RCAN clock failing to
> register:
>
> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>
>I was going to look at it yesterday but (wrongly) thought it somehow
> cured itself... I'll look at it now.
The RCAN parent is the second clock in the CPG node's "clocks" property,
which you didn't provide.
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 0/3] pinctrl: sh-pfc: add r8a7795 support for voltage switching
Hi Wolfram,
On Mon, Jun 6, 2016 at 6:08 PM, Wolfram Sang <w...@the-dreams.de> wrote:
> This series adds support for PFC voltage switching for r8a7795. I decided to
> refactor voltage switching because all Gen2 and Gen3 hardware follow the same
> style to do that. So, we can put generic handling to the core and keep only
> pin-to-bit mapping SoC specific. See patch 1 for details.
>
> Tested on a Lager board (r8a7790/H2) and a Salvator-X (r8a7795/H3) by using
> UHS/non-UHS SD cards. They work fine with SDR50 and the POCCTRL register
> setting was also verified.
>
> Branch is here:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git
> renesas/topic/h3-pfc-set-voltage
>
> Changes since RFC:
> * be precise in encoding which pins can do voltage switching on bank3
> * addded Geert's reviewed tag (thanks!)
>
> Please apply,
>
>Wolfram
>
> Wolfram Sang (3):
> pinctrl: sh-pfc: refactor voltage setting
> pinctrl: sh-pfc: r8a7795: add support for voltage switching
> arm64: dts: r8a7795: salvator: enable UHS for SDHI 0 & 3
Thanks for your series!
I've queued the first two patches in sh-pfc-for-v4.8, and will send a pull
request after next renesas-drivers release.
BTW, are these a hard dependency for patch 3, or will the missing power
source control just be ignored?
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: r8a7795: Provide FDP1 clocks
Hi Kieran,
On Thu, Jun 9, 2016 at 6:12 PM, Kieran Bingham <kie...@bingham.xyz> wrote:
> Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
> Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
> Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
> ---
> drivers/clk/renesas/r8a7795-cpg-mssr.c | 3 +++
> 1 file changed, 3 insertions(+)
Thanks queued in clk-renesas-for-v4.8.
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/2] arm64: dts: r8a7795: add FCPF device nodes
On Thu, Jun 9, 2016 at 6:56 PM, Kieran Bingham <kie...@ksquared.org.uk> wrote:
> Provide nodes for the FCP devices dedicated to the FDP device channels.
>
> Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
Reviewed-by: Geert Uytterhoeven <geert+rene...@glider.be>
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] clk: renesas: r8a7795: Correct lvds clock parent
According to the latest information, the parent clock of the LVDS module
clock is the S0D4 clock, not the S2D1 clock.
Note that this change has no influence on actual operation, as the
rcar-du LVDS encoder driver doesn't use the parent clock's rate.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
Will queue in clk-renesas-for-v4.8.
drivers/clk/renesas/r8a7795-cpg-mssr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/renesas/r8a7795-cpg-mssr.c
b/drivers/clk/renesas/r8a7795-cpg-mssr.c
index 8f76af6f454d0823..ad01b0b1bc5fa172 100644
--- a/drivers/clk/renesas/r8a7795-cpg-mssr.c
+++ b/drivers/clk/renesas/r8a7795-cpg-mssr.c
@@ -180,7 +180,7 @@ static const struct mssr_mod_clk r8a7795_mod_clks[]
__initconst = {
DEF_MOD("du2", 722, R8A7795_CLK_S2D1),
DEF_MOD("du1", 723, R8A7795_CLK_S2D1),
DEF_MOD("du0", 724, R8A7795_CLK_S2D1),
- DEF_MOD("lvds", 727, R8A7795_CLK_S2D1),
+ DEF_MOD("lvds", 727, R8A7795_CLK_S0D4),
DEF_MOD("hdmi1", 728, R8A7795_CLK_HDMI),
DEF_MOD("hdmi0", 729, R8A7795_CLK_HDMI),
DEF_MOD("vin7", 804, R8A7795_CLK_S2D1),
--
1.9.1
Re: [PATCH/RFC v3 01/22] reset: Add renesas,rst DT bindings
Hi Laurent,
On Thu, Jun 2, 2016 at 11:47 PM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/reset/renesas,rst.txt
>> @@ -0,0 +1,35 @@
>> +DT bindings for the Renesas R-Car Reset Controller
>> +
>> +The R-Car Reset Controller provides reset control, and implements the
>> following
>> +functions:
>> + - Latching of the levels on mode pins when PRESET# is negated,
>> + - Mode monitoring register,
>> + - Reset control of peripheral devices (on R-Car Gen1),
>> + - Watchdog timer (on R-Car Gen1).
>> + - Register-based reset control and boot address registers for the various
>> CPU
>> +cores (on R-Car Gen2/Gen3),
>> +
>> +
>> +Required properties:
>> + - compatible: Should be
>> + - "renesas,-reset-wdt" for R-Car Gen1,
>> + - "renesas,-rst" for R-Car Gen2/Gen3.
>> + Examples with soctypes are:
>> + - "renesas,r8a7778-reset-wdt" (R-Car M1A)
>> + - "renesas,r8a7779-reset-wdt" (R-Car H1)
>> + - "renesas,r8a7790-rst" (R-Car H2)
>> + - "renesas,r8a7791-rst" (R-Car M2-W)
>> + - "renesas,r8a7792-rst" (R-Car V2H
>> + - "renesas,r8a7793-rst" (R-Car M2-N)
>> + - "renesas,r8a7794-rst" (R-Car E2)
>> + - "renesas,r8a7795-rst" (R-Car H3)
>> + - "renesas,r8a7796-rst" (R-Car M3-W)
>
> Any specific reason for such a large indentation ? (I know this is really
> nitpicking)
To align the two paragraphs and lists.
> Apart from that, it's just a bit of a shame we can't have generic compatible
> strings, but that would require additional DT properties to describe the reset
> controller features, and I assume that's not a path we want to take.
The reset controller is one of the few blocks that really differs
between members
of the same family, due to the relationship with the various CPU cores.
> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
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/RFC v3 02/22] soc: renesas: Add R-Car RST driver
Hi Laurent,
On Thu, Jun 2, 2016 at 11:58 PM, Laurent Pinchart
<laurent.pinch...@ideasonboard.com> wrote:
>> --- /dev/null
>> +++ b/drivers/soc/renesas/rcar-rst.c
>> +static int __init rcar_rst_init(void)
>> +{
[...]
>> +}
>> +arch_initcall(rcar_rst_init);
>
> Given that rcar_rst_init() is only used as a support function for
> rcar_rst_read_mode_pins(), how about removing the initcall ?
Thanks, good idea!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH/RFC v3 02/22] soc: renesas: Add R-Car RST driver
Hi Dirk,
On Thu, Jun 2, 2016 at 7:42 AM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
>> +int __init rcar_rst_read_mode_pins(u32 *mode)
>
> Just a style issue: Is the string 'pins' in the function name still
> relevant? I.e. what's about just 'rcar_rst_read_mode()'?
I feel "mode" is a too generic word for a public API.
It's used a several contexts inside the RST module (secure mode, 64-bit
addressing mode, free-running mode, step-up mode).
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 v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3
Hi Magnus,
On Thu, Jun 2, 2016 at 5:55 PM, Magnus Damm <magnus.d...@gmail.com> wrote:
> iommu/ipmmu-vmsa: IPMMU multi-arch update V3
>
> [PATCH v3 01/06] iommu/ipmmu-vmsa: Remove platform data handling
> [PATCH v3 02/06] iommu/ipmmu-vmsa: Rework interrupt code and use bitmap for
> context
> [PATCH v3 03/06] iommu/ipmmu-vmsa: Break out utlb parsing code
> [PATCH v3 04/06] iommu/ipmmu-vmsa: Break out domain allocation code
> [PATCH v3 05/06] iommu/ipmmu-vmsa: Add new IOMMU_DOMAIN_DMA ops
> [PATCH v3 06/06] iommu/ipmmu-vmsa: Drop LPAE Kconfig dependency
>
> These patches update the IPMMU driver with a couple of changes
> to support build on multiple architectures. In the process of
> doing so the interrupt code gets reworked and the foundation
> for supporting multiple contexts are added.
>
> In this version of the series the patch order has been reworked
> to make simplify review. Thanks to Laurent for his suggestions!
>
> The 32-bit ARM logic has intentionally been changed as little as possible
> to avoid breakage. Once CONFIG_IOMMU_DMA can be used it may be good time
> to revisit the init ordering for the 32-bit SoCs. There is room for
> improvement for sure like Robin Murphy kindly pointed out.
>
> Changes since V2:
> - Got rid of patch 3 from the V2 however patch 1, 2 and 4 are kept.
> - V3 patch 3, 4 and 5 come from
>[PATCH 00/04] iommu/ipmmu-vmsa: IPMMU CONFIG_IOMMU_DMA update
> - Patch 5 has been reworked to include patch 3 of the V1 of this series
>
> Changes since V1:
> - Got rid of patch 2 and 3 from initial series
> - Updated bitmap code locking and also used lighter bitop functions
> - Updated the Kconfig bits to apply on top of ARCH_RENESAS
>
> Signed-off-by: Magnus Damm <damm+rene...@opensource.se>
Thanks for your series!
For your convenience, I've queued it up in topic/ipmmu-multi-arch-v3 at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git, and
will include it in next renesas-drivers release.
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 v3 07/11] serial: sh-sci: Add more Serial Port Control/Data Register documentation
Improve documentation for the SCIFA/SCIFB Serial Port Control and Data
Registers:
- State clearly that the RTS and CTS lines are active-low,
- Document the bits related to the serial port's SCK, RXD, and TXD
pins.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
---
v3:
- Add Reviewed-by,
v2:
- New.
---
drivers/tty/serial/sh-sci.h | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.h b/drivers/tty/serial/sh-sci.h
index 85a2b81ba0a845e5..e7d2bc692a581e9e 100644
--- a/drivers/tty/serial/sh-sci.h
+++ b/drivers/tty/serial/sh-sci.h
@@ -121,12 +121,18 @@ enum {
#define HSCIF_SRE BIT(15) /* Sampling Rate Register Enable */
/* SCPCR (Serial Port Control Register), SCIFA/SCIFB only */
-#define SCPCR_RTSC BIT(4) /* Serial Port RTS Pin / Output Pin */
-#define SCPCR_CTSC BIT(3) /* Serial Port CTS Pin / Input Pin */
+#define SCPCR_RTSC BIT(4) /* Serial Port RTS# Pin / Output Pin */
+#define SCPCR_CTSC BIT(3) /* Serial Port CTS# Pin / Input Pin */
+#define SCPCR_SCKC BIT(2) /* Serial Port SCK Pin / Output Pin */
+#define SCPCR_RXDC BIT(1) /* Serial Port RXD Pin / Input Pin */
+#define SCPCR_TXDC BIT(0) /* Serial Port TXD Pin / Output Pin */
/* SCPDR (Serial Port Data Register), SCIFA/SCIFB only */
-#define SCPDR_RTSD BIT(4) /* Serial Port RTS Output Pin Data */
-#define SCPDR_CTSD BIT(3) /* Serial Port CTS Input Pin Data */
+#define SCPDR_RTSD BIT(4) /* Serial Port RTS# Output Pin Data */
+#define SCPDR_CTSD BIT(3) /* Serial Port CTS# Input Pin Data */
+#define SCPDR_SCKD BIT(2) /* Serial Port SCK Output Pin Data */
+#define SCPDR_RXDD BIT(1) /* Serial Port RXD Input Pin Data */
+#define SCPDR_TXDD BIT(0) /* Serial Port TXD Output Pin Data */
/*
* BRG Clock Select Register (Some SCIF and HSCIF)
--
1.9.1
[PATCH v3 03/11] serial: sh-sci: Always set TIOCM_CTS in .get_mctrl() callback
Documentation/serial/driver clearly states:
If the port does not support CTS, DCD or DSR, the driver should
indicate that the signal is permanently active.
Hence always set TIOCM_CTS, as we currently don't look at the CTS
hardware line state at all.
FWIW, this fixes the transmit path when hardware-assisted flow control
is enabled, and userspace enables CRTSCTS.
The receive path is still broken, as RTS is never asserted.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
---
v3:
- Add Reviewed-by,
v2:
- Drop RFC status.
---
drivers/tty/serial/sh-sci.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 0130feb069aee02f..135f836642ab1c5a 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1835,9 +1835,9 @@ static unsigned int sci_get_mctrl(struct uart_port *port)
{
/*
* CTS/RTS is handled in hardware when supported, while nothing
-* else is wired up. Keep it simple and simply assert DSR/CAR.
+* else is wired up. Keep it simple and simply assert CTS/DSR/CAR.
*/
- return TIOCM_DSR | TIOCM_CAR;
+ return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
}
static void sci_break_ctl(struct uart_port *port, int break_state)
--
1.9.1
[PATCH v3 05/11] serial: sh-sci: Do not open-code sci_getreg()
Replace open-coded variants of sci_getreg() by function calls, and drop
intermediate variables where appropriate.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
---
v3:
- Add Reviewed-by,
v2:
- New.
---
drivers/tty/serial/sh-sci.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index bf3780a7f700cad8..ce7bd165929ea078 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -703,7 +703,6 @@ static void sci_poll_put_char(struct uart_port *port,
unsigned char c)
static void sci_init_pins(struct uart_port *port, unsigned int cflag)
{
struct sci_port *s = to_sci_port(port);
- const struct plat_sci_reg *reg = sci_regmap[s->cfg->regtype] + SCSPTR;
/*
* Use port-specific handler if provided.
@@ -717,7 +716,7 @@ static void sci_init_pins(struct uart_port *port, unsigned
int cflag)
* For the generic path SCSPTR is necessary. Bail out if that's
* unavailable, too.
*/
- if (!reg->size)
+ if (!sci_getreg(port, SCSPTR)->size)
return;
if ((s->cfg->capabilities & SCIx_HAVE_RTSCTS) &&
@@ -1866,12 +1865,10 @@ static void sci_enable_ms(struct uart_port *port)
static void sci_break_ctl(struct uart_port *port, int break_state)
{
- struct sci_port *s = to_sci_port(port);
- const struct plat_sci_reg *reg = sci_regmap[s->cfg->regtype] + SCSPTR;
unsigned short scscr, scsptr;
/* check wheter the port has SCSPTR */
- if (!reg->size) {
+ if (!sci_getreg(port, SCSPTR)->size) {
/*
* Not supported by hardware. Most parts couple break and rx
* interrupts together, with break detection always enabled.
--
1.9.1
[PATCH v3 06/11] serial: sh-sci: Add more Serial Port Register documentation
Improve documentation for the (H)SCIF Serial Port Register:
- Make it clear the RTS and CTS lines are active-low,
- Document the bits related to the serial port's clock pin.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
---
v3:
- Add Reviewed-by,
v2:
- New.
---
drivers/tty/serial/sh-sci.h | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.h b/drivers/tty/serial/sh-sci.h
index 7a4fa185b93ef307..85a2b81ba0a845e5 100644
--- a/drivers/tty/serial/sh-sci.h
+++ b/drivers/tty/serial/sh-sci.h
@@ -108,10 +108,12 @@ enum {
#define SCLSR_ORER BIT(0) /* Overrun Error */
/* SCSPTR (Serial Port Register), optional */
-#define SCSPTR_RTSIO BIT(7) /* Serial Port RTS Pin Input/Output */
-#define SCSPTR_RTSDT BIT(6) /* Serial Port RTS Pin Data */
-#define SCSPTR_CTSIO BIT(5) /* Serial Port CTS Pin Input/Output */
-#define SCSPTR_CTSDT BIT(4) /* Serial Port CTS Pin Data */
+#define SCSPTR_RTSIO BIT(7) /* Serial Port RTS# Pin Input/Output */
+#define SCSPTR_RTSDT BIT(6) /* Serial Port RTS# Pin Data */
+#define SCSPTR_CTSIO BIT(5) /* Serial Port CTS# Pin Input/Output */
+#define SCSPTR_CTSDT BIT(4) /* Serial Port CTS# Pin Data */
+#define SCSPTR_SCKIO BIT(3) /* Serial Port Clock Pin Input/Output */
+#define SCSPTR_SCKDT BIT(2) /* Serial Port Clock Pin Data */
#define SCSPTR_SPB2IO BIT(1) /* Serial Port Break Input/Output */
#define SCSPTR_SPB2DT BIT(0) /* Serial Port Break Data */
--
1.9.1
[PATCH v3 00/11] serial: sh-sci: Hardware Flow Control Updates
Hi Greg, Jiri, Peter,
This patch series contains updates to the Renesas SCI UART driver,
related to hardware flow control:
- Patches 1-2: Device Tree binding updates for GPIO-controlled modem
lines, and for dedicated RTS/CTS modem lines,
- Patches 3-4: Driver support for GPIO-controlled modem lines, using
the serial_mctrl_gpio helpers,
- New patches 5-11: Driver support for hardware-assisted (automatic)
hardware flow control, using the dedicated RTS/CTS modem lines.
Changes compared to v2:
- No code changes,
- Add Acked-by, Reviewed-by.
Changes compared to v1 (more details in the individual patches):
- Add Acked-by,
- Refer to the Generic Serial DT Bindings,
- Drop out[12]-gpios,
- Reject combining GPIO and dedicated RTS/CTS,
- Drop "serial: sh-sci: Replace SCIx_HAVE_RTSCTS by standard
UPF_HARD_FLOW",
- Add support for hardware-assisted automatic RTS/CTS control on
(H)SCIF, SCIFA, and SCIFB.
Dependencies:
- The patches apply to v4.7-rc1 and next-20160603.
This was tested on r8a7791/koelsch and r8a7740/armadillo, using UARTs
and GPIO pins on expansion connectors.
Expected behavior, using GPIO-based RTS/CTS as a reference:
- When CRTSCTS is disabled:
- Reading from a UART asserts the RTS line,
- Writing to a UART asserts the RTS line.
- When CRTSCTS is enabled:
- Reading from a UART asserts the RTS line,
- Writing to a UART asserts the RTS line.
- Writing is blocked until CTS is asserted.
Hardware-assisted hardware flow control with HSCIF and SCIFB on
r8a7791/koelsch behaves as expected when dedicated RTS/CTS modem lines
are enabled (beware the large transmission FIFOs on SCIFB ;-)
For SCIFA on r8a7740/armadillo, manually overriding (asserting) the RTS
signal doesn't seem to work. Hence when CRTSCTS is disabled, RTS is
never asserted. When CRTSCTS is enabled, hardware-assisted RTS/CTS does
control RTS as expected. As SCIFA on r8a7791 doesn't have dedicated
RTS/CTS modem lines, I cannot compare.
DT overlays for testing can be found in the topic/renesas-overlays
branch of
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git.
Regression testing on platforms without DT and/or GPIOLIB support
(SuperH) would be appreciated.
Compile-tested on ecovec24_defconfig(GPIOLIB=y) and se7780_defconfig
(GPIOLIB=n).
Please apply, thanks!
Geert Uytterhoeven (11):
serial: sh-sci: Update DT binding documentation for GPIO modem lines
serial: sh-sci: Update DT binding documentation for dedicated RTS/CTS
serial: sh-sci: Always set TIOCM_CTS in .get_mctrl() callback
serial: sh-sci: Add support for GPIO-controlled modem lines
serial: sh-sci: Do not open-code sci_getreg()
serial: sh-sci: Add more Serial Port Register documentation
serial: sh-sci: Add more Serial Port Control/Data Register
documentation
serial: sh-sci: Correct pin initialization on (H)SCIF
serial: sh-sci: Add pin initialization for SCIFA/SCIFB
serial: sh-sci: Fix support for hardware-assisted RTS/CTS
serial: sh-sci: Add DT support for dedicated RTS/CTS
.../bindings/serial/renesas,sci-serial.txt | 4 +
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/sh-sci.c| 177 ++---
drivers/tty/serial/sh-sci.h| 24 ++-
4 files changed, 173 insertions(+), 33 deletions(-)
--
1.9.1
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 v3 08/11] serial: sh-sci: Correct pin initialization on (H)SCIF
Correct pin initialization on (H)SCIF:
- RTS must be deasserted (it's active low),
- SCK must be an input, as it may be used as the optional external
clock input.
Initial pin configuration must always be done:
- Regardless of the presence of dedicated RTS and CTS pins: if the
register exists, the RTS/CTS bits exist, too,
- Regardless of hardware flow control being enabled or not: RTS must
be deasserted.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
v3:
- No changes,
v2:
- New.
---
drivers/tty/serial/sh-sci.c | 23 ---
1 file changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index ce7bd165929ea078..c46999f20917964e 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -712,21 +712,14 @@ static void sci_init_pins(struct uart_port *port,
unsigned int cflag)
return;
}
- /*
-* For the generic path SCSPTR is necessary. Bail out if that's
-* unavailable, too.
-*/
- if (!sci_getreg(port, SCSPTR)->size)
- return;
-
- if ((s->cfg->capabilities & SCIx_HAVE_RTSCTS) &&
- ((!(cflag & CRTSCTS {
- unsigned short status;
-
- status = serial_port_in(port, SCSPTR);
- status &= ~SCSPTR_CTSIO;
- status |= SCSPTR_RTSIO;
- serial_port_out(port, SCSPTR, status); /* Set RTS = 1 */
+ if (sci_getreg(port, SCSPTR)->size) {
+ u16 status = serial_port_in(port, SCSPTR);
+
+ /* RTS# is output, driven 1 */
+ status |= SCSPTR_RTSIO | SCSPTR_RTSDT;
+ /* CTS# and SCK are inputs */
+ status &= ~(SCSPTR_CTSIO | SCSPTR_SCKIO);
+ serial_port_out(port, SCSPTR, status);
}
}
--
1.9.1
[PATCH v3 09/11] serial: sh-sci: Add pin initialization for SCIFA/SCIFB
Before, the driver relied on initialization by the boot loader, or by
implicit reset state.
Note that unlike on (H)SCIF, the RTS/CTS bits exist only if dedicated
RTS/CTS pins are available, which depends on the SoC and UART instance.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
v3:
- No changes,
v2:
- New.
---
drivers/tty/serial/sh-sci.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index c46999f20917964e..b9d027af0f3e71f6 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -712,7 +712,21 @@ static void sci_init_pins(struct uart_port *port, unsigned
int cflag)
return;
}
- if (sci_getreg(port, SCSPTR)->size) {
+ if (port->type == PORT_SCIFA || port->type == PORT_SCIFB) {
+ u16 ctrl = serial_port_in(port, SCPCR);
+
+ /* Enable RXD and TXD pin functions */
+ ctrl &= ~(SCPCR_RXDC | SCPCR_TXDC);
+ if (to_sci_port(port)->cfg->capabilities & SCIx_HAVE_RTSCTS) {
+ /* RTS# is output, driven 1 */
+ ctrl |= SCPCR_RTSC;
+ serial_port_out(port, SCPDR,
+ serial_port_in(port, SCPDR) | SCPDR_RTSD);
+ /* Enable CTS# pin function */
+ ctrl &= ~SCPCR_CTSC;
+ }
+ serial_port_out(port, SCPCR, ctrl);
+ } else if (sci_getreg(port, SCSPTR)->size) {
u16 status = serial_port_in(port, SCSPTR);
/* RTS# is output, driven 1 */
--
1.9.1
[PATCH v3 11/11] serial: sh-sci: Add DT support for dedicated RTS/CTS
Add support for indicating the availability of dedicated lines for RTS/CTS hardware flow control, using the standard "uart-has-rtscts" DT property. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- v3: - No changes, v2: - New. --- drivers/tty/serial/sh-sci.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index 02b240a02dc6a593..d9cb0d70fceef07d 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -2999,6 +2999,9 @@ sci_parse_dt(struct platform_device *pdev, unsigned int *dev_id) p->regtype = SCI_OF_REGTYPE(match->data); p->scscr = SCSCR_RE | SCSCR_TE; + if (of_find_property(np, "uart-has-rtscts", NULL)) + p->capabilities |= SCIx_HAVE_RTSCTS; + return p; } -- 1.9.1
[PATCH v3 04/11] serial: sh-sci: Add support for GPIO-controlled modem lines
Enhance the Renesas SCI UART driver to add support for GPIO-controlled
modem lines (CTS, DSR, DCD, RNG, RTS, DTR), using the serial_mctrl_gpio
helpers.
GPIO-controlled modem lines can be used when dedicated modem lines are
not available. Invalid configurations specifying both GPIO RTS/CTS and
dedicated RTS/CTS are rejected.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Reviewed-by: Peter Hurley <pe...@hurleysoftware.com>
---
Testing for regressions on platforms without DT and/or GPIOLIB support
(SuperH) would be appreciated.
Compile-tested on ecovec24_defconfig(GPIOLIB=y) and se7780_defconfig
(GPIOLIB=n).
v3:
- Add Reviewed-by,
v2:
- Drop RFC status.
- Fix typo s/UART_GPIO_CAR/UART_GPIO_DCD/ (too many different names
for the same thing: CAR, DCD, CD),
- Drop OUT[12] from the patch description,
- Use intermediate variables to avoid breaking long lines,
- Reject combining GPIO and dedicated RTS/CTS.
---
drivers/tty/serial/Kconfig | 1 +
drivers/tty/serial/sh-sci.c | 46 -
2 files changed, 46 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 7e3a58c8bb67cd80..b5c8ad1573f4416d 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -736,6 +736,7 @@ config SERIAL_SH_SCI
tristate "SuperH SCI(F) serial port support"
depends on SUPERH || ARCH_RENESAS || H8300 || COMPILE_TEST
select SERIAL_CORE
+ select SERIAL_MCTRL_GPIO if GPIOLIB
config SERIAL_SH_SCI_NR_UARTS
int "Maximum number of SCI(F) serial ports"
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 135f836642ab1c5a..bf3780a7f700cad8 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -57,6 +57,7 @@
#include
#endif
+#include "serial_mctrl_gpio.h"
#include "sh-sci.h"
/* Offsets into the sci_port->irqs array */
@@ -111,6 +112,7 @@ struct sci_port {
unsigned interror_clear;
unsigned intsampling_rate_mask;
resource_size_t reg_size;
+ struct mctrl_gpios *gpios;
/* Break timer */
struct timer_list break_timer;
@@ -1817,6 +1819,8 @@ static unsigned int sci_tx_empty(struct uart_port *port)
*/
static void sci_set_mctrl(struct uart_port *port, unsigned int mctrl)
{
+ struct sci_port *s = to_sci_port(port);
+
if (mctrl & TIOCM_LOOP) {
const struct plat_sci_reg *reg;
@@ -1829,15 +1833,35 @@ static void sci_set_mctrl(struct uart_port *port,
unsigned int mctrl)
serial_port_in(port, SCFCR) |
SCFCR_LOOP);
}
+
+ mctrl_gpio_set(s->gpios, mctrl);
}
static unsigned int sci_get_mctrl(struct uart_port *port)
{
+ struct sci_port *s = to_sci_port(port);
+ struct mctrl_gpios *gpios = s->gpios;
+ unsigned int mctrl = 0;
+
+ mctrl_gpio_get(gpios, );
+
/*
* CTS/RTS is handled in hardware when supported, while nothing
* else is wired up. Keep it simple and simply assert CTS/DSR/CAR.
*/
- return TIOCM_CTS | TIOCM_DSR | TIOCM_CAR;
+ if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_CTS)))
+ mctrl |= TIOCM_CTS;
+ if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DSR)))
+ mctrl |= TIOCM_DSR;
+ if (IS_ERR_OR_NULL(mctrl_gpio_to_gpiod(gpios, UART_GPIO_DCD)))
+ mctrl |= TIOCM_CAR;
+
+ return mctrl;
+}
+
+static void sci_enable_ms(struct uart_port *port)
+{
+ mctrl_gpio_enable_ms(to_sci_port(port)->gpios);
}
static void sci_break_ctl(struct uart_port *port, int break_state)
@@ -1899,6 +1923,8 @@ static void sci_shutdown(struct uart_port *port)
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
+ mctrl_gpio_disable_ms(to_sci_port(port)->gpios);
+
spin_lock_irqsave(>lock, flags);
sci_stop_rx(port);
sci_stop_tx(port);
@@ -2300,6 +2326,9 @@ done:
sci_start_rx(port);
sci_port_disable(s);
+
+ if (UART_ENABLE_MS(port, termios->c_cflag))
+ sci_enable_ms(port);
}
static void sci_pm(struct uart_port *port, unsigned int state,
@@ -2425,6 +2454,7 @@ static struct uart_ops sci_uart_ops = {
.start_tx = sci_start_tx,
.stop_tx= sci_stop_tx,
.stop_rx= sci_stop_rx,
+ .enable_ms = sci_enable_ms,
.break_ctl = sci_break_ctl,
.startup= sci_startup,
.shutdown = sci_shutdown,
@@ -2912,6 +2942,20 @@ static int sci_probe_single(struct platform_device *dev,
if (ret)
return ret;
+ sciport->gpios = mctrl_gpio_init(>port, 0);
+ if (IS_ERR(sciport->gpios) && PTR
[PATCH/RFC] ARM: shmobile: rcar-gen2: Correct arch timer frequency on R-Car V2H
According to the datasheet, the frequency of the ARM architecture timer
on R-Car V2H depends on the frequency of the ZS clock, just like on
R-Car E2.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
Against renesas-devel-20160613-v4.7-rc3 with "ARM: shmobile: rcar-gen2:
Obtain extal frequency from DT" applied.
Untested due to lack of hardware.
---
arch/arm/mach-shmobile/setup-rcar-gen2.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c
b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index ea092d5dd475042d..afb9fdcd3d9084e2 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -76,7 +76,8 @@ void __init rcar_gen2_timer_init(void)
void __iomem *base;
u32 freq;
- if (of_machine_is_compatible("renesas,r8a7794")) {
+ if (of_machine_is_compatible("renesas,r8a7792") ||
+ of_machine_is_compatible("renesas,r8a7794")) {
freq = 26000 / 8; /* ZS / 8 */
/* CNTVOFF has to be initialized either from non-secure
* Hypervisor mode or secure Monitor mode with SCR.NS==1.
--
1.9.1
Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree
Hi Sergei,
On Fri, Jun 10, 2016 at 10:50 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> On 06/10/2016 11:42 PM, Geert Uytterhoeven wrote:
>>>The only problem I'm seeing (again) is the RCAN clock failing to
>>> register:
>>>
>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock (-12)
>>>
>>>I was going to look at it yesterday but (wrongly) thought it somehow
>>> cured itself... I'll look at it now.
>>
>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>> which you didn't provide.
>
>Actually, the things are more complex. The figure 7.1c suggests that the
> RCAN clock has different parent on R8A7792 than on the other SoCs -- namely
> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
> SoC (it doesn't seem to support any USB IPs). Which means the
> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current form.
Right, I had forgotten about that.
Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case ;-)
it seems the RCAN clock can just be modeled as a fixed clock. However,
its divider value isn't clear to me, as 15.9 MHz cannot be generated from PLL1
using an integer divider. Morimoto-san, can you please ask for clarification?
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] ARM: shmobile: rcar-gen2: Obtain extal frequency from DT
On some R-Car Gen2 SoCs, the frequency of the ARM architecture timer
depends on the frequency of the external clock crystal. Currently the
latter is determined indirectly from the state of the mode pins, which
is a relic predating DT.
Obtain the external clock crystal frequency from DT instead, removing
the dependency on the mode pins.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
Against renesas-devel-20160613-v4.7-rc3.
Tested on r8a7790/lager and r8a7791/koelsch.
---
arch/arm/mach-shmobile/setup-rcar-gen2.c | 42 +---
1 file changed, 22 insertions(+), 20 deletions(-)
diff --git a/arch/arm/mach-shmobile/setup-rcar-gen2.c
b/arch/arm/mach-shmobile/setup-rcar-gen2.c
index 1c6fd11c2f824019..ea092d5dd475042d 100644
--- a/arch/arm/mach-shmobile/setup-rcar-gen2.c
+++ b/arch/arm/mach-shmobile/setup-rcar-gen2.c
@@ -46,6 +46,26 @@ u32 rcar_gen2_read_mode_pins(void)
return mode;
}
+static unsigned int __init get_extal_freq(void)
+{
+ struct device_node *cpg, *extal;
+ u32 freq = 2000;
+
+ cpg = of_find_compatible_node(NULL, NULL,
+ "renesas,rcar-gen2-cpg-clocks");
+ if (!cpg)
+ return freq;
+
+ extal = of_parse_phandle(cpg, "clocks", 0);
+ of_node_put(cpg);
+ if (!extal)
+ return freq;
+
+ of_property_read_u32(extal, "clock-frequency", );
+ of_node_put(extal);
+ return freq;
+}
+
#define CNTCR 0
#define CNTFID0 0x20
@@ -54,7 +74,6 @@ void __init rcar_gen2_timer_init(void)
u32 mode = rcar_gen2_read_mode_pins();
#ifdef CONFIG_ARM_ARCH_TIMER
void __iomem *base;
- int extal_mhz = 0;
u32 freq;
if (of_machine_is_compatible("renesas,r8a7794")) {
@@ -82,26 +101,9 @@ void __init rcar_gen2_timer_init(void)
* with the counter disabled. Moreover, it may also report
* a potentially incorrect fixed 13 MHz frequency. To be
* correct these registers need to be updated to use the
-* frequency EXTAL / 2 which can be determined by the MD pins.
+* frequency EXTAL / 2.
*/
-
- switch (mode & (MD(14) | MD(13))) {
- case 0:
- extal_mhz = 15;
- break;
- case MD(13):
- extal_mhz = 20;
- break;
- case MD(14):
- extal_mhz = 26;
- break;
- case MD(13) | MD(14):
- extal_mhz = 30;
- break;
- }
-
- /* The arch timer frequency equals EXTAL / 2 */
- freq = extal_mhz * (100 / 2);
+ freq = get_extal_freq() / 2;
}
/* Remap "armgcnt address map" space */
--
1.9.1
Re: [PATCH] pinctrl: sh-pfc: fix property name in bindings doc
Hi Linus,
On Tue, Jun 14, 2016 at 9:04 AM, Linus Walleij <linus.wall...@linaro.org> wrote:
> On Fri, Jun 10, 2016 at 5:11 PM, Wolfram Sang <w...@the-dreams.de> wrote:
>
>> From: Wolfram Sang <wsa+rene...@sang-engineering.com>
>>
>> It must be "drive-strength", with a hyphen.
>>
>> Signed-off-by: Wolfram Sang <wsa+rene...@sang-engineering.com>
>
> Geert are you queuing this too?
Sure.
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: [git pull] clk: renesas: Add support for R-Car M3-W
On Mon, Jun 6, 2016 at 1:33 PM, Geert Uytterhoeven
<geert+rene...@glider.be> wrote:
> The following changes since commit 1a695a905c18548062509178b98bc91e67510864:
>
> Linux 4.7-rc1 (2016-05-29 09:29:24 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
> tags/clk-renesas-for-v4.8-tag1
>
> for you to fetch changes up to e4e2d7c388350eba8b1dbc2569441ac9b545a8c4:
>
> clk: renesas: cpg-mssr: Add support for R-Car M3-W (2016-06-06 11:58:35
> +0200)
>
>
> clk: renesas: Add support for R-Car M3-W
>
> Add initial support for the Clock Pulse Generator and Module Standby and
> Software Reset modules on the Renesas R-Car M3-W SoC:
> - Basic core clocks,
> - SCIF2 (console) module clock,
> - INTC-AP (GIC) module clock.
>
> As is a hard dependency for the
> initial r8a7796.dtsi file, I would appreciate if you could pull this
> sooner rather than later, so Simon can pull it as well, and start
> queueing up the DT files for R-Car M3-W.
>
> Thanks for pulling!
Ping?
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: Boot failure on emev2/kzm9d (was: Re: [PATCH v2 11/11] mm/slab: lockless decision to grow cache)
Hi Jonsoo,
On Mon, Jun 13, 2016 at 9:43 PM, Geert Uytterhoeven
<ge...@linux-m68k.org> wrote:
> On Tue, Apr 12, 2016 at 6:51 AM, <js1...@gmail.com> wrote:
>> From: Joonsoo Kim <iamjoonsoo@lge.com>
>> To check whther free objects exist or not precisely, we need to grab a
>> lock. But, accuracy isn't that important because race window would be
>> even small and if there is too much free object, cache reaper would reap
>> it. So, this patch makes the check for free object exisistence not to
>> hold a lock. This will reduce lock contention in heavily allocation case.
>> Signed-off-by: Joonsoo Kim <iamjoonsoo@lge.com>
>
> I've bisected a boot failure (no output at all) in v4.7-rc2 on emev2/kzm9d
> (Renesas dual Cortex A9) to this patch, which is upstream commit
> 801faf0db8947e01877920e848a4d338dd7a99e7.
BTW, when disabling SMP, the problem goes away.
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: Boot failure on emev2/kzm9d (was: Re: [PATCH v2 11/11] mm/slab: lockless decision to grow cache)
Hi Joonsoo, On Tue, Jun 14, 2016 at 10:11 AM, Joonsoo Kim <iamjoonsoo@lge.com> wrote: > On Tue, Jun 14, 2016 at 09:31:23AM +0200, Geert Uytterhoeven wrote: >> On Tue, Jun 14, 2016 at 8:24 AM, Joonsoo Kim <iamjoonsoo@lge.com> wrote: >> > On Mon, Jun 13, 2016 at 09:43:13PM +0200, Geert Uytterhoeven wrote: >> >> On Tue, Apr 12, 2016 at 6:51 AM, <js1...@gmail.com> wrote: >> >> > From: Joonsoo Kim <iamjoonsoo@lge.com> >> >> > To check whther free objects exist or not precisely, we need to grab a >> >> > lock. But, accuracy isn't that important because race window would be >> >> > even small and if there is too much free object, cache reaper would reap >> >> > it. So, this patch makes the check for free object exisistence not to >> >> > hold a lock. This will reduce lock contention in heavily allocation >> >> > case. >> >> > >> >> > Note that until now, n->shared can be freed during the processing by >> >> > writing slabinfo, but, with some trick in this patch, we can access it >> >> > freely within interrupt disabled period. >> >> > >> >> > Below is the result of concurrent allocation/free in slab allocation >> >> > benchmark made by Christoph a long time ago. I make the output simpler. >> >> > The number shows cycle count during alloc/free respectively so less is >> >> > better. >> >> > >> >> > * Before >> >> > Kmalloc N*alloc N*free(32): Average=248/966 >> >> > Kmalloc N*alloc N*free(64): Average=261/949 >> >> > Kmalloc N*alloc N*free(128): Average=314/1016 >> >> > Kmalloc N*alloc N*free(256): Average=741/1061 >> >> > Kmalloc N*alloc N*free(512): Average=1246/1152 >> >> > Kmalloc N*alloc N*free(1024): Average=2437/1259 >> >> > Kmalloc N*alloc N*free(2048): Average=4980/1800 >> >> > Kmalloc N*alloc N*free(4096): Average=9000/2078 >> >> > >> >> > * After >> >> > Kmalloc N*alloc N*free(32): Average=344/792 >> >> > Kmalloc N*alloc N*free(64): Average=347/882 >> >> > Kmalloc N*alloc N*free(128): Average=390/959 >> >> > Kmalloc N*alloc N*free(256): Average=393/1067 >> >> > Kmalloc N*alloc N*free(512): Average=683/1229 >> >> > Kmalloc N*alloc N*free(1024): Average=1295/1325 >> >> > Kmalloc N*alloc N*free(2048): Average=2513/1664 >> >> > Kmalloc N*alloc N*free(4096): Average=4742/2172 >> >> > >> >> > It shows that allocation performance decreases for the object size up to >> >> > 128 and it may be due to extra checks in cache_alloc_refill(). But, >> >> > with >> >> > considering improvement of free performance, net result looks the same. >> >> > Result for other size class looks very promising, roughly, 50% >> >> > performance >> >> > improvement. >> >> > >> >> > v2: replace kick_all_cpus_sync() with synchronize_sched(). >> >> > >> >> > Signed-off-by: Joonsoo Kim <iamjoonsoo@lge.com> >> >> >> >> I've bisected a boot failure (no output at all) in v4.7-rc2 on emev2/kzm9d >> >> (Renesas dual Cortex A9) to this patch, which is upstream commit >> >> 801faf0db8947e01877920e848a4d338dd7a99e7. >> >> >> >> I've attached my .config. I don't know if it also happens with >> >> shmobile_defconfig, as something went wrong with my remote access to the >> >> board, >> >> preventing further testing. I also couldn't verify if the issue persists >> >> in >> >> v4.7-rc3. >> >> In the mean time, I've verified it also happens with shmobile_defconfig. >> >> >> Do you have a clue? >> > >> > I don't have yet. Could you help me to narrow down the problem? >> > Following diff is half-revert change to check that synchronize_sched() >> > has no problem. >> >> Thanks! >> >> Unfortunately the half revert is not sufficient. The full revert is. > > Thanks for quick testing! > > Could I ask one more time to check that synchronize_sched() is root > cause of the problem? Testing following two diffs will be helpful to me. > > Thanks. > > --->8 > diff --git a/mm/slab.c b/mm/slab.c > index 763096a..d892364 100644 > --- a/mm/slab.c > +++ b/mm/slab.c > @@ -965,7 +965,7 @@ static
renesas-drivers-2016-06-14-v4.7-rc2
I have pushed renesas-drivers-2016-06-14-v4.7-rc2 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-20160613-v4.7-rc3.
Included branches with driver code:
- clk-renesas-for-v4.8
- sh-pfc-for-v4.8
- topic/rcar-dmac-residue-v1
- topic/rcar-dmac-hamza-v3
- topic/ipmmu-multi-arch-v4
- topic/r8a7795-ipmmu-v2-rebased1
- topic/r8a7796-ipmmu-v1-rebased1
- topic/salvator-x-ipmmu-rfc-v3-rebased4
- topic/scif-hwflow-v3
- topic/scif-fifo-v1
-
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/r8a7796-v3
- topic/r8a7796-sysc-dt-v1
-
git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git#topic/sdr104-v3
- git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#staging/ks7010
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git#renesas/topic/pretimeout
- topic/h3-pfc-set-voltage-v1-rebased1
- https://git.ragnatech.se/linux#rcar-vin-for-renesas-drivers
- git://linuxtv.org/pinchartl/media.git#for/renesas-drivers
- git://linuxtv.org/pinchartl/media.git#vsp1/functions
- topic/fcpf-v1-rebased2
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://people.freedesktop.org/~airlied/linux#drm-next
- git://git.kernel.org/pub/scm/linux/kernel/git/joro/iommu.git#next
- git://linuxtv.org/mchehab/media-next.git#master
- git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git#mmc-next
- git://git.linaro.org/people/ulf.hansson/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.kernel.org/pub/scm/linux/kernel/git/djbw/dmaengine.git#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://ftp.arm.linux.org.uk/pub/linux/arm/kernel/git-cur/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://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git#for-next
- git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git#for-next
- git://git.infradead.org/battery-2.6.git#master
- 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-intel#topic/drm-misc
- 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
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 0/5] ARM: dts: renesas: Update console parameters
Hi Simon, Magnus,
This patch series updates the console parameters in the DTSes for
various Renesas ARM boards.
- For all of them, the serial port config is added to
chosen/stdout-path, as per current best practices,
- On some boards (armadillo, genmai, kzm9g), the console alias is
changed to "serial0", for consistency with other boards, and to
match current best practices (the first serial port should be called
"serial0", unless labeled otherwise).
This does mean the device changes its name to /dev/ttySC0 in
userspace. I believe it's OK to make this change, as we did the
same for koelsch, lager, and marzen before.
- On some boards (armadillo, kzm9d, kzm9g), "console=" parameters are
removed from the kernel command lines, as they're no longer needed
for DT-only platforms.
Beware leftover parameters in bootargs environment variables!
- On kzm9d, a console alias is added.
Changes compared to v1:
- Drop patches that have been applied,
- Change one-line summary prefixes to match current arm-soc practices,
- Drop name changes of pfc subnodes,
- Reword patch descriptions.
Dependencies:
- Due to dropping the name changes of pfc subnodes, this has an
esthetic (never realized before this does exist ;-) dependency on
"[PATCH 00/19] ARM: dts: renesas: Name pfc subnodes after device
names".
Tested on all five affected boards (some with remote access), to verify
there is no other impact to userspace than the change of the console
device to /dev/ttySC0, which may be handled automatically, depending on
your userspace.
Thanks for applying!
Geert Uytterhoeven (5):
ARM: dts: armadillo800eva: Update console parameters
ARM: dts: genmai: Update console parameters
ARM: dts: marzen: Add serial port config to chosen/stdout-path
ARM: dts: kzm9d: Update console parameters
ARM: dts: kzm9g: Update console parameters
arch/arm/boot/dts/emev2-kzm9d.dts | 8 ++--
arch/arm/boot/dts/r7s72100-genmai.dts | 4 ++--
arch/arm/boot/dts/r8a7740-armadillo800eva.dts | 6 +++---
arch/arm/boot/dts/r8a7779-marzen.dts | 2 +-
arch/arm/boot/dts/sh73a0-kzm9g.dts| 6 +++---
5 files changed, 15 insertions(+), 11 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 5/5] ARM: dts: kzm9g: Update console parameters
Change the console alias to "serial0", for consistency with other
boards (the first unlabeled serial port is always called "serial0").
This does change the serial console from /dev/ttySC4 to /dev/ttySC0.
Add the serial port config to "chosen/stdout-path", which requires
referring to the port by alias.
Drop the "console=" parameters from the kernel command line, as they're
no longer needed for DT-based platforms.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
v2:
- Change one-line summary prefix to match current arm-soc practices,
- Drop name change of pfc subnode,
- Reword patch description.
---
arch/arm/boot/dts/sh73a0-kzm9g.dts | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/sh73a0-kzm9g.dts
b/arch/arm/boot/dts/sh73a0-kzm9g.dts
index 1df68b1670339491..3d65f1f6d78b62a4 100644
--- a/arch/arm/boot/dts/sh73a0-kzm9g.dts
+++ b/arch/arm/boot/dts/sh73a0-kzm9g.dts
@@ -22,7 +22,7 @@
compatible = "renesas,kzm9g", "renesas,sh73a0";
aliases {
- serial4 =
+ serial0 =
};
cpus {
@@ -39,8 +39,8 @@
};
chosen {
- bootargs = "console=tty0 console=ttySC4,115200 root=/dev/nfs
ip=dhcp ignore_loglevel rw";
- stdout-path =
+ bootargs = "root=/dev/nfs ip=dhcp ignore_loglevel rw";
+ stdout-path = "serial0:115200n8";
};
memory@4000 {
--
1.9.1
[PATCH v2 3/5] ARM: dts: marzen: Add serial port config to chosen/stdout-path
Add the serial port config to "chosen/stdout-path", which requires
referring to the port by alias.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
v2:
- Change one-line summary prefix to match current arm-soc practices,
- Reword patch description.
---
arch/arm/boot/dts/r8a7779-marzen.dts | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/r8a7779-marzen.dts
b/arch/arm/boot/dts/r8a7779-marzen.dts
index 013e6f510b0faae4..541678df90a9829e 100644
--- a/arch/arm/boot/dts/r8a7779-marzen.dts
+++ b/arch/arm/boot/dts/r8a7779-marzen.dts
@@ -25,7 +25,7 @@
chosen {
bootargs = "ignore_loglevel root=/dev/nfs ip=on";
- stdout-path =
+ stdout-path = "serial0:115200n8";
};
memory@6000 {
--
1.9.1
[PATCH v2 4/5] ARM: dts: kzm9d: Update console parameters
Add a "serial1" alias for the serial console (it is labeled "uart1").
Add the serial port config to "chosen/stdout-path", which requires
referring to the port by alias.
Drop the "console=" parameter from the kernel command line, as it's no
longer needed for DT-based platforms.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
v2:
- Change one-line summary prefix to match current arm-soc practices,
- Reword patch description.
---
arch/arm/boot/dts/emev2-kzm9d.dts | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/arm/boot/dts/emev2-kzm9d.dts
b/arch/arm/boot/dts/emev2-kzm9d.dts
index 9eb86f8f32c5afc0..60d0a732833aaada 100644
--- a/arch/arm/boot/dts/emev2-kzm9d.dts
+++ b/arch/arm/boot/dts/emev2-kzm9d.dts
@@ -23,9 +23,13 @@
reg = <0x4000 0x800>;
};
+ aliases {
+ serial1 =
+ };
+
chosen {
- bootargs = "console=ttyS1,115200n81 ignore_loglevel
root=/dev/nfs ip=dhcp";
- stdout-path =
+ bootargs = "ignore_loglevel root=/dev/nfs ip=dhcp";
+ stdout-path = "serial1:115200n8";
};
gpio_keys {
--
1.9.1
Re: Boot failure on emev2/kzm9d (was: Re: [PATCH v2 11/11] mm/slab: lockless decision to grow cache)
Hi Joonsoo,
On Wed, Jun 15, 2016 at 4:23 AM, Joonsoo Kim <iamjoonsoo@lge.com> wrote:
> On Tue, Jun 14, 2016 at 12:45:14PM +0200, Geert Uytterhoeven wrote:
>> On Tue, Jun 14, 2016 at 10:11 AM, Joonsoo Kim <iamjoonsoo@lge.com> wrote:
>> > On Tue, Jun 14, 2016 at 09:31:23AM +0200, Geert Uytterhoeven wrote:
>> >> On Tue, Jun 14, 2016 at 8:24 AM, Joonsoo Kim <iamjoonsoo@lge.com>
>> >> wrote:
>> >> > On Mon, Jun 13, 2016 at 09:43:13PM +0200, Geert Uytterhoeven wrote:
>> >> >> On Tue, Apr 12, 2016 at 6:51 AM, <js1...@gmail.com> wrote:
>> >> >> > From: Joonsoo Kim <iamjoonsoo@lge.com>
>> >> >> > To check whther free objects exist or not precisely, we need to grab
>> >> >> > a
>> >> >> > lock. But, accuracy isn't that important because race window would
>> >> >> > be
>> >> >> > even small and if there is too much free object, cache reaper would
>> >> >> > reap
>> >> >> > it. So, this patch makes the check for free object exisistence not
>> >> >> > to
>> >> >> > hold a lock. This will reduce lock contention in heavily allocation
>> >> >> > case.
>> >> >> I've bisected a boot failure (no output at all) in v4.7-rc2 on
>> >> >> emev2/kzm9d
>> >> >> (Renesas dual Cortex A9) to this patch, which is upstream commit
>> >> >> 801faf0db8947e01877920e848a4d338dd7a99e7.
> It's curious that synchronize_sched() has some effect in this early
> phase. In synchronize_sched(), rcu_blocking_is_gp() is called and
> it checks num_online_cpus <= 1. If so, synchronize_sched() does nothing.
>
> It would be related to might_sleep() in rcu_blocking_is_gp() but I'm not sure
> now.
>
> First, I'd like to confirm that num_online_cpus() is correct.
> Could you try following patch and give me a dmesg?
>
> Thanks.
>
> --->8--
> diff --git a/mm/slab.c b/mm/slab.c
> index 763096a..5b7300a 100644
> --- a/mm/slab.c
> +++ b/mm/slab.c
> @@ -964,8 +964,10 @@ static int setup_kmem_cache_node(struct kmem_cache
> *cachep,
> * guaranteed to be valid until irq is re-enabled, because it will be
> * freed after synchronize_sched().
> */
> - if (force_change)
> - synchronize_sched();
> + if (force_change) {
> + WARN_ON_ONCE(num_online_cpus() <= 1);
> + WARN_ON_ONCE(num_online_cpus() > 1);
> + }
Full dmesg output below.
I also tested whether it's the call to synchronize_sched() before or after
secondary CPU bringup that hangs.
if (force_change && num_online_cpus() <= 1)
synchronize_sched();
boots.
if (force_change && num_online_cpus() > 1)
synchronize_sched();
hangs.
Booting Linux on physical CPU 0x0
Linux version 4.6.0-kzm9d-05060-g801faf0db8947e01-dirty (geert@ramsan)
(gcc version 4.9.0 (GCC) ) #84 SMP Wed Jun 15 10:20:12 CEST 2016
CPU: ARMv7 Processor [411fc093] revision 3 (ARMv7), cr=10c5387d
CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Machine model: EMEV2 KZM9D Board
debug: ignoring loglevel setting.
Memory policy: Data cache writealloc
On node 0 totalpages: 32768
free_area_init_node: node 0, pgdat c09286c0, node_mem_map c7efa000
Normal zone: 256 pages used for memmap
Normal zone: 0 pages reserved
Normal zone: 32768 pages, LIFO batch:7
percpu: Embedded 12 pages/cpu @c7ed9000 s19264 r8192 d21696 u49152
pcpu-alloc: s19264 r8192 d21696 u49152 alloc=12*4096
pcpu-alloc: [0] 0 [0] 1
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 32512
Kernel command line: console=ttyS1,115200n81 ignore_loglevel
root=/dev/nfs ip=dhcp
PID hash table entries: 512 (order: -1, 2048 bytes)
Dentry cache hash table entries: 16384 (order: 4, 65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
Memory: 121144K/131072K available (4243K kernel code, 165K rwdata,
1344K rodata, 2048K init, 264K bss, 9928K reserved, 0K cma-reserved,
0K highmem)
Virtual kernel memory layout:
vector : 0x - 0x1000 ( 4 kB)
fixmap : 0xffc0 - 0xfff0 (3072 kB)
vmalloc : 0xc880 - 0xff80 ( 880 MB)
lowmem : 0xc000 - 0xc800 ( 128 MB)
pkmap : 0xbfe0 - 0xc000 ( 2 MB)
modules : 0xbf00 - 0xbfe0 ( 14 MB)
.text : 0xc0008000 - 0xc0674eb8 (6580 kB)
.init : 0xc070 - 0xc090 (2048 kB)
.data : 0xc090 - 0xc0929420 ( 166 kB)
.bss : 0xc092b000 - 0xc096d1e8 ( 265 kB)
Hierarchical RCU implementation.
Build-time adjustment
Re: [PATCH 07/13] ARM: dts: r8a7792: initial SoC device tree
Hi Sergei,
On Mon, Jun 13, 2016 at 1:24 PM, Sergei Shtylyov
<sergei.shtyl...@cogentembedded.com> wrote:
> On 6/13/2016 10:12 AM, Geert Uytterhoeven wrote:
>>>>>The only problem I'm seeing (again) is the RCAN clock failing to
>>>>> register:
>>>>>
>>>>> rcar_gen2_cpg_clocks_init: failed to register cpg_clocks rcan clock
>>>>> (-12)
>>>>>
>>>>>I was going to look at it yesterday but (wrongly) thought it somehow
>>>>> cured itself... I'll look at it now.
>>>>
>>>>
>>>> The RCAN parent is the second clock in the CPG node's "clocks" property,
>>>> which you didn't provide.
>>>
>>>
>>>Actually, the things are more complex. The figure 7.1c suggests that
>>> the
>>> RCAN clock has different parent on R8A7792 than on the other SoCs --
>>> namely
>>> PLL1/VCO 1/4. That may be, since there's just no USB_EXTAL signal on this
>>> SoC (it doesn't seem to support any USB IPs). Which means the
>>> 'clk-rcar-gen2' driver can't work with the RCAN clock in its current
>>> form.
>>
>> Right, I had forgotten about that.
>> Fortunately the clk-rcar-gen2 driver has a sane failure mode for this case
>> ;-)
>
>What do you mean?
I mean that it failed due to the missing parent clock, instead of continuing
silently with a wrong clock rate.
>> it seems the RCAN clock can just be modeled as a fixed clock. However,
>> its divider value isn't clear to me,
>
>IIRC, the fixed RCAN divisor was equal to 6.
1560 / 6 != 15.9.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH 3/4] dt-bindings: Document Renesas R-Car FCP power-domains usage
Hi Kieran,
On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham <kie...@ksquared.org.uk> wrote:
> The example misses the power-domains usage, and documentation that the
> property is used by the node.
>
> Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
Thanks for your patch!
> ---
> Documentation/devicetree/bindings/media/renesas,fcp.txt | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt
> b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> index 1c0718b501ef..464bb7ae4b92 100644
> --- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> @@ -21,6 +21,8 @@ are paired with. These DT bindings currently support the
> FCPV and FCPF.
>
> - reg: the register base and size for the device registers
> - clocks: Reference to the functional clock
> + - power-domains : power-domain property defined with a phandle
> + to respective power domain.
I'd write "power domain specifier" instead of "phandle". While SYSC on R-Car
Gen3 uses #power-domain-cells = 0, the FCP module may show up on another
SoC that uses a different value, needing more than just a phandle.
In fact I'm inclined to leave out the power-domains property completely:
it's not a feature of the FCP, but of the SoC the FCP is part of.
power-domains properties may appear in any device node where needed.
> Device node example
> @@ -30,4 +32,5 @@ Device node example
> compatible = "renesas,r8a7795-fcpv", "renesas,fcpv";
> reg = <0 0xfea2f000 0 0x200>;
> clocks = < CPG_MOD 602>;
> + power-domains = < R8A7795_PD_A3VP>;
Adding it to the example doesn't hurt, though.
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/4] dt-bindings: Update Renesas R-Car FCP DT binding
Hi Kieran,
On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham <kie...@ksquared.org.uk> wrote:
> The FCP driver, can also support the FCPF variant for FDP1 compatible
> processing.
>
> Signed-off-by: Kieran Bingham <kie...@bingham.xyz>
Thanks for your patch!
> ---
> Documentation/devicetree/bindings/media/renesas,fcp.txt | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> Cc: devicet...@vger.kernel.org
>
> diff --git a/Documentation/devicetree/bindings/media/renesas,fcp.txt
> b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> index 6a12960609d8..1c0718b501ef 100644
> --- a/Documentation/devicetree/bindings/media/renesas,fcp.txt
> +++ b/Documentation/devicetree/bindings/media/renesas,fcp.txt
> @@ -7,11 +7,12 @@ conversion of AXI transactions in order to reduce the
> memory bandwidth.
>
> There are three types of FCP: FCP for Codec (FCPC), FCP for VSP (FCPV) and
> FCP
> for FDP (FCPF). Their configuration and behaviour depend on the module they
> -are paired with. These DT bindings currently support the FCPV only.
> +are paired with. These DT bindings currently support the FCPV and FCPF.
>
> - compatible: Must be one or more of the following
>
> - "renesas,r8a7795-fcpv" for R8A7795 (R-Car H3) compatible 'FCP for VSP'
> + - "renesas,r8a7795-fcpf" for R8A7795 (R-Car H3) compatible 'FCP for FDP'
> - "renesas,fcpv" for generic compatible 'FCP for VSP'
I guess checkpatch complained about your dtsi additions because you forgot
to add "renesas,fcpf" here?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 2/4] clk: renesas: Add r8a7796 CPG Core Clock Definitions
Add all R-Car M3-W Clock Pulse Generator Core Clock Outputs, as listed
in Table 8.2b ("List of Clocks [R-Car M3-W]") of the R-Car Gen3
datasheet (rev. 0.51 + Errata for Rev051 Mar 31 2016).
Note that internal CPG clocks (S0, S1, S2, S3, SDSRC, and SSPSRC) are
not included, as they are used as internal clock sources only, and never
referenced from DT.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Tested-by: Simon Horman <horms+rene...@verge.net.au>
---
v2:
- Add Tested-by.
---
include/dt-bindings/clock/r8a7796-cpg-mssr.h | 69
1 file changed, 69 insertions(+)
create mode 100644 include/dt-bindings/clock/r8a7796-cpg-mssr.h
diff --git a/include/dt-bindings/clock/r8a7796-cpg-mssr.h
b/include/dt-bindings/clock/r8a7796-cpg-mssr.h
new file mode 100644
index ..1e5942695f0dd057
--- /dev/null
+++ b/include/dt-bindings/clock/r8a7796-cpg-mssr.h
@@ -0,0 +1,69 @@
+/*
+ * Copyright (C) 2016 Renesas Electronics Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+#ifndef __DT_BINDINGS_CLOCK_R8A7796_CPG_MSSR_H__
+#define __DT_BINDINGS_CLOCK_R8A7796_CPG_MSSR_H__
+
+#include
+
+/* r8a7796 CPG Core Clocks */
+#define R8A7796_CLK_Z 0
+#define R8A7796_CLK_Z2 1
+#define R8A7796_CLK_ZR 2
+#define R8A7796_CLK_ZG 3
+#define R8A7796_CLK_ZTR4
+#define R8A7796_CLK_ZTRD2 5
+#define R8A7796_CLK_ZT 6
+#define R8A7796_CLK_ZX 7
+#define R8A7796_CLK_S0D1 8
+#define R8A7796_CLK_S0D2 9
+#define R8A7796_CLK_S0D3 10
+#define R8A7796_CLK_S0D4 11
+#define R8A7796_CLK_S0D6 12
+#define R8A7796_CLK_S0D8 13
+#define R8A7796_CLK_S0D12 14
+#define R8A7796_CLK_S1D1 15
+#define R8A7796_CLK_S1D2 16
+#define R8A7796_CLK_S1D4 17
+#define R8A7796_CLK_S2D1 18
+#define R8A7796_CLK_S2D2 19
+#define R8A7796_CLK_S2D4 20
+#define R8A7796_CLK_S3D1 21
+#define R8A7796_CLK_S3D2 22
+#define R8A7796_CLK_S3D4 23
+#define R8A7796_CLK_LB 24
+#define R8A7796_CLK_CL 25
+#define R8A7796_CLK_ZB326
+#define R8A7796_CLK_ZB3D2 27
+#define R8A7796_CLK_ZB3D4 28
+#define R8A7796_CLK_CR 29
+#define R8A7796_CLK_CRD2 30
+#define R8A7796_CLK_SD0H 31
+#define R8A7796_CLK_SD032
+#define R8A7796_CLK_SD1H 33
+#define R8A7796_CLK_SD134
+#define R8A7796_CLK_SD2H 35
+#define R8A7796_CLK_SD236
+#define R8A7796_CLK_SD3H 37
+#define R8A7796_CLK_SD338
+#define R8A7796_CLK_SSP2 39
+#define R8A7796_CLK_SSP1 40
+#define R8A7796_CLK_SSPRS 41
+#define R8A7796_CLK_RPC42
+#define R8A7796_CLK_RPCD2 43
+#define R8A7796_CLK_MSO44
+#define R8A7796_CLK_CANFD 45
+#define R8A7796_CLK_HDMI 46
+#define R8A7796_CLK_CSI0 47
+#define R8A7796_CLK_CSIREF 48
+#define R8A7796_CLK_CP 49
+#define R8A7796_CLK_CPEX 50
+#define R8A7796_CLK_R 51
+#define R8A7796_CLK_OSC52
+
+#endif /* __DT_BINDINGS_CLOCK_R8A7796_CPG_MSSR_H__ */
--
1.9.1
[PATCH v2 4/4] clk: renesas: cpg-mssr: Add support for R-Car M3-W
Initial support for R-Car M3-W (r8a7796), including basic core clocks,
and SCIF2 (console) and INTC-AP (GIC) module clocks.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
Tested-by: Simon Horman <horms+rene...@verge.net.au>
---
v2:
- Add Tested-by.
---
drivers/clk/renesas/Kconfig| 1 +
drivers/clk/renesas/Makefile | 1 +
drivers/clk/renesas/r8a7796-cpg-mssr.c | 192 +
drivers/clk/renesas/renesas-cpg-mssr.c | 6 ++
drivers/clk/renesas/renesas-cpg-mssr.h | 1 +
5 files changed, 201 insertions(+)
create mode 100644 drivers/clk/renesas/r8a7796-cpg-mssr.c
diff --git a/drivers/clk/renesas/Kconfig b/drivers/clk/renesas/Kconfig
index 2115ce410cfb4bc9..fcad9ff090f5fd2b 100644
--- a/drivers/clk/renesas/Kconfig
+++ b/drivers/clk/renesas/Kconfig
@@ -1,6 +1,7 @@
config CLK_RENESAS_CPG_MSSR
bool
default y if ARCH_R8A7795
+ default y if ARCH_R8A7796
config CLK_RENESAS_CPG_MSTP
bool
diff --git a/drivers/clk/renesas/Makefile b/drivers/clk/renesas/Makefile
index 88924c95808c3b2e..0b8d31b4909c9690 100644
--- a/drivers/clk/renesas/Makefile
+++ b/drivers/clk/renesas/Makefile
@@ -9,6 +9,7 @@ obj-$(CONFIG_ARCH_R8A7791) += clk-rcar-gen2.o
clk-div6.o
obj-$(CONFIG_ARCH_R8A7793) += clk-rcar-gen2.o clk-div6.o
obj-$(CONFIG_ARCH_R8A7794) += clk-rcar-gen2.o clk-div6.o
obj-$(CONFIG_ARCH_R8A7795) += r8a7795-cpg-mssr.o rcar-gen3-cpg.o
+obj-$(CONFIG_ARCH_R8A7796) += r8a7796-cpg-mssr.o rcar-gen3-cpg.o
obj-$(CONFIG_ARCH_SH73A0) += clk-sh73a0.o clk-div6.o
obj-$(CONFIG_CLK_RENESAS_CPG_MSSR) += renesas-cpg-mssr.o clk-div6.o
diff --git a/drivers/clk/renesas/r8a7796-cpg-mssr.c
b/drivers/clk/renesas/r8a7796-cpg-mssr.c
new file mode 100644
index ..c84b549c14d2e57d
--- /dev/null
+++ b/drivers/clk/renesas/r8a7796-cpg-mssr.c
@@ -0,0 +1,192 @@
+/*
+ * r8a7796 Clock Pulse Generator / Module Standby and Software Reset
+ *
+ * Copyright (C) 2016 Glider bvba
+ *
+ * Based on r8a7795-cpg-mssr.c
+ *
+ * Copyright (C) 2015 Glider bvba
+ * Copyright (C) 2015 Renesas Electronics Corp.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; version 2 of the License.
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "renesas-cpg-mssr.h"
+#include "rcar-gen3-cpg.h"
+
+enum clk_ids {
+ /* Core Clock Outputs exported to DT */
+ LAST_DT_CORE_CLK = R8A7796_CLK_OSC,
+
+ /* External Input Clocks */
+ CLK_EXTAL,
+ CLK_EXTALR,
+
+ /* Internal Core Clocks */
+ CLK_MAIN,
+ CLK_PLL0,
+ CLK_PLL1,
+ CLK_PLL2,
+ CLK_PLL3,
+ CLK_PLL4,
+ CLK_PLL1_DIV2,
+ CLK_PLL1_DIV4,
+ CLK_S0,
+ CLK_S1,
+ CLK_S2,
+ CLK_S3,
+ CLK_SDSRC,
+ CLK_SSPSRC,
+
+ /* Module Clocks */
+ MOD_CLK_BASE
+};
+
+static const struct cpg_core_clk r8a7796_core_clks[] __initconst = {
+ /* External Clock Inputs */
+ DEF_INPUT("extal", CLK_EXTAL),
+ DEF_INPUT("extalr", CLK_EXTALR),
+
+ /* Internal Core Clocks */
+ DEF_BASE(".main", CLK_MAIN, CLK_TYPE_GEN3_MAIN, CLK_EXTAL),
+ DEF_BASE(".pll0", CLK_PLL0, CLK_TYPE_GEN3_PLL0, CLK_MAIN),
+ DEF_BASE(".pll1", CLK_PLL1, CLK_TYPE_GEN3_PLL1, CLK_MAIN),
+ DEF_BASE(".pll2", CLK_PLL2, CLK_TYPE_GEN3_PLL2, CLK_MAIN),
+ DEF_BASE(".pll3", CLK_PLL3, CLK_TYPE_GEN3_PLL3, CLK_MAIN),
+ DEF_BASE(".pll4", CLK_PLL4, CLK_TYPE_GEN3_PLL4, CLK_MAIN),
+
+ DEF_FIXED(".pll1_div2", CLK_PLL1_DIV2, CLK_PLL1, 2, 1),
+ DEF_FIXED(".pll1_div4", CLK_PLL1_DIV4, CLK_PLL1_DIV2, 2, 1),
+ DEF_FIXED(".s0",CLK_S0,CLK_PLL1_DIV2, 2, 1),
+ DEF_FIXED(".s1",CLK_S1,CLK_PLL1_DIV2, 3, 1),
+ DEF_FIXED(".s2",CLK_S2,CLK_PLL1_DIV2, 4, 1),
+ DEF_FIXED(".s3",CLK_S3,CLK_PLL1_DIV2, 6, 1),
+
+ /* Core Clock Outputs */
+ DEF_FIXED("ztr",R8A7796_CLK_ZTR, CLK_PLL1_DIV2, 6, 1),
+ DEF_FIXED("ztrd2", R8A7796_CLK_ZTRD2, CLK_PLL1_DIV2, 12, 1),
+ DEF_FIXED("zt", R8A7796_CLK_ZT,CLK_PLL1_DIV2, 4, 1),
+ DEF_FIXED("zx", R8A7796_CLK_ZX,CLK_PLL1_DIV2, 2, 1),
+ DEF_FIXED("s0d1", R8A7796_CLK_S0D1, CLK_S0, 1, 1),
+ DEF_FIXED("s0d2", R8A7796_CLK_S0D2, CLK_S0, 2, 1),
+ DEF_FIXED("s0d3", R8A7796_CLK_S0D3, CLK_S0, 3, 1),
+ DEF_FIXED("s0d4", R8A7796_C
[PATCH v2 2/3] soc: renesas: Add r8a7796 SYSC PM Domain Binding Definitions
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> --- v2: - Add Acked-by. --- include/dt-bindings/power/r8a7796-sysc.h | 36 1 file changed, 36 insertions(+) create mode 100644 include/dt-bindings/power/r8a7796-sysc.h diff --git a/include/dt-bindings/power/r8a7796-sysc.h b/include/dt-bindings/power/r8a7796-sysc.h new file mode 100644 index ..5b4daab44daa0057 --- /dev/null +++ b/include/dt-bindings/power/r8a7796-sysc.h @@ -0,0 +1,36 @@ +/* + * Copyright (C) 2016 Glider bvba + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; version 2 of the License. + */ +#ifndef __DT_BINDINGS_POWER_R8A7796_SYSC_H__ +#define __DT_BINDINGS_POWER_R8A7796_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 R8A7796_PD_CA57_CPU00 +#define R8A7796_PD_CA57_CPU11 +#define R8A7796_PD_CA53_CPU05 +#define R8A7796_PD_CA53_CPU16 +#define R8A7796_PD_CA53_CPU27 +#define R8A7796_PD_CA53_CPU38 +#define R8A7796_PD_CA57_SCU12 +#define R8A7796_PD_CR7 13 +#define R8A7796_PD_A3VC14 +#define R8A7796_PD_3DG_A 17 +#define R8A7796_PD_3DG_B 18 +#define R8A7796_PD_CA53_SCU21 +#define R8A7796_PD_A3IR24 +#define R8A7796_PD_A2VC0 25 +#define R8A7796_PD_A2VC1 26 + +/* Always-on power area */ +#define R8A7796_PD_ALWAYS_ON 32 + +#endif /* __DT_BINDINGS_POWER_R8A7796_SYSC_H__ */ -- 1.9.1
[PATCH v2 0/3] soc: renesas: rcar-sysc: Add support for R-Car M3-W power areas
Hi Simon, Magnus,
This patch series adds support for the power areas exposed by the System
Controller on the Renesas R-Car M3-W SoC. This is a prerequisite for
enabling devices (e.g. VSP and FCP) that reside in power areas.
/sys/kernel/debug/pm_genpd/pm_genpd_summary output:
domain status slaves
/device runtime status
--
clock-controlleron
a3iroff-0
3dg-b off-0
3dg-a off-0 3dg-b
a2vc1 off-0
a2vc0 off-0
a3vcoff-0 a2vc0, a2vc1
cr7 off-0
ca53-cpu3 on
ca53-cpu2 on
ca53-cpu1 on
ca53-cpu0 on
ca53-scuon ca53-cpu0, ca53-cpu1,
ca53-cpu2, ca53-cpu3
ca57-cpu1 on
ca57-cpu0 on
ca57-scuon ca57-cpu0, ca57-cpu1
always-on on ca57-scu, ca53-scu, cr7,
a3vc, 3dg-a, a3ir
/devices/platform/soc/e6e88000.serial active
Changes compared to v1:
- Add Acked-by.
For your convenience, I've pushed this series to the
topic/r8a7796-sysc-v2 branch of
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git.
This has been tested on r8a7796/salvator-x, and the code (minus the
acks, i.e. v1), has been part of renesas-drivers since 2016-05-10.
Thanks!
Geert Uytterhoeven (3):
soc: renesas: rcar-sysc: Document r8a7796 support
soc: renesas: Add r8a7796 SYSC PM Domain Binding Definitions
soc: renesas: rcar-sysc: Add support for R-Car M3-W power areas
.../bindings/power/renesas,rcar-sysc.txt | 1 +
drivers/soc/renesas/Makefile | 1 +
drivers/soc/renesas/r8a7796-sysc.c | 48 ++
drivers/soc/renesas/rcar-sysc.c| 3 ++
drivers/soc/renesas/rcar-sysc.h| 1 +
include/dt-bindings/power/r8a7796-sysc.h | 36
6 files changed, 90 insertions(+)
create mode 100644 drivers/soc/renesas/r8a7796-sysc.c
create mode 100644 include/dt-bindings/power/r8a7796-sysc.h
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
[PATCH v2 1/3] soc: renesas: rcar-sysc: Document r8a7796 support
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> Acked-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> Acked-by: Rob Herring <r...@kernel.org> --- v2: - Add Acked-by. --- 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 b74e4d4785ab2d60..0725fb37a973d8eb 100644 --- a/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt +++ b/Documentation/devicetree/bindings/power/renesas,rcar-sysc.txt @@ -14,6 +14,7 @@ Required properties: - "renesas,r8a7793-sysc" (R-Car M2-N) - "renesas,r8a7794-sysc" (R-Car E2) - "renesas,r8a7795-sysc" (R-Car H3) + - "renesas,r8a7796-sysc" (R-Car M3-W) - reg: Address start and address range for the device. - #power-domain-cells: Must be 1. -- 1.9.1
[PATCH 1/2] arm64: dts: r8a7796: Add SYSC PM Domains
Add a device node for the System Controller.
Hook up the Cortex-A57 CPU core and L2 cache/SCU to their respective PM
Domains.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
index 178debf68318fde4..85f0843ddd874378 100644
--- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi
+++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi
@@ -10,6 +10,7 @@
#include
#include
+#include
/ {
compatible = "renesas,r8a7796";
@@ -30,6 +31,7 @@
compatible = "arm,cortex-a57", "arm,armv8";
reg = <0x0>;
device_type = "cpu";
+ power-domains = < R8A7796_PD_CA57_CPU0>;
next-level-cache = <_CA57>;
enable-method = "psci";
};
@@ -37,6 +39,7 @@
L2_CA57: cache-controller@0 {
compatible = "cache";
reg = <0>;
+ power-domains = < R8A7796_PD_CA57_SCU>;
cache-unified;
cache-level = <2>;
};
@@ -104,6 +107,12 @@
#power-domain-cells = <0>;
};
+ sysc: system-controller@e618 {
+ compatible = "renesas,r8a7796-sysc";
+ reg = <0 0xe618 0 0x0400>;
+ #power-domain-cells = <1>;
+ };
+
scif2: serial@e6e88000 {
compatible = "renesas,scif-r8a7796",
"renesas,rcar-gen3-scif", "renesas,scif";
--
1.9.1
[PATCH 0/2] arm64: dts: r8a7796: Add SYSC PM Domains
Hi Simon, Magnus,
This patch series adds support for the power areas exposed by the System
Controller on the Renesas R-Car M3-W SoC to the DTS.
This series is against Simon's "[PATCH v3 0/3] arm64: Add Renesas
R8A7796 SoC support". It has a build and runtime dependency on my series
"[PATCH v2 0/3] soc: renesas: rcar-sysc: Add support for R-Car M3-W power
areas".
For your convenience, I've pushed this series to the
topic/r8a7796-sysc-dt-v1 branch of
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git.
This has been tested on r8a7796/salvator-x.
Thanks!
Geert Uytterhoeven (2):
arm64: dts: r8a7796: Add SYSC PM Domains
arm64: dts: r8a7796: Use SYSC "always-on" PM Domain
arch/arm64/boot/dts/renesas/r8a7796.dtsi | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
--
1.9.1
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 2/2] arm64: dts: r8a7796: Use SYSC "always-on" PM Domain
Hook up all devices that are part of the CPG/MSSR Clock Domain to the SYSC "always-on" PM Domain, for a more consistent device-power-area description in DT. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- arch/arm64/boot/dts/renesas/r8a7796.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/boot/dts/renesas/r8a7796.dtsi b/arch/arm64/boot/dts/renesas/r8a7796.dtsi index 85f0843ddd874378..fab61eddede3818c 100644 --- a/arch/arm64/boot/dts/renesas/r8a7796.dtsi +++ b/arch/arm64/boot/dts/renesas/r8a7796.dtsi @@ -122,7 +122,7 @@ < CPG_CORE R8A7796_CLK_S3D1>, <_clk>; clock-names = "fck", "brg_int", "scif_clk"; - power-domains = <>; + power-domains = < R8A7796_PD_ALWAYS_ON>; status = "disabled"; }; }; -- 1.9.1
Re: [PATCH 0/4] RCar r8a7795 FCPF support
Hi Kieran,
On Fri, May 27, 2016 at 7:19 PM, Kieran Bingham <kie...@ksquared.org.uk> wrote:
> An RCar FCP driver is available with support for the FCPV module for VSP.
> This series updates that driver to support the FCPF and then provide the
> relevant nodes in the r8a7795 device tree.
>
> Checkpatch generates a warning on these DT references but they are
> documented under Documentation/devicetree/bindings/media/renesas,fcp.txt
>
> These patches are based on Geert's renesas-drivers tree, and are pushed
> to a branch at g...@github.com:kbingham/linux.git renesas/fcpf for
> convenience.
As this is based on previous renesas-drivers release, which included the
Salvator-X HDMI prototype, I created a topic branch topic/fcpf-v1 just
containing your changes.
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 0/4] ARM: Renesas: R-Car3: Add product register support
On Fri, May 27, 2016 at 10:44 AM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
> Btw, what's about the MODEMR patch series? As it's from you and there have
> been no further comments with v3, I'm somehow hoping to get it integrated.
I'll be working on it soon.
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 2/4] serial: sh-sci: Stop transfers in sci_shutdown()
Make sure the transmitter and receiver are stopped when shutting down the port, and related interrupts are disabled. Without this: - New input data may be received into the RX FIFO, possibly triggering a new RX DMA completion, - Transfers will still be enabled on a subsequent startup of the UART, before the UART's FIFOs have been reset, causing reading of stale data. Inspired by a patch in the BSP by Koji Matsuoka <koji.matsuoka...@renesas.com>. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- Extracted from "[PATCH/RFC v3 0/4] serial: sh-sci: Add DT DMA support". The issues with the serial console seen before on r8a7740/armadillo and sh73a0/kzm9g seem to be gone. Changes after resurrection: - Write zero to also disable related interrupts, as suggested by Laurent Pinchart, - Enhanced patch description. --- drivers/tty/serial/sh-sci.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index d6ba90c572f7475c..4d2f916f45277e20 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -1896,6 +1896,8 @@ static void sci_shutdown(struct uart_port *port) spin_lock_irqsave(>lock, flags); sci_stop_rx(port); sci_stop_tx(port); + /* Stop RX and TX, disable related interrupts */ + serial_port_out(port, SCSCR, 0); spin_unlock_irqrestore(>lock, flags); #ifdef CONFIG_SERIAL_SH_SCI_DMA -- 1.9.1
[PATCH 1/4] serial: sh-sci: Do not start transfers from sci_startup()
FIFO reset is done in sci_reset(), called from sci_set_termios(), while
sci_start_tx() and sci_start_rx() are called before, from sci_startup().
However, starting transfers before the UART's FIFOs have been reset may
cause reading of stale data.
Remove the calls to sci_start_tx() and sci_start_rx() from sci_startup()
to fix this.
Transfers are still started when needed:
- sci_start_rx() is called from sci_set_termios() after FIFO reset, if
the CREAD flag is set,
- sci_start_tx() is called from uart_change_speed() immediately
thereafter, if transmission is enabled.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/tty/serial/sh-sci.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 0130feb069aee02f..d6ba90c572f7475c 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -1873,7 +1873,6 @@ static void sci_break_ctl(struct uart_port *port, int
break_state)
static int sci_startup(struct uart_port *port)
{
struct sci_port *s = to_sci_port(port);
- unsigned long flags;
int ret;
dev_dbg(port->dev, "%s(%d)\n", __func__, port->line);
@@ -1884,11 +1883,6 @@ static int sci_startup(struct uart_port *port)
sci_request_dma(port);
- spin_lock_irqsave(>lock, flags);
- sci_start_tx(port);
- sci_start_rx(port);
- spin_unlock_irqrestore(>lock, flags);
-
return 0;
}
--
1.9.1
[PATCH 3/4] serial: sh-sci: Clear RX, error, and break flags during reset
Setting the FIFO reset bits is not sufficient to reset the RX FIFO. After this the status register's RDF flag bit may still be set, causing the reception of one stale byte of data. To fix this, clear all status flag bits related to reception, error, and break handling, cfr. the initialization flowchart in the datasheet. Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be> --- drivers/tty/serial/sh-sci.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c index 4d2f916f45277e20..549d799cb18fafe7 100644 --- a/drivers/tty/serial/sh-sci.c +++ b/drivers/tty/serial/sh-sci.c @@ -2052,6 +2052,10 @@ static void sci_reset(struct uart_port *port) reg = sci_getreg(port, SCFCR); if (reg->size) serial_port_out(port, SCFCR, SCFCR_RFRST | SCFCR_TFRST); + + sci_clear_SCxSR(port, + SCxSR_RDxF_CLEAR(port) & SCxSR_ERROR_CLEAR(port) & + SCxSR_BREAK_CLEAR(port)); } static void sci_set_termios(struct uart_port *port, struct ktermios *termios, -- 1.9.1
[PATCH 4/4] serial: sh-sci: Clear (H)SCIF timeout and overrun during reset
Add the missing timeout bit definition for (H)SCIF.
Clear the timeout and overrun flag bits during UART reset, cfr. the
initialization flowchart in the datasheet.
Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
---
drivers/tty/serial/sh-sci.c | 5 +
drivers/tty/serial/sh-sci.h | 1 +
2 files changed, 6 insertions(+)
diff --git a/drivers/tty/serial/sh-sci.c b/drivers/tty/serial/sh-sci.c
index 549d799cb18fafe7..fe9ad1b56420876a 100644
--- a/drivers/tty/serial/sh-sci.c
+++ b/drivers/tty/serial/sh-sci.c
@@ -2056,6 +2056,11 @@ static void sci_reset(struct uart_port *port)
sci_clear_SCxSR(port,
SCxSR_RDxF_CLEAR(port) & SCxSR_ERROR_CLEAR(port) &
SCxSR_BREAK_CLEAR(port));
+ if (sci_getreg(port, SCLSR)->size) {
+ status = serial_port_in(port, SCLSR);
+ status &= ~(SCLSR_TO | SCLSR_ORER);
+ serial_port_out(port, SCLSR, status);
+ }
}
static void sci_set_termios(struct uart_port *port, struct ktermios *termios,
diff --git a/drivers/tty/serial/sh-sci.h b/drivers/tty/serial/sh-sci.h
index 7a4fa185b93ef307..c590418d2a40d78b 100644
--- a/drivers/tty/serial/sh-sci.h
+++ b/drivers/tty/serial/sh-sci.h
@@ -105,6 +105,7 @@ enum {
#define SCFCR_LOOP BIT(0) /* Loopback Test */
/* SCLSR (Line Status Register) on (H)SCIF */
+#define SCLSR_TO BIT(2) /* Timeout */
#define SCLSR_ORER BIT(0) /* Overrun Error */
/* SCSPTR (Serial Port Register), optional */
--
1.9.1
[PATCH 0/4] serial: sh-sci: FIFO initialization fixes
Hi Greg, Jiri, Magnus,
When opening a Renesas SCIF serial port after it has been used before,
stale data may be read. This has been observed on R-Car Gen2 and R-Car
Gen3, with all SCIF variants present (SCIF, SCIFA, SCIFB, and HSCIF). It
is much more likely to happen when DMA is enabled, although it has been
seen with PIO, too.
There are actually two reasons why stale data is received:
1. Transfers are started, or are still activated, before the FIFO is
reset, causing one or more (up to the RX FIFO size) stale bytes
(fixed by patches 1 and 2),
2. FIFO reset lacked clearing the RDF flag, causing one byte of stale
data (fixed by patch 3).
While at it, patch 4 adds the missing clearing of two other flags in the
initialization sequence on (H)SCIF.
While the issue can be reproduced using subsequent runs of sertest[1],
I wrote a new test program, fifotest[2], to trigger it more easily.
More detailed test information can be found on the eLinux wiki[3].
I have verified that this series fixes the issue on SCIF, SCIFA, SCIFB,
and HSCIF, on R-Car Gen2 (r8a7791/koelsch) and R-Car Gen3
(r8a7795/salvator-x).
Basic regression testing has been done with SCIFA on sh73a0/kzm9g.
Regression testing on other variants (notably SCI) would be appreciated.
This series applies against both v4.6 and next-20160526. It's also
available in a topic branch at
https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/log/?h=topic/scif-fifo-v1.
Thanks!
[1] https://github.com/geertu/sertest
[2] https://github.com/geertu/fifotest
[3] http://elinux.org/Tests:SCIF-FIFO
Geert Uytterhoeven (4):
serial: sh-sci: Do not start transfers from sci_startup()
serial: sh-sci: Stop transfers in sci_shutdown()
serial: sh-sci: Clear RX, error, and break flags during reset
serial: sh-sci: Clear (H)SCIF timeout and overrun during reset
drivers/tty/serial/sh-sci.c | 17 +++--
drivers/tty/serial/sh-sci.h | 1 +
2 files changed, 12 insertions(+), 6 deletions(-)
--
1.9.1
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH/RFC v3 20/22] clk: renesas: r8a7778: Remove obsolete r8a7778_clocks_init()
Hi Dirk,
On Thu, Jun 2, 2016 at 7:54 AM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
> On 01.06.2016 21:21, Geert Uytterhoeven wrote:
>> The R-Car M1A board code no longer calls r8a7778_clocks_init().
>>
>> Signed-off-by: Geert Uytterhoeven <geert+rene...@glider.be>
>> ---
>> v3:
>> - New.
>> ---
>> drivers/clk/renesas/clk-r8a7778.c | 13 -
>> include/linux/clk/renesas.h | 1 -
>> 2 files changed, 14 deletions(-)
>>
>> diff --git a/drivers/clk/renesas/clk-r8a7778.c
>> b/drivers/clk/renesas/clk-r8a7778.c
>> index 07ea411098a75ad1..886a8380e91247a1 100644
>> --- a/drivers/clk/renesas/clk-r8a7778.c
>> +++ b/drivers/clk/renesas/clk-r8a7778.c
>> @@ -143,16 +143,3 @@ static void __init r8a7778_cpg_clocks_init(struct
>> device_node *np)
>>
>> CLK_OF_DECLARE(r8a7778_cpg_clks, "renesas,r8a7778-cpg-clocks",
>>r8a7778_cpg_clocks_init);
>> -
>> -void __init r8a7778_clocks_init(u32 mode)
>> -{
>> - BUG_ON(!(mode & BIT(19)));
>> -
>> - cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
>> -(!!(mode & BIT(12)) << 1) |
>> -(!!(mode & BIT(11)));
>> - cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
>> - (!!(mode & BIT(1)));
>> -
>> - of_clk_init(NULL);
>> -}
>
> Just a question on how you structured the patches: Is there a special reason
> why you do the adding of new code and the removal of dead code in two
> patches?
>
> Having both in one patch normally makes it more obvious which old code is
> replaced by which new code.
>
> An example: In patch
>
> [PATCH/RFC v3 11/22] clk: renesas: r8a7778: Obtain mode pin values using
> R-Car RST driver
>
> I wondered where the section
>
> + BUG_ON(!(mode & BIT(19)));
> +
> + cpg_mode_rates = (!!(mode & BIT(18)) << 2) |
> +(!!(mode & BIT(12)) << 1) |
> +(!!(mode & BIT(11)));
> + cpg_mode_divs = (!!(mode & BIT(2)) << 1) |
> + (!!(mode & BIT(1)));
>
> comes from. This becomes obvious with this patch 20/22. But it's 9 patches
> later ;) So why don't make the whole replacement visible in one patch?
Because that would break bisection.
Path 20 depends on patch 17, which depends on patch 11.
These three can't be a single patch because they touch multiple subsystems.
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 v3 1/3] arm64: dts: r8a7796: Add Renesas R8A7796 SoC support
Hi Dirk,
On Wed, May 25, 2016 at 9:32 AM, Dirk Behme <dirk.be...@de.bosch.com> wrote:
> P.S.: This also results in the question why we need similar
> r8a7795-cpg-mssr.h and r8a7796-cpg-mssr.h with just different "numbers" for
> the same clocks. Can't we use the same numbers on all SoCs, with just having
> wholes in the list where the clocks don't exist on a SoC? I haven't looked
The CPG and MSSR block are the IP blocks that differ most among SoCs of the
same family. Some clocks are present on H3 only, others on M3-W only.
Having a shared driver core, but different defines, is a compromise between
reusability and avoiding mistakes in DTSes (e.g. pointing to a nonexisting
clock due to copy and paste from another SoC).
> into the manual if these numbers are given by the hardware, though.
The actual numbers don't map to numbers in the datasheet, just to an unordered
list in a table. The list of number is considered part of the DT bindings, and
thus append-only (to be considered in case the datasheet is updated).
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
