The Cortex-A57 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 1561f20760 ("arm64: dts: r8a7796: Add Renesas R8A7796 SoC support")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A57/A53 cache controllers are integrated controllers, and
thus the device nodes representing them should not have unit-addresses
or reg properties.
Fixes: 6f7bf82cc9 ("arm64: dts: r8a7795: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>From PSCI v1.0, Suspend-to-RAM is supported via SYSTEM_SUSPEND PSCI
function call. Hence, upgrade PSCI version for R-Car M3-W to support
Suspend-to-RAM.
The Suspend-to-RAM is highly dependent on ARM Trusted Firwmare support
since necessary callback functions will be registered after a query
to ARM Trusted Firmware about SYSTEM_SUSPEND support.
Since PSCI v1.0 is backward compatible with PSCI v0.2, CPU Hotplug and
CPUIdle should be able to work normally with this change.
Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@renesas.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Keep "arm,psci-0.2"]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
>From PSCI v1.0, Suspend-to-RAM is supported via SYSTEM_SUSPEND PSCI
function call. Hence, upgrade PSCI version for R-Car H3 to support
Suspend-to-RAM.
The Suspend-to-RAM is highly dependent on ARM Trusted Firwmare support
since necessary callback functions will be registered after a query
to ARM Trusted Firmware about SYSTEM_SUSPEND support.
Since PSCI v1.0 is backward compatible with PSCI v0.2, CPU Hotplug and
CPUIdle should be able to work normally with this change.
Signed-off-by: Khiem Nguyen <khiem.nguyen.xt@renesas.com>
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
[geert: Keep "arm,psci-0.2"]
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Enable the performance monitor unit for the Cortex-A53 cores on the
R8A7795 SoC.
Extracted from a patch by Takeshi Kihara in the BSP.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
This patch adds Cortex-A53 CPU cores to r8a7795 SoC for a total of 8
cores (4 x Cortex-A57 + 4 x Cortex-A53).
Based on work by Takeshi Kihara and Dirk Behme.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Add the device nodes for all HSCIF serial ports, incl. clocks, and
power domain.
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
[simon: express register size in hex; refer to power domain in changelog]
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Current Audio-DMAC is assigned "rx" as Audio-DMAC0, "tx" as Audio-DMAC1.
Thus, DVC "tx" should be assigned as Audio-DMAC1, instead of Audio-DMAC0.
Because of this, current platform board (using SRC/DVC/SSI)
Playback/Capture both will use same Audio-DMAC0
(but it depends on data path).
First note is that this "rx" and "tx" are from each IP point,
it doesn't mean Playback/Capture.
Second note is that Audio DMAC assigned on DT is only for
Audio-DMAC, Audio-DMAC-peri-peri has no entry.
=> Audio-DMAC
-> Audio-DMAC-peri-peri
-- HW connection
Playback case
[Mem] => [SRC]--[DVC] -> [SSI]--[Codec]
rx ~~~~~~~~~~~~
Capture
[Mem] <= [DVC]--[SRC] <- [SSI]--[Codec]
tx ~~~~~~~~~~~~
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A7 cache controller is an integrated controller, and thus the
device node representing it should not have a unit-addresses or reg
property.
Fixes: 34ea4b4a82 ("ARM: dts: r8a7794: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: ad53f5f00b ("ARM: dts: r8a7793: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 7c4163aae3 ("ARM: dts: r8a7792: initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 6f9314ce25 ("ARM: dts: r8a7791: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A15/A7 cache controllers are integrated controllers, and thus
the device nodes representing them should not have unit-addresses or reg
properties.
Fixes: 2c3de36700 ("ARM: dts: r8a7790: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A7 cache controller is an integrated controller, and thus the
device node representing it should not have a unit-addresses or reg
property.
Fixes: c95360247b ("ARM: dts: r8a7745: initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A15 cache controller is an integrated controller, and thus
the device node representing it should not have a unit-addresses or reg
property.
Fixes: 34e8d993a6 ("ARM: dts: r8a7743: initial SoC device tree")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The Cortex-A15/A7 cache controllers are integrated controllers, and thus
the device nodes representing them should not have unit-addresses or reg
properties.
Fixes: b0da45c60d ("ARM: dts: r8a73a4: Fix W=1 dtc warnings")
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
The skeleton.dtsi file is now deprecated as noted in commit 9c0da3cc61
("ARM: dts: explicitly mark skeleton.dtsi as deprecated"). The SoCFPGA
device trees already contain the nodes that are defined in skeleton.dtsi
(#address-cells, #size-cells, chosen, aliases, memory).
Including skeleton.dtsi is useless and will produce the following
warning when compiled with W=1:
Node /memory has a reg or ranges property, but no unit name
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
GPIO LEDs in the Cyclone5 EBV SOCrates board have a unit name but no reg
property. Indeed, GPIO LEDs do not need such a property. They do not
need a unit name neither. This will trigger the following warnings when
compiled with W=1:
Node /gpio-leds/led@0 has a unit name, but no reg property
Node /gpio-leds/led@1 has a unit name, but no reg property
Node /gpio-leds/led@2 has a unit name, but no reg property
The solution is to remove the unit name. In order to have unique node
names, a rename is necessary. This should be harmless as all the LEDs
have a 'label' property, hence their name do not derive from the node
name and will stay the same after this patch.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
The stmpe_touchscreen node in Cyclone5 MCV EVK has a reg property, but
this is not used by the driver. Moreover the binding documentation do
not define this property. Having a reg property without a unit name will
trigger the following warning when compiled with W=1:
Node /soc/i2c@ffc04000/stmpe811@41/stmpe_touchscreen has a reg or ranges
property, but no unit name
Remove the superfluous reg property.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Node eccmgr has a unit name, but do not have a reg property as only the
child nodes do have this property. Likewise the usbphy node do not have
a reg property. This will trigger the following warnings when compiled
with W=1:
Node /soc/eccmgr@ffd08140 has a unit name, but no reg property
Node /soc/usbphy@0 has a unit name, but no reg property
Remove the superfluous unit names.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Memory nodes in Arria5, Cyclone5 and Arria10 do not have a unit name.
This will trigger several warnings like this one (when compiled with
W=1):
Node /memory has a reg or ranges property, but no unit name
Add the corresponding unit name to each node.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Most clock nodes in Arria5, Cyclone5 and Arria10 have a reg property but
does not have a unit name. This will trigger several warnings like this
one (when compiled with W=1):
Node /soc/clkmgr@ffd04000/clocks/periph_pll has a reg or ranges
property, but no unit name
Add the corresponding unit name to each node.
Signed-off-by: Florian Vaussard <florian.vaussard@heig-vd.ch>
Signed-off-by: Dinh Nguyen <dinguyen@kernel.org>
Fix warnings reported when built with W=1:
Node /memory has a reg or ranges property, but no unit name
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Fix warnings reported when built with W=1:
Node /memory has a reg or ranges property, but no unit name
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Commit 9c0da3cc61 ("ARM: dts: explicitly mark skeleton.dtsi as
deprecated") declared that skeleton.dtsi was deprecated.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
It's preferred to have DT source files licensed under BSD compatible
license. All new BCM5301X DTS files use ISC so let's also relicense old
ones to it.
Except for me only Hauke was ever touched these files in his commit
9faa5960ee ("ARM: BCM5301X: add NAND flash chip description") and
commit bb1d8fba19 ("ARM: BCM5301X: add NAND flash chip description for
Asus RT-AC87U").
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Acked-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
As OMAP uses the standard suspend_valid_only_mem() for its
platform_suspend_ops.valid() callback, its platform_suspend_ops.enter()
callback will never be called with state equal to PM_SUSPEND_STANDBY.
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The ethmac node has to be configured for each board due to different
pinctrl nodes for RGMII/RMII. Thus the phy-mode should be specified at
the same place (= in the board .dts), making it easier to read the board
.dts file (because the phy-mode is stated explicitly, without requiring
developers to read all "parent" .dtsi as well).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Amlogic's own .dts specifies that the P201 board uses a RMII PHY (with
the reset GPIO being GPIOZ_14).
However our P201 board .dts simply inherits the phy-mode setting from
from meson-gx.dtsi where it defaults to RGMII mode.
Remove all ethernet settings from meson-gxbb-p20x.dtsi as it only
specifies the RGMII pins which are only valid for the P200 board.
Instead we add the ethmac node to the meson-gxbb-p201.dts and configure
the pinctrl property and the phy-mode for an RMII PHY.
An MDIO node (which would also specify the PHY) is not added since we
don't know which PHY is being used (and thus which PHY address would
have to be used).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state.
While here also specify the phy-handle of the ethmac node to make the
PHY configuration similar to the one we have on GXL devices. This will
allow us to specify OF-properties for the PHY itself.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
This resets the ethernet PHY during boot to get the PHY into a "clean"
state. While here also explicitly specify the phy-mode instead of
relying on the default-value from meson-gx.dtsi.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Tested-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
This enables the leds-pwm driver to support LEDs which are PWM-powered
(and thus dimmable). Additionally we have to enable the "default-on"
trigger - this was not required before because the gpio-leds driver has
a separate "default-state" property which can be used to enable the LED
by default.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
The modules stay disabled by default, and if you want to enable DSI
you'll need an overlay that connects a panel to it.
Signed-off-by: Eric Anholt <eric@anholt.net>
AM335x, AM437x, DRA7xx, and AM57xx platforms all now depend on
ti-cpufreq driver to enable proper OPPs for use with cpufreq, so
enable the same.
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
Reviewed-by: Lukasz Majewski <lukma@denx.de>
Signed-off-by: Tony Lindgren <tony@atomide.com>
VMCLEAR should silently ignore a failure to clear the launch state of
the VMCS referenced by the operand.
Signed-off-by: Jim Mattson <jmattson@google.com>
[Changed "kvm_write_guest(vcpu->kvm" to "kvm_vcpu_write_guest(vcpu".]
Signed-off-by: Radim Krčmář <rkrcmar@redhat.com>
Droid4's touchscreen can be used with mainline's maxtouch driver. The
touchscreen's lower area is used for four soft buttons (KEY_MENU,
KEY_HOME, KEY_BACK, KEY_SEARCH), but that does not seem to be currently
supported by the mainline kernel.
The mxt224 configuration can be saved with "mxt-app" for the kernel
to load. It can be saved after the first boot with:
# mxt-app -d i2c-dev:1-004a --save /lib/firmware/maxtouch.cfg
Where the mxt-app can be found at:
https://github.com/atmel-maxtouch/mxt-app
The firmware for the droid 4 mxt224 comes with GPLv2 license in the
Motorola Linux kernel sources. This firmware can be dumped out with
"droid4-touchscreen-firmware" program at:
https://github.com/tmlind/droid4-touchscreen-firmware
The related LCD patches are still pending, but when merged,
the touchscreen can be rotated in X with something like:
# xrandr --output DSI-1 --rotate right
# xinput set-prop 6 'Coordinate Transformation Matrix' \
0 1 0 -1 0 1 0 0 1
For now, we rely on a gpio-hog but later on we can add the reset
gpio handling to the driver and have it load the maxtouch.cfg and
maxtouch.fw on boot.
This patch is based on combined similar patches done by me and
Sebastian.
Signed-off-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
