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: NArnd Bergmann <arnd@arndb.de>
[Fixup mising Makefile, fixup BB_UID_BASE to fc0]
Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>

We get a harmless warning if the RASPBERRYPI_POWER driver is enabled without
CONFIG_OF during compile testing:

warning: RASPBERRYPI_POWER selects PM_GENERIC_DOMAINS_OF which has unmet direct dependencies (PM_GENERIC_DOMAINS && OF)

There is no need to select PM_GENERIC_DOMAINS_OF if OF is set, so we can
replace the 'select' with a dependency.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Acked-by: NEric Anholt <eric@anholt.net>

Arrays storing values for Power Management Unit for given sleep mode can
be made const.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>

The Tegra XHCI driver does not currently manage the Tegra XUSB power
partitions and so it these partitions have not been enabled by the
bootloader then the system will crash when probing the XHCI device.

While proper support for managing the power partitions is being
developed to the XHCI driver for Tegra, for now power on all the XUSB
partitions for USB host and super-speed on boot if the XHCI driver is
enabled.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

If CONFIG_PM_GENERIC_DOMAINS is not enabled, then power partitions
associated with a device will not be enabled automatically by the PM
core when the device is in use. To avoid situations where a device in
a power partition is to be used but the partition is not enabled,
initialise the power partitions for Tegra early in the boot process and
if CONFIG_PM_GENERIC_DOMAINS is not enabled, then power on all
partitions defined in the device-tree blob.

Note that if CONFIG_PM_GENERIC_DOMAINS is not enabled, after the
partitions are turned on, the clocks and resets used as part of the
sequence for turning on the partition are released again as they are no
longer needed by the PMC driver. Another benefit of this is that this
avoids any issues of sharing resets between the PMC driver and other
device drivers that may wish to independently control a particular
reset.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

When initialising a powergate, only a single error message is shown if
the initialisation fails. Add more error messages to give specific
details of what failed if the initialisation failed and remove the
generic failure message.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Use blank lines after blocks and before labels for consistency with the
existing code in the file.
Signed-off-by: NThierry Reding <treding@nvidia.com>

Commit 0259f522 ('soc/tegra: pmc: Restore base address on probe
failure') fixes an issue where the PMC base address pointer is not
restored on probe failure. However, this fix creates another problem
where if early initialisation of the PMC driver fails and an initial
mapping for the PMC address space is not created, then when the PMC
device is probed, the PMC base address pointer will not be valid and
this will cause a crash when tegra_pmc_init() is called and attempts
to access a register.

Although the PMC address space is mapped a 2nd time during the probe
and so this could be fixed by populating the base address pointer
earlier during the probe, this adds more complexity to the code.
Moreover, the PMC probe also assumes the the soc data pointer is also
initialised when the device is probed and if not will also lead to a
crash when calling tegra_pmc_init_tsense_reset(). Given that if the
early initialisation does fail then something bad has happen, it seems
acceptable to allow the PMC device probe to fail as well. Therefore, if
the PMC base address pointer or soc data pointer are not valid when
probing the PMC device, WARN and return an error.

Fixes: 0259f522 ('soc/tegra: pmc: Restore base address on probe failure')
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Add missing of_node_put() in PMC early initialisation function to avoid
leaking the device nodes.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
[treding@nvidia.com: squash in a couple more of_node_put() calls]
Signed-off-by: NThierry Reding <treding@nvidia.com>

The mutex used by the PMC driver may not be initialised if early
initialisation of the driver fails. If this does happen, then it could
be possible for callers of the public PMC functions to still attempt to
acquire the mutex. Fix this by initialising the mutex as soon as
possible to ensure it will always be initialised.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The public functions exported by the PMC driver use the presence of the
SoC data pointer to determine if the PMC device is configured and the
registers can be accessed. However, the SoC data is populated before the
PMC register space is mapped and this opens a window where the SoC data
pointer is valid but the register space has not yet been mapped which
could lead to a crash. Furthermore, if the mapping of the PMC register
space fails, then the SoC data pointer is not cleared and so would
expose a larger window where a crash could occur.

Fix this by initialising the SoC data pointer after the PMC register
space has been mapped.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

During early initialisation, the available power partitions for a given
device is configured as well as the polarity of the PMC interrupt. Both
of which should only be configured if there is a valid device node for
the PMC device. This is because the soc data used for configuring the
power partitions is only available if a device node for the PMC is found
and the code to configure the interrupt polarity uses the device node
pointer directly.

Some early device-tree images may not have this device node and so fix
this by ensuring the device node pointer is valid when configuring these
items.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

The function tegra_power_sequence_power_up() is a public function used
to power on a partition. When this function is called, we do not check
to see if the partition being powered up is valid/available. Fix this
by checking to see that the partition is valid/available.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

When registering the Tegra power partitions with the generic PM domain
framework, the current state of the each partition is checked and used
as the default state for the partition. However, the state of each reset
associated with the partition is not initialised and so it is possible
that the state of the resets are not in the expected state. For example,
if a partition is on, then the resets should be de-asserted and if the
partition is off, the resets should be asserted.

There have been cases where the bootloader has powered on a partition
and only de-asserted some of the resets to some of the devices in the
partition. This can cause accesses to these devices to hang the system
when the kernel boots and attempts to probe these devices.

Ideally, the driver for the device should ensure the reset has been
de-asserted when probing, but the resets cannot be shared between the
PMC driver (that needs to de-assert/assert the reset when turning the
partition on or off) and another driver because we cannot ensure the
reset is in the correct state.

To ensure the resets are in the correct state, when using the generic
PM domain framework, put each reset associated with the partition in
the correct state (based upon the partition's current state) when
obtaining the resets for a partition.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

Align SYSC interrupt configuration in the legacy wrapper with the DT
version:
  - Mask SYSC interrupt sources before enabling them (doesn't matter
    much as they're disabled at the GIC level anyway),
  - Make sure not to clear reserved SYSCIMR bits that were set before.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

On R-Car H1 and Gen2, the SYSC interrupt registers are always configured
using hardcoded values in platform code. For R-Car Gen2, values are
provided for H2 and M2-W only, other SoCs are not yet supported, and
never will be.

Move this configuration from SoC-specific platform code to the
rcar_sysc_init() wrapper, so it can be skipped if the SYSC is configured
from DT. This would be the case not only for H1, H2, and M2-W using a
modern DTS, but also for other R-Car Gen2 SoCs not supported by the
platform code, relying purely on DT.

There is no longer a need to return the mapped register block, hence
make the function return void.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NUlrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Let rcar_sysc_init() trigger initialization of the SYSC PM domains from
DT if called before the early_initcall.
On failure, it falls back to mapping the passed register block, as
before.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

On success, rcar_sysc_pd_init() returns an uninitialized error code.
Use the return value of of_genpd_add_provider_onecell() to fix this.

This went unnoticed, as early_initcall() doesn't care about the return
value.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Update the property names to match device tree bindings, the correct
values should be qcom,smem-states and qcom,smem-state-names.

Also update the #qcom,smem-state-cells for consistency, before we merge
any users of these properties.
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Acked-by: NRob Herring <robh@kernel.org>
Signed-off-by: NAndy Gross <andy.gross@linaro.org>

SMEM is now mapped write-combine and we can use memcpy to access the
name of the entires.
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NAndy Gross <andy.gross@linaro.org>

The valid_entries index should not be incremented until after we have
acquired the pointer to the value, or we will read and write data one
item off.

Fixes: 50e99641 ("soc: qcom: smp2p: Qualcomm Shared Memory Point to Point")
Cc: stable@vger.kernel.org
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NAndy Gross <andy.gross@linaro.org>

We need the signal from wcnss_ctrl indicating that the firmware is up
and running before we can communicate with the other components of the
chip. So make these other components children of the wcnss_ctrl device,
so they can be probed in order.

The process seems to take between 1/2-5 seconds, so this is done in a
worker, instead of holding up the probe.
Signed-off-by: NBjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: NAndy Gross <andy.gross@linaro.org>

Add support for R-Car V2H (R8A7792) SoC power areas to the SYSC driver.
Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Use register definitions for the main SoC reset operation instead of
hard-coding magic values. Note that the PMC_RST_STATUS register isn't
actually accessed, but since it is mentioned in a comment the
definitions are added for completeness.
Acked-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

QE has module to support TDM, some other protocols
supported by QE are based on TDM.
add a qe-tdm lib, this lib provides functions to the protocols
using TDM to configurate QE-TDM.
Signed-off-by: NZhao Qiang <qiang.zhao@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Add tdm clock configuration in both qe clock system and ucc
fast controller.
Signed-off-by: NZhao Qiang <qiang.zhao@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

Rx_sync and tx_sync are used by QE-TDM mode,
add them to struct ucc_fast_info.
Signed-off-by: NZhao Qiang <qiang.zhao@nxp.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>

The brcmstb_biuctrl_init() is defined in the soc specific header
file, but wasn't included in the driver file. Fix the following
warning by including <linux/soc/brcmstb/brcmstb.h> in the driver:

drivers/soc/brcmstb/biuctrl.c:101:13: warning: symbol 'brcmstb_biuctrl_init' was not declared. Should it be static?
Signed-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Acked-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

Unify the different Broadcom SoCs directory and have everybody live
under drivers/soc/bcm/*.
Acked-by: NScott Branden <scott.branden@broadcom.com>
Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>

Introduce a platform selectable symbol EXYNOS_PM_DOMAINS which can be
also toggled on by COMPILE_TEST for some build coverage.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>

The ARMv8 Exynos family (Exynos5433 and Exynos7420) uses different value
(0xf instead of 0x7) for controlling the power domain on/off registers
(both for control and for status).

Choose the value depending on the compatible. This prepares the driver
for supporting ARMv8 SoCs.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>

Exynos PM domains driver does not have mach-specific dependencies so it
can be safely moved out of arm/mach-exynos to drivers/soc. This in
future will allow re-using it on ARM64 boards.
Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
Reviewed-by: NJavier Martinez Canillas <javier@osg.samsung.com>

On ARM64, the mtk-pmic-wrap driver causes a harmless warning:

mtk-pmic-wrap.c:1062:16: warning: large integer implicitly truncated to unsigned type [-Woverflow]
mtk-pmic-wrap.c:1074:16: warning: large integer implicitly truncated to unsigned type [-Woverflow]
mtk-pmic-wrap.c:1086:16: warning: large integer implicitly truncated to unsigned type [-Woverflow]
  .int_en_all = ~(BIT(31) | BIT(1)),

The problem is that the result of the BIT() macro is an 'unsigned long',
so taking the bitwise NOT operation of that results in an integer
with the upper 32 bits all set and that cannot be assigned to a
'u32' variable without loss of information.

This is harmless because we were never interested in the upper bits
here anyway, so we can shut up the warning by adding a simple cast
to 'u32'.
Signed-off-by: NArnd Bergmann <arnd@arndb.de>

Adds generic PM domain support to the PMC driver where the PM domains
are populated from device-tree and the PM domain consumer devices are
bound to their relevant PM domains via device-tree as well.

Update the tegra_powergate_sequence_power_up() API so that internally
it calls the same tegra_powergate_xxx functions that are used by the
Tegra generic PM domain code for consistency.

To ensure that the Tegra power domains (a.k.a. powergates) cannot be
controlled via both the legacy tegra_powergate_xxx functions as well
as the generic PM domain framework, add a bit map for available
powergates that can be controlled via the legacy powergate functions.

Move the majority of the tegra_powergate_remove_clamping() function
to a sub-function, so that this can be used by both the legacy and
generic power domain code.

This is based upon work by Thierry Reding <treding@nvidia.com>
and Vince Hsu <vinceh@nvidia.com>.
Signed-off-by: NJon Hunter <jonathanh@nvidia.com>
Signed-off-by: NThierry Reding <treding@nvidia.com>

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

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

R-Car M2-N is identical to R-Car M2-W w.r.t. power domains, so reuse the
definitions from the latter.
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: NLaurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: NSimon Horman <horms+renesas@verge.net.au>

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

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