01d675f159 ARM: shmobile: rcar-gen2: Add watchdog support
58adf1ba0d ARM: shmobile: Add watchdog support
* SoC
- Identify R-Car V3H (r8a77980) and M3N (r8a77965)
- Enable R-Car Gen2 regulator quirk for Stout board with H3 (r8a7790) SoC
Marek Vaust says "Regulator setup is suboptimal on H2 Stout too. The
Stout newly has two DA9210 regulators, so the quirk is extended to
handle another DA9210 at i2c address 0x70."
- Add watchdog support
This is the SoC portion of the following solution. It is not yet
enabled in DT as it is not functional without clock dependencies
in place.
Fabrizio Castro says "this series has been around for some time as RFC,
and it has collected useful comments from the community along the way.
The solution proposed by this patch set works for most R-Car Gen2 and
RZ/G1 devices, but not all of them. We now know that for some R-Car
Gen2 early revisions there is no proper software fix. Anyway, no
product has been built around early revisions, but development boards
mounting early revisions (basically prototypes) are still out there.
As a result, this series isn't enabling the internal watchdog on R-Car
Gen2 boards, developers may enable it in board specific device trees if
needed. This series has been tested by me on the iwg20d, iwg22d,
Lager, Alt, and Koelsch boards.
The problem
===========
To deal with SMP on R-Car Gen2 and RZ/G1, we install a reset vector to
ICRAM1 and we program the [S]BAR registers so that when we turn ON the
non-boot CPUs they are redirected to the reset vector installed by Linux
in ICRAM1, and eventually they continue the execution to RAM, where the
SMP bring-up code will take care of the rest. The content of the [S]BAR
registers survives a watchdog triggered reset, and as such after the
watchdog fires the boot core will try and execute the SMP bring-up code
instead of jumping to the bootrom code.
The fix
=======
The main strategy for the solution is to let the reset vector decide if
it needs to jump to shmobile_boot_fn or to the bootrom code. In a
watchdog triggered reset scenario, since the [S]BAR registers keep their
values, the boot CPU will jump into the newly designed reset vector, the
assembly routine will eventually test WOVF (a bit in register RWTCSRA
that indicates if the watchdog counter has overflown, the value of this
bit gets retained in this scenario), and jump to the bootrom code which
will in turn load up the bootloader, etc. When bringing up SMP or using
CPU hotplug, the reset vector will jump to shmobile_boot_fn instead."
* R-Car Rst
- Add support for R-Car V3H (r8a77980) and V3H (r8a77980)
* R-Car SYSC
- Mark rcar_sysc_matches[] __initconst
Geert Uytterhoeven says "This frees another 1764 bytes
(arm32/shmobile_defconfig) or 1000 bytes (arm64/renesas_defconfig) of
memory after kernel init."
- Fix power area parents
Sergei Shtylyov says "According to the figure 9.2(b) of the R-Car
Series, 3rd Generation User’s Manual: Hardware Rev. 0.80 the A2IRn and
A2SCn power areas in R8A77970 have the A3IR area as a parent, thus the
SYSC driver has those parents wrong.."
- Add support for R-Car V3H (r8a77980) and V3H (r8a77980)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEE4nzZofWswv9L/nKF189kaWo3T74FAlqr2U0ACgkQ189kaWo3
T76GQQ//TglmA64QnoynoYa7VR5VBvMoT4Hfd2LhUQaJ5dlqtnaIeipPIc/k5rlH
qsw5Jp7OlkNWAwchlIqkto+vfNhuxHItqvZoBnmrI2otEUvbaJ+9A2xAuhmYBxxH
awKoSTY4A+n8GFcCIOvYMzvRKVFUSIDSWYvYQSJtu6OyXZYI244qwcytgDyuHdRE
mS1nqdQkAcuxEdTLSwjct0puZTWMR41+NOM0B7qvVLDi2bnONUSS0ktLoEBiYO5D
Q7fpDOg6OZjIjVPYYb7hPSVw+jo+imyqgYdQ9CJu/r9j6Q7pn22NZ8MKWcTFsfYY
ZUhcJp1vHhTGMRupkgTi+oWSA7TFw1oxb1ZFCP1C5hL+mfryybVe5pBEwetOHg8A
DGb6OejvC1/amVArTco7JJ1Ul6Q2IU5UcvuOtmfT7UPNw05O/dIYjjV/BVfBHcGC
cDgVLq8Y6PGHjU2Jx1botuPdMSVsgZrQzbc8h7p02z9Klr9Drzh9+5oox5oxUlqb
A+60+OBHizY4g2/TCKvtPMWtEBt1Wjhayx/fF1EwD7/K16Wb2UFKizKbeZPTXHpH
KlltgVucDvqr/otJFBgS+Kg/7+ITq6hHrB3KCk4bjk+6qSXiZ93p58c4l7+A+JTB
S9q02YQC+cvy0StMrCpuc2R9n9EK0tmXFvv5hF8Ls938caGl6rI=
=S1q0
-----END PGP SIGNATURE-----
Merge tag 'renesas-soc-for-v4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas into next/soc
Pull "Renesas ARM Based SoC Updates for v4.17" from Simon Horman:
01d675f159 ARM: shmobile: rcar-gen2: Add watchdog support
58adf1ba0d ARM: shmobile: Add watchdog support
* SoC
- Identify R-Car V3H (r8a77980) and M3N (r8a77965)
- Enable R-Car Gen2 regulator quirk for Stout board with H3 (r8a7790) SoC
Marek Vaust says "Regulator setup is suboptimal on H2 Stout too. The
Stout newly has two DA9210 regulators, so the quirk is extended to
handle another DA9210 at i2c address 0x70."
- Add watchdog support
This is the SoC portion of the following solution. It is not yet
enabled in DT as it is not functional without clock dependencies
in place.
Fabrizio Castro says "this series has been around for some time as RFC,
and it has collected useful comments from the community along the way.
The solution proposed by this patch set works for most R-Car Gen2 and
RZ/G1 devices, but not all of them. We now know that for some R-Car
Gen2 early revisions there is no proper software fix. Anyway, no
product has been built around early revisions, but development boards
mounting early revisions (basically prototypes) are still out there.
As a result, this series isn't enabling the internal watchdog on R-Car
Gen2 boards, developers may enable it in board specific device trees if
needed. This series has been tested by me on the iwg20d, iwg22d,
Lager, Alt, and Koelsch boards.
The problem
===========
To deal with SMP on R-Car Gen2 and RZ/G1, we install a reset vector to
ICRAM1 and we program the [S]BAR registers so that when we turn ON the
non-boot CPUs they are redirected to the reset vector installed by Linux
in ICRAM1, and eventually they continue the execution to RAM, where the
SMP bring-up code will take care of the rest. The content of the [S]BAR
registers survives a watchdog triggered reset, and as such after the
watchdog fires the boot core will try and execute the SMP bring-up code
instead of jumping to the bootrom code.
The fix
=======
The main strategy for the solution is to let the reset vector decide if
it needs to jump to shmobile_boot_fn or to the bootrom code. In a
watchdog triggered reset scenario, since the [S]BAR registers keep their
values, the boot CPU will jump into the newly designed reset vector, the
assembly routine will eventually test WOVF (a bit in register RWTCSRA
that indicates if the watchdog counter has overflown, the value of this
bit gets retained in this scenario), and jump to the bootrom code which
will in turn load up the bootloader, etc. When bringing up SMP or using
CPU hotplug, the reset vector will jump to shmobile_boot_fn instead."
* R-Car Rst
- Add support for R-Car V3H (r8a77980) and V3H (r8a77980)
* R-Car SYSC
- Mark rcar_sysc_matches[] __initconst
Geert Uytterhoeven says "This frees another 1764 bytes
(arm32/shmobile_defconfig) or 1000 bytes (arm64/renesas_defconfig) of
memory after kernel init."
- Fix power area parents
Sergei Shtylyov says "According to the figure 9.2(b) of the R-Car
Series, 3rd Generation User’s Manual: Hardware Rev. 0.80 the A2IRn and
A2SCn power areas in R8A77970 have the A3IR area as a parent, thus the
SYSC driver has those parents wrong.."
- Add support for R-Car V3H (r8a77980) and V3H (r8a77980)
* tag 'renesas-soc-for-v4.17' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/horms/renesas:
ARM: shmobile: rcar-gen2: Add watchdog support
ARM: shmobile: Add watchdog support
ARM: shmobile: rcar-gen2: Fix error check in regulator quirk
soc: renesas: rcar-rst: Add support for R-Car M3-N
ARM: shmobile: stout: enable R-Car Gen2 regulator quirk
soc: renesas: rcar-sysc: Add R-Car M3-N support
soc: renesas: Identify R-Car M3-N
soc: renesas: rcar-sysc: add R8A77980 support
dt-bindings: power: add R8A77980 SYSC power domain definitions
soc: renesas: r8a77970-sysc: fix power area parents
soc: renesas: rcar-rst: Enable watchdog as reset trigger for Gen2
soc: renesas: rcar-rst: add R8A77980 support
soc: renesas: identify R-Car V3H
soc: renesas: rcar-sysc: Mark rcar_sysc_matches[] __initconst
Linux kernel
============
This file was moved to Documentation/admin-guide/README.rst
Please notice that there are several guides for kernel developers and users.
These guides can be rendered in a number of formats, like HTML and PDF.
In order to build the documentation, use ``make htmldocs`` or
``make pdfdocs``.
There are various text files in the Documentation/ subdirectory,
several of them using the Restructured Text markup notation.
See Documentation/00-INDEX for a list of what is contained in each file.
Please read the Documentation/process/changes.rst file, as it contains the
requirements for building and running the kernel, and information about
the problems which may result by upgrading your kernel.
59162c9366