ARM: ixp4xx: Move NPE and QMGR to drivers/soc

The Network Processing Engine and Queue Manager are
versatile firmware components used by several IXP4xx
drivers.

Drivers are relying on getting access

ARM: ixp4xx: Move NPE and QMGR to drivers/soc

The Network Processing Engine and Queue Manager are
versatile firmware components used by several IXP4xx
drivers.

Drivers are relying on getting access to these components
using <mach/*> headers which does not work with
multiplatform. We need to find a better place for the
drivers to live.

Let's first move them to drivers/soc and the start to
refactor a bit by passing resources and moving headers.

This patch introduce static IRQ assignments but that
will be fixed by later patches in this series.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

show more ...

drivers: soc: Allow building the amlogic drivers without ARCH_MESON

The current condition makes it difficult to compile the amlogic/
drivers with COMPILE_TEST, or without ARCH_MESON in general.

Fix

drivers: soc: Allow building the amlogic drivers without ARCH_MESON

The current condition makes it difficult to compile the amlogic/
drivers with COMPILE_TEST, or without ARCH_MESON in general.

Fixes kbuild errors with patch series that depend on drivers in that
directory, for instance the meson video decoder.

Signed-off-by: Maxime Jourdan <mjourdan@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>

show more ...

drivers: soc: Allow building the sunxi driver without ARCH_SUNXI

This makes it possible to build the sunxi SRAM driver without building
for the sunxi architecture. This allows selecting the driver w

drivers: soc: Allow building the sunxi driver without ARCH_SUNXI

This makes it possible to build the sunxi SRAM driver without building
for the sunxi architecture. This allows selecting the driver when
building the kernel in testing environments.

In particular, this is necessary for testing of the Cedrus driver, that
selects the sunxi SRAM driver.

Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Acked-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>

show more ...

soc: Unconditionally include qcom Makefile

Incoming Qualcomm changes for GENI, i2c [1], and cmd-db [2] are enabled
with COMPILE_TEST in drivers/soc/qcom. For this to work, the Makefile
in that direc

soc: Unconditionally include qcom Makefile

Incoming Qualcomm changes for GENI, i2c [1], and cmd-db [2] are enabled
with COMPILE_TEST in drivers/soc/qcom. For this to work, the Makefile
in that directory has to be included unconditionally, rather than only
if ARCH_QCOM is enabled.

Example of the errors seen on allmodconfig with the GENI, i2c, and
cmd-db patches applied:

Kernel: arch/x86/boot/bzImage is ready (#1)
ERROR: "geni_se_select_mode" [drivers/tty/serial/qcom_geni_serial.ko] undefined!
ERROR: "geni_se_init" [drivers/tty/serial/qcom_geni_serial.ko] undefined!
ERROR: "geni_se_config_packing" [drivers/tty/serial/qcom_geni_serial.ko] undefined!
ERROR: "geni_se_resources_on" [drivers/tty/serial/qcom_geni_serial.ko] undefined!
ERROR: "geni_se_resources_off" [drivers/tty/serial/qcom_geni_serial.ko] undefined!
ERROR: "geni_se_tx_dma_unprep" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
ERROR: "geni_se_tx_dma_prep" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
ERROR: "geni_se_rx_dma_unprep" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
ERROR: "geni_se_rx_dma_prep" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
ERROR: "geni_se_select_mode" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
ERROR: "geni_se_config_packing" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
ERROR: "geni_se_init" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
ERROR: "geni_se_resources_off" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
ERROR: "geni_se_resources_on" [drivers/i2c/busses/i2c-qcom-geni.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:92: __modpost] Error 1
make: *** [Makefile:1237: modules] Error 2

[1] https://patchwork.ozlabs.org/cover/893437/
[2] https://lkml.org/lkml/2018/4/10/714

Signed-off-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Evan Green <evgreen@chromium.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>

show more ...

soc: xilinx: Create folder structure for soc specific drivers

Create directory structure with Makefile/Kconfig for adding xilinx soc
specific drivers.

Signed-off-by: Michal Simek <michal.simek@xili

soc: xilinx: Create folder structure for soc specific drivers

Create directory structure with Makefile/Kconfig for adding xilinx soc
specific drivers.

Signed-off-by: Michal Simek <michal.simek@xilinx.com>

show more ...

soc: Add SoC driver for Gemini

This adds an SoC driver for the Gemini. Currently there
is only one thing not fitting into any other framework,
and that is the bus arbitration setting.

All Gemini ve

soc: Add SoC driver for Gemini

This adds an SoC driver for the Gemini. Currently there
is only one thing not fitting into any other framework,
and that is the bus arbitration setting.

All Gemini vendor trees seem to be setting this register to
exactly the same arbitration so we just add a small code
snippet to do this at subsys_init() time before any other
drivers kick in.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>

show more ...

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine

License cleanup: add SPDX GPL-2.0 license identifier to files with no license

Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.

By default all files without license information are under the default
license of the kernel, which is GPL version 2.

Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.

This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.

How this work was done:

Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,

Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.

The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.

The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.

Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).

All documentation files were explicitly excluded.

The following heuristics were used to determine which SPDX license
identifiers to apply.

- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.

For non */uapi/* files that summary was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139

and resulted in the first patch in this series.

If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:

SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930

and resulted in the second patch in this series.

- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:

SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1

and that resulted in the third patch in this series.

- when the two scanners agreed on the detected license(s), that became
the concluded license(s).

- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.

- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).

- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.

- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.

In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.

Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.

Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.

In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.

Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct

This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.

These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.

Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

show more ...

soc: Allow test-building of MediaTek drivers

The COMPILE_TEST alternative dependency allows test-building the
drivers but only as long as the build system itself will look into
the directory where t

soc: Allow test-building of MediaTek drivers

The COMPILE_TEST alternative dependency allows test-building the
drivers but only as long as the build system itself will look into
the directory where the drivers reside.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Acked-by: Sean Wang <sean.wang@mediatek.com>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>

show more ...

MIPS: lantiq: Convert the fpi bus driver to a platform_driver

Instead of hacking the configuration of the FPI bus into the arch code
add an own bus driver for this internal bus. The FPI bus is the m

MIPS: lantiq: Convert the fpi bus driver to a platform_driver

Instead of hacking the configuration of the FPI bus into the arch code
add an own bus driver for this internal bus. The FPI bus is the main
bus of the SoC. This bus driver makes sure the bus is configured
correctly before the child drivers are getting initialized. This driver
will probably also be used on different SoCs later.

Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Acked-by: Rob Herring <robh@kernel.org>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Cc: john@phrozen.org
Cc: p.zabel@pengutronix.de
Cc: kishon@ti.com
Cc: mark.rutland@arm.com
Cc: linux-mips@linux-mips.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-watchdog@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-spi@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/17122/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>

show more ...

soc: Add Amlogic SoC Information driver

Amlogic SoCs have a SoC information register for SoC type, package type and
revision information.
This patchs adds support for this register decoding and expo

soc: Add Amlogic SoC Information driver

Amlogic SoCs have a SoC information register for SoC type, package type and
revision information.
This patchs adds support for this register decoding and exposing with the
SoC bus infrastructure.

Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>

show more ...

soc: actions: Add Owl SPS

Implement S500 Smart Power System power-gating.
For now flag PD_CPU2 and PD_CPU3 as always-on.

Based on LeMaker linux-actions tree.

Signed-off-by: Andreas Färber <afaerbe

soc: actions: Add Owl SPS

Implement S500 Smart Power System power-gating.
For now flag PD_CPU2 and PD_CPU3 as always-on.

Based on LeMaker linux-actions tree.

Signed-off-by: Andreas Färber <afaerber@suse.de>

show more ...

soc: renesas: Rework Kconfig and Makefile logic

The goals are to:
- Allow precise control over and automatic selection of which
(sub)drivers are used for which SoC,
- Allow adding support fo

soc: renesas: Rework Kconfig and Makefile logic

The goals are to:
- Allow precise control over and automatic selection of which
(sub)drivers are used for which SoC,
- Allow adding support for new SoCs easily,
- Allow compile-testing of all (sub)drivers,
- Keep driver selection logic in the subsystem-specific Kconfig,
independent from the architecture-specific Kconfig (i.e. no "select"
from arch/arm64/Kconfig.platforms), to avoid dependencies.

This is implemented by:
- Introducing Kconfig symbols for all drivers and sub-drivers,
- Introducing the Kconfig symbol SOC_RENESAS, which is enabled
automatically when building for a Renesas ARM platform, and which
enables all required drivers without interaction of the user, based
on SoC-specific ARCH_* symbols,
- Allowing the user to enable any Kconfig symbol manually if
COMPILE_TEST is enabled,
- Using the new Kconfig symbols instead of the ARCH_* symbols to
control compilation in the Makefile,
- Always entering drivers/soc/renesas/ during the build.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

show more ...

ARM: at91: move SoC detection to its own driver

To simplify machine init and as the soc_device struct is not used as the
parent for on-chip devices anymore, move SoC detection to its own driver.

Ch

ARM: at91: move SoC detection to its own driver

To simplify machine init and as the soc_device struct is not used as the
parent for on-chip devices anymore, move SoC detection to its own driver.

Change in dmesg:
- before:
DMA: preallocated 256 KiB pool for atomic coherent allocations
AT91: Detected SoC family: sama5d2
AT91: Detected SoC: sama5d27, revision 0
No ATAGs?
clocksource: tcb_clksrc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 184217874325 ns
at_xdmac f0010000.dma-controller: 16 channels, mapped at 0xe085b000
SCSI subsystem initialized

- after:
DMA: preallocated 256 KiB pool for atomic coherent allocations
No ATAGs?
clocksource: tcb_clksrc: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 184217874325 ns
at_xdmac f0010000.dma-controller: 16 channels, mapped at 0xe0859000
AT91: Detected SoC family: sama5d2
AT91: Detected SoC: sama5d27, revision 0
SCSI subsystem initialized

Suggested-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com>
Signed-off-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>

show more ...

soc: imx: move PGC handling to a new GPC driver

This is an almost complete re-write of the previous GPC power gating control
code found in the IMX architecture code. It supports both the old and the

soc: imx: move PGC handling to a new GPC driver

This is an almost complete re-write of the previous GPC power gating control
code found in the IMX architecture code. It supports both the old and the new
DT binding, allowing more domains to be added later and generally makes the
driver easier to extend, while keeping compatibility with existing DTBs.

As the result, all functionality regarding the power gating controller
gets removed from the IMX architecture GPC driver. It keeps only the
IRQ controller code in the architecture, as this is closely coupled to
the CPU idle implementation.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>

show more ...

soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family

The ARMv8 zx2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value

soc: zte: pm_domains: Prepare for supporting ARMv8 zx2967 family

The ARMv8 zx2967 family (296718, 296716 etc) uses different value
for controlling the power domain on/off registers, Choose the
value depending on the compatible.

Multiple domains are prepared for the family, this patch prepares
the common functions.

Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>

show more ...

ARM: ux500: move soc_id driver to drivers/soc

As the ux500 id code is basically a standalone driver, we can move it
out of the arch code into drivers/soc/ux500.

This is a user-visible change, as it

ARM: ux500: move soc_id driver to drivers/soc

As the ux500 id code is basically a standalone driver, we can move it
out of the arch code into drivers/soc/ux500.

This is a user-visible change, as it moves all the devices in sysfs
from /sys/devices/soc0/ to /sys/devices/ and leaves the soc0 node as a
separate device.

Originally the idea was to put all on-chip devices under the soc node,
and ux500 was the first platform to have this device, but later platforms
almost all didn't follow that pattern, so this makes the platform do
the same thing as everyone else.

Since the platform is really obsolete now, I am optimistic that nothing
will break after moving the devices around.

As the SoC driver no longer has access to the private header files,
I'm changing the code to instead look up the address of the backupram
from devicetree, which is a good idea anyway.

Finally, having a separate Kconfig symbol means the driver is now
optional and could even be a loadable module rather than always being
built-in if we allowed that for soc_device.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
[Fixup mising Makefile, fixup BB_UID_BASE to fc0]
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

show more ...

soc: Move brcmstb to bcm/brcmstb

Unify the different Broadcom SoCs directory and have everybody live
under drivers/soc/bcm/*.

Acked-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Flo

soc: Move brcmstb to bcm/brcmstb

Unify the different Broadcom SoCs directory and have everybody live
under drivers/soc/bcm/*.

Acked-by: Scott Branden <scott.branden@broadcom.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

show more ...

soc: renesas: Move pm-rcar to drivers/soc/renesas/rcar-sysc

Move the pm-rcar driver from arch/arm/mach-shmobile/ to
drivers/soc/renesas/, and its header file to include/linux/soc/renesas/,
so it can

soc: renesas: Move pm-rcar to drivers/soc/renesas/rcar-sysc

Move the pm-rcar driver from arch/arm/mach-shmobile/ to
drivers/soc/renesas/, and its header file to include/linux/soc/renesas/,
so it can be shared between arm32 (R-Car H1 and Gen2) and arm64 (R-Car
Gen3). Rename it to rcar-sysc as it's really a driver for the R-Car
System Controller (SYSC).

Kill the intermediate PM_RCAR config symbol, as it's not user
configurable anymore, and to prepare for SoC-specific make rules.

Add the missing #include <linux/types.h> to rcar-sysc.h, which was
exposed by different include order.

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>

show more ...

drivers: soc: Add support for Exynos PMU driver

This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
to "drivers/soc/samsung". This driver is mainly used for setting misc
bits of

drivers: soc: Add support for Exynos PMU driver

This patch moves Exynos PMU driver implementation from "arm/mach-exynos"
to "drivers/soc/samsung". This driver is mainly used for setting misc
bits of register from PMU IP of Exynos SoC which will be required to
configure before Suspend/Resume. Currently all these settings are done
in "arch/arm/mach-exynos/pmu.c" but moving ahead for ARM64 based SoC
support, there is a need of this PMU driver in driver/* folder.

This driver uses existing DT binding information and there should
be no functionality change in the supported platforms.

Signed-off-by: Amit Daniel Kachhap <amitdanielk@gmail.com>
[tested on Peach-Pi (Exynos5880)]
Signed-off-by: Pankaj Dubey <pankaj.dubey@samsung.com>
Reviewed-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
[for testing on Trats2 (Exynos4412) and Odroid XU3 (Exynos5422)]
Tested-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>
[k.kozlowski: Rebased, add necessary infrastructure for building and
selecting drivers/soc because original patchset was on top of movement
SROMc to drivers/soc]
Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com>

show more ...

QE: Move QE from arch/powerpc to drivers/soc

ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm

Signed-off-by: Zhao Qiang <qiang.zhao@freescale

QE: Move QE from arch/powerpc to drivers/soc

ls1 has qe and ls1 has arm cpu.
move qe from arch/powerpc to drivers/soc/fsl
to adapt to powerpc and arm

Signed-off-by: Zhao Qiang <qiang.zhao@freescale.com>
Signed-off-by: Scott Wood <scottwood@freescale.com>

show more ...

ARM: bcm2835: add rpi power domain driver

This patch adds support for several power domains on Raspberry Pi,
including USB (so it can be enabled even if the bootloader didn't do
it), and graphics.

ARM: bcm2835: add rpi power domain driver

This patch adds support for several power domains on Raspberry Pi,
including USB (so it can be enabled even if the bootloader didn't do
it), and graphics.

This patch is the combined work of Eric Anholt (who wrote USB support
inside of the Raspberry Pi firmware driver, and wrote the non-USB
domain support) and Alexander Aring (who separated the original USB
work out from the firmware driver).

Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
Reviewed-by: Kevin Hilman <khilman@linaro.org>

show more ...

soc: dove: add legacy support to PMU driver

Add support for legacy non-DT Dove to the PMU driver, so that we can
transition the legacy support over.

[gregory.clement@free-electrons.com: removed pm_

soc: dove: add legacy support to PMU driver

Add support for legacy non-DT Dove to the PMU driver, so that we can
transition the legacy support over.

[gregory.clement@free-electrons.com: removed pm_genpd_poweroff_unused]
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...

soc: rockchip: power-domain: Add power domain driver

This driver is found on RK3288 SoCs.

In order to meet high performance and low power requirements, a power
management unit is designed or saving

soc: rockchip: power-domain: Add power domain driver

This driver is found on RK3288 SoCs.

In order to meet high performance and low power requirements, a power
management unit is designed or saving power when RK3288 in low power
mode.
The RK3288 PMU is dedicated for managing the power of the whole chip.

PMU can work in the Low Power Mode by setting bit[0] of PMU_PWRMODE_CON
register. After setting the register, PMU would enter the Low Power mode.
In the low power mode, pmu will auto power on/off the specified power
domain, send idle req to specified power domain, shut down/up pll and
so on. All of above are configurable by setting corresponding registers.

Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-by: Kevin Hilman <khilman@linaro.org>

[replace dsb() with dsb(sy) for arm64 buildability; sy is the default,
so no functional change; adapt to per-user clocks in genpd]
Signed-off-by: Heiko Stuebner <heiko@sntech.de>

show more ...

soc: add stubs for brcmstb SoC's

Used on BCM7xxx Set-Top Box chips (e.g., BCM7445).

Signed-off-by: Brian Norris <computersforpeace@gmail.com>
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>

ARM: dove: create a proper PMU driver for power domains, PMU IRQs and resets

The PMU device contains an interrupt controller, power control and
resets. The interrupt controller is a little sub-stan

ARM: dove: create a proper PMU driver for power domains, PMU IRQs and resets

The PMU device contains an interrupt controller, power control and
resets. The interrupt controller is a little sub-standard in that
there is no race free way to clear down pending interrupts, so we try
to avoid problems by reducing the window as much as possible, and
clearing as infrequently as possible.

The interrupt support is implemented using an IRQ domain, and the
parent interrupt referenced in the standard DT way.

The power domains and reset support is closely related - there is a
defined sequence for powering down a domain which is tightly coupled
with asserting the reset. Hence, it makes sense to group these two
together, and in order to avoid any locking contention disrupting this
sequence, we avoid the use of syscon or regmap.

This patch adds the core PMU driver: power domains must be defined in
the DT file in order to make use of them. The reset controller can
be referenced in the standard way for reset controllers.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

show more ...