Add support for identifying the remaining R-Car Gen3e SoCs: R-Car H3e
(R8A779M0), M3e (R8A779M2), M3Ne (R8A779M4), M3Ne-2G (R8A779M5), E3e
(R8A779M6), D3e (R8A779M7), and H3Ne (R8A779M8).
As these are different gradings of the already supported R-Car Gen3
SoCs, support for them is enabled through the existing ARCH_R8A779*
configuration symbols.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/ccf2206b24147b3d977e4119bbdefaedceb28644.1628766192.git.geert+renesas@glider.be
strcpy() performs no bounds checking on the destination buffer. This
could result in linear overflows beyond the end of the buffer, leading
to all kinds of misbehaviors. So, use memcpy() as a safe replacement.
This is a previous step in the path to remove the strcpy() function
entirely from the kernel.
Signed-off-by: Len Baker <len.baker@gmx.com>
Link: https://lore.kernel.org/r/20210808125012.4715-3-len.baker@gmx.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Currently, there are two drivers binding to the R-Mobile System
Controller (SYSC):
- The rmobile-sysc driver registers PM domains from a core_initcall(),
and does not use a platform driver,
- The optional rmobile-reset driver registers a reset handler, and
does use a platform driver.
As fw_devlink only considers devices, commit bab2d712ee ("PM:
domains: Mark fwnodes when their powerdomain is added/removed") works
only for PM Domain drivers where the DT node is a real device node, and
not for PM Domain drivers using a hierarchical representation inside a
subnode. Hence if fw_devlink is enabled, probing of on-chip devices
that are part of the SYSC PM domain is deferred until the optional
rmobile-reset driver has been bound. If the rmobile-reset driver is
not available, this will never happen, and thus lead to complete system
boot failures.
Fix this by explicitly marking the fwnode initialized.
Suggested-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210216123958.3180014-1-geert+renesas@glider.be
The R-Car System Controller (SYSC) driver registers PM domains from an
early_initcall(). It does not use a platform driver, as secondary CPU
startup on R-Car H1 needs to control the CPU power domains, before
initialization of the driver framework.
As fw_devlink only considers devices, it does not know that the System
Controller is ready. Hence probing of on-chip devices that are part of
the SYSC PM domain fails if fw_devlink is enabled:
probe deferral - supplier e6180000.system-controller not ready
Fix this by setting the OF_POPULATED flag for the SYSC device node after
successful initialization. This will make of_link_to_phandle() ignore
the SYSC device node as a dependency, and consumer devices will be
probed again.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Saravana Kannan <saravanak@google.com>
Link: https://lore.kernel.org/r/20210128082847.2205950-1-geert+renesas@glider.be
Now, Renesas SoC drivers are under menu, but current descriptions are
not aligned.
This patch aligns them.
- Emma Mobile EV2
- RZ/A1H (R7S72100)
...
- R-Car H2 (R8A77900)
...
- Renesas R-Car H3 ES1.x SoC Platform
...
- R-Car H2 System Controller support
- R-Car M2-W/N System Controller support
- R-Car V2H System Controller support
- R-Car E2 System Controller support
- R-Car H3 System Controller support
- R-Car M3-W System Controller support
- R-Car M3-W+ System Controller support
- R-Car M3-N System Controller support
+ SoC Platform support for Emma Mobile EV2
+ SoC Platform support for RZ/A1H+
...
+ SoC Platform support for R-Car H2
...
+ SoC Platform support for R-Car H3 ES1.x
...
+ System Controller support for R-Car H2
+ System Controller support for R-Car M2-W/N
+ System Controller support for R-Car V2H
+ System Controller support for R-Car E2
+ System Controller support for R-Car H3
+ System Controller support for R-Car M3-W
+ System Controller support for R-Car M3-W+
+ System Controller support for R-Car M3-N
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://lore.kernel.org/r/87zh6kyedc.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Pull ARM driver updates from Arnd Bergmann:
"These are the usual updates for SoC specific device drivers and
related subsystems that don't have their own top-level maintainers:
- ARM SCMI/SCPI updates to allow pluggable transport layers
- TEE subsystem cleanups
- A new driver for the Amlogic secure power domain controller
- Various driver updates for the NXP Layerscape DPAA2, NXP i.MX SCU
and TI OMAP2+ sysc drivers.
- Qualcomm SoC driver updates, including a new library module for
"protection domain" notifications
- Lots of smaller bugfixes and cleanups in other drivers"
* tag 'arm-drivers-5.7' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (70 commits)
soc: fsl: qe: fix sparse warnings for ucc_slow.c
soc: fsl: qe: ucc_slow: remove 0 assignment for kzalloc'ed structure
soc: fsl: qe: fix sparse warnings for ucc_fast.c
soc: fsl: qe: fix sparse warnings for qe_ic.c
soc: fsl: qe: fix sparse warnings for ucc.c
soc: fsl: qe: fix sparse warning for qe_common.c
soc: fsl: qe: fix sparse warnings for qe.c
soc: qcom: Fix QCOM_APR dependencies
soc: qcom: pdr: Avoid uninitialized use of found in pdr_indication_cb
soc: imx: drop COMPILE_TEST for IMX_SCU_SOC
firmware: imx: add COMPILE_TEST for IMX_SCU driver
soc: imx: gpc: fix power up sequencing
soc: imx: increase build coverage for imx8m soc driver
soc: qcom: apr: Add avs/audio tracking functionality
dt-bindings: soc: qcom: apr: Add protection domain bindings
soc: qcom: Introduce Protection Domain Restart helpers
devicetree: bindings: firmware: add ipq806x to qcom_scm
memory: tegra: Correct debugfs clk rate-range on Tegra124
memory: tegra: Correct debugfs clk rate-range on Tegra30
memory: tegra: Correct debugfs clk rate-range on Tegra20
...
SH-Mobile AG5 and R-Car H1 SoCs are based on the Cortex-A9 MPCore, which
includes a global timer.
Enable the ARM global timer on these SoCs, which will be used for:
- the scheduler clock, improving scheduler accuracy from 10 ms to 3 or
4 ns,
- delay loops, allowing removal of calls to shmobile_init_delay() from
the corresponding machine vectors.
Note that when using an old DTB lacking the global timer, the kernel
will still work. However, loops-per-jiffies will no longer be preset,
and the delay loop will need to be calibrated during boot.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191211135222.26770-5-geert+renesas@glider.be
Despite using the same compatible values ("r8a7795"-based) because of
historical reasons, R-Car H3 ES1.x (R8A77950) and R-Car H3 ES2.0+
(R8A77951) are really different SoCs, with different part numbers.
Reflect this in the SoC configuration, by adding CONFIG_ARCH_R8A77950
and CONFIG_ARCH_R8A77951 as new config symbols. These are intended to
replace CONFIG_ARCH_R8A7795, and will allow making support for early SoC
revisions optional.
Note that for now, CONFIG_ARCH_R8A7795 is retained, and just selects
CONFIG_ARCH_R8A77950 and CONFIG_ARCH_R8A77951. This relaxes
dependencies of other subsystems on the SoC configuration symbol, and
provides a smooth transition path for config files through "make
oldconfig".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191217183841.432-6-geert+renesas@glider.be
The configure call back takes a register pointer, so should
have been marked with __iomem. Add this to silence the
following sparse warnings:
drivers/soc/renesas/rcar-rst.c:33:22: warning: incorrect type in initializer (incompatible argument 1 (different address spaces))
drivers/soc/renesas/rcar-rst.c:33:22: expected int ( *configure )( ... )
drivers/soc/renesas/rcar-rst.c:33:22: got int ( * )( ... )
drivers/soc/renesas/rcar-rst.c:97:40: warning: incorrect type in argument 1 (different address spaces)
drivers/soc/renesas/rcar-rst.c:97:40: expected void *base
drivers/soc/renesas/rcar-rst.c:97:40: got void [noderef] <asn:2> *[assigned] base
Signed-off-by: Ben Dooks (Codethink) <ben.dooks@codethink.co.uk>
Link: https://lore.kernel.org/r/20191218135230.2610161-1-ben.dooks@codethink.co.uk
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Add support for the power areas in the Renesas R-Car M3-W+ (R8A77961)
SoC to the R-Car System Controller driver.
R-Car M3-W+ (aka R-Car M3-W ES3.0) is very similar to R-Car
M3-W (R8A77960), which allows for both SoCs to share a driver:
- R-Car M3-W+ lacks the A2VC power area, so its area must be
nullified,
- The existing support for the SYSCEXTMASK register added in commit
9bd645af9d2a49ac ("soc: renesas: r8a7796-sysc: Fix power request
conflicts") applies to ES3.0 and later only.
As R-Car M3-W+ uses a different compatible value, differentiate
based on that, instead of on the ES version.
Based on a patch in the BSP by Dien Pham <dien.pham.ry@renesas.com>.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Tested-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191023123342.13100-7-geert+renesas@glider.be
Add CONFIG_ARCH_R8A77960 as a new config symbol for R-Car M3-W
(R8A77960), to replace CONFIG_ARCH_R8A7796, and avoid confusion with
R-Car M3-W+ (R8A77961), which will use CONFIG_ARCH_R8A77961.
Note that for now, CONFIG_ARCH_R8A7796 is retained, and just selects
CONFIG_ARCH_R8A77960. This relaxes dependencies of other subsystems on
the SoC configuration symbol, and provides a smooth transition path for
config files through "make oldconfig".
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Link: https://lore.kernel.org/r/20191023123342.13100-3-geert+renesas@glider.be
If the DTB for a device with an RZ/A2 SoC lacks a device node for the
BSID register, the ID validation code falls back to using a register at
address 0x0, which leads to undefined behavior (e.g. reading back a
random value).
This could be fixed by letting fam_rza2.reg point to the actual BSID
register. However, the hardcoded fallbacks were meant for backwards
compatibility with old DTBs only, not for new SoCs. Hence fix this by
validating renesas_family.reg before using it.
Fixes: 175f435f44 ("soc: renesas: identify RZ/A2")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Link: https://lore.kernel.org/r/20191016143306.28995-1-geert+renesas@glider.be
