linux-toradex.git/arch/arm/mach-ux500, branch master Linux kernel for Apalis and Colibri modules ARM: ux500: Move power-domain driver to the genpd dir 2023-07-14T08:41:59+00:00 Ulf Hansson ulf.hansson@linaro.org 2023-06-30T14:28:16+00:00 b43f11e5b453a9c48159d7121c88d79d81901276 To simplify with maintenance let's move the ux500 power-domain driver to the new genpd directory. Going forward, patches are intended to be managed through a separate git tree, according to MAINTAINERS. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
To simplify with maintenance let's move the ux500 power-domain driver to
the new genpd directory. Going forward, patches are intended to be managed
through a separate git tree, according to MAINTAINERS.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
ARM: ux500: Convert power-domain code into a regular platform driver 2023-07-14T08:41:59+00:00 Ulf Hansson ulf.hansson@linaro.org 2023-06-30T14:11:57+00:00 bd4ce2d7f988c9becd711973e2b751c6cb5f391a To make the code more standalone and moveable, let's convert it into a platform driver. Cc: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org> 
To make the code more standalone and moveable, let's convert it into a
platform driver.

Cc: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
ARM: ux500: Drop unused register file 2022-11-08T20:18:42+00:00 Linus Walleij linus.walleij@linaro.org 2022-11-08T20:18:42+00:00 2f89fbc94bce85b4253358bf6554d9d6fc36825f This file with all base addresses and offsets is not used anymore, everything is looked up from the device tree. Delete it. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
This file with all base addresses and offsets is not
used anymore, everything is looked up from the device
tree. Delete it.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
arm/mach-ux500: fix repeated words in comments 2022-11-07T22:19:47+00:00 wangjianli wangjianli@cdjrlc.com 2022-10-20T12:45:58+00:00 b29ea0e7e8122a11e9336fb89e96ca7ccdb314ae Delete the redundant word 'in'. Signed-off-by: wangjianli <wangjianli@cdjrlc.com> Link: https://lore.kernel.org/r/20221020124558.38060-1-wangjianli@cdjrlc.com Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
Delete the redundant word 'in'.

Signed-off-by: wangjianli <wangjianli@cdjrlc.com>
Link: https://lore.kernel.org/r/20221020124558.38060-1-wangjianli@cdjrlc.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
ARM: remove support for NOMMU ARMv4/v5 2022-03-17T08:13:13+00:00 Arnd Bergmann arnd@arndb.de 2022-03-09T13:20:20+00:00 2f618d5ef5dd05e2380ee627814de90d5a33c3f2 It is possible to build MMU-less kernels for Cortex-M base microcrontrollers as well as a couple of older platforms that have not been converted to CONFIG_ARCH_MULTIPLATFORM, specifically ep93xx, footbridge, dove, sa1100 and s3c24xx. It seems unlikely that anybody has tested those configurations in recent years, as even building them is frequently broken. A patch I submitted caused another build time regression in this configuration. I sent a patch for that, but it seems better to also remove the option entirely, leaving ARMv7-M as the only supported Arm NOMMU target for simplicity. A couple of platforms have dependencies on CONFIG_MMU, those can all be removed now. Notably, mach-integrator tries to support MMU-less CPU cores, but those have not actually been selectable for a long time. This addresses several build failures in randconfig builds that have accumulated over the years. Cc: Vladimir Murzin <vladimir.murzin@arm.com> Cc: Russell King <linux@armlinux.org.uk> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Reviewed by: Ard Biesheuvel <ardb@kernel.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
It is possible to build MMU-less kernels for Cortex-M base
microcrontrollers as well as a couple of older platforms that
have not been converted to CONFIG_ARCH_MULTIPLATFORM,
specifically ep93xx, footbridge, dove, sa1100 and s3c24xx.

It seems unlikely that anybody has tested those configurations
in recent years, as even building them is frequently broken.
A patch I submitted caused another build time regression
in this configuration. I sent a patch for that, but it seems
better to also remove the option entirely, leaving ARMv7-M
as the only supported Arm NOMMU target for simplicity.

A couple of platforms have dependencies on CONFIG_MMU, those
can all be removed now. Notably, mach-integrator tries to
support MMU-less CPU cores, but those have not actually been
selectable for a long time.

This addresses several build failures in randconfig builds that
have accumulated over the years.

Cc: Vladimir Murzin <vladimir.murzin@arm.com>
Cc: Russell King <linux@armlinux.org.uk>
Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
clk: ux500: Add driver for the reset portions of PRCC 2021-10-27T01:06:05+00:00 Linus Walleij linus.walleij@linaro.org 2021-09-21T18:48:03+00:00 b14cbdfd467d1e505ad8e03f94e18b3cffc37043 The Ux500 PRCC (peripheral reset and clock controller) can also control reset of the IP blocks, not just clocks. As the PRCC is probed as a clock controller and we have other platforms implementing combined clock and reset controllers, follow this pattern and implement the PRCC rest controller as part of the clock driver. The reset controller needs to be selected from the machine as Ux500 has traditionally selected its mandatory subsystem prerequisites from there. Cc: Philipp Zabel <p.zabel@pengutronix.de> Cc: Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210921184803.1757916-2-linus.walleij@linaro.org Acked-by: Ulf Hansson <ulf.hansson@linaro.org> [sboyd@kernel.org: Dropped allocation error message] Signed-off-by: Stephen Boyd <sboyd@kernel.org> 
The Ux500 PRCC (peripheral reset and clock controller) can also
control reset of the IP blocks, not just clocks. As the PRCC is probed
as a clock controller and we have other platforms implementing combined
clock and reset controllers, follow this pattern and implement the PRCC
rest controller as part of the clock driver.

The reset controller needs to be selected from the machine as Ux500 has
traditionally selected its mandatory subsystem prerequisites from there.

Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210921184803.1757916-2-linus.walleij@linaro.org
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
[sboyd@kernel.org: Dropped allocation error message]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
ARM: ux500: make ux500_cpu_die static 2021-04-01T20:30:49+00:00 Ben Dooks ben.dooks@codethink.co.uk 2021-03-23T08:32:03+00:00 758c5408ea3d6d730ee388ad8354c4fe94685d4c The ux500_cpu_die function is not exported so make it static to avoid the following warning: arch/arm/mach-ux500/platsmp.c:89:6: warning: symbol 'ux500_cpu_die' was not declared. Should it be static? Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Link: https://lore.kernel.org/r/20210323083203.1646842-1-linus.walleij@linaro.org' Signed-off-by: Arnd Bergmann <arnd@arndb.de> 
The ux500_cpu_die function is not exported so make it static
to avoid the following warning:

arch/arm/mach-ux500/platsmp.c:89:6: warning: symbol 'ux500_cpu_die' was not declared. Should it be static?

Signed-off-by: Ben Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Link: https://lore.kernel.org/r/20210323083203.1646842-1-linus.walleij@linaro.org'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
mfd: db8500-prcmu: Support U8420-sysclk firmware 2019-11-11T08:45:04+00:00 Linus Walleij linus.walleij@linaro.org 2019-10-26T21:47:32+00:00 22fb3ad0cc5f578398953ddcab9c8239a08caccd There is a distinct version of the Ux500 U8420 variant with "sysclk", as can be seen from the vendor code that didn't make it upstream, this firmware lacks the ULPPLL (ultra-low power phase locked loop) which in effect means that the timer clock is instead wired to the 32768 Hz always-on clock. This has some repercussions when enabling the timer clock as the code as it stands will disable the timer clock on these platforms (lacking the so-called "doze mode") and obtaining the wrong rate of the timer clock. The timer frequency is of course needed very early in the boot, and as a consequence, we need to shuffle around the early PRCMU init code: whereas in the past we did not need to look up the PRCMU firmware version in the early init, but now we need to know the version before the core system timers are registered so we restructure the platform callbacks to the PRCMU so as not to take any arguments and instead look up the resources it needs directly from the device tree when initializing. As we do not yet support any platforms using this firmware it is not a regression, but as PostmarketOS is starting to support products with this firmware we need to fix this up. The low rate of 32kHz also makes the MTU timer unsuitable as delay timer but this needs to be fixed in a separate patch. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Stephan Gerhold <stephan@gerhold.net> Acked-by: Olof Johansson <olof@lixom.net> Signed-off-by: Lee Jones <lee.jones@linaro.org> 
There is a distinct version of the Ux500 U8420 variant
with "sysclk", as can be seen from the vendor code that
didn't make it upstream, this firmware lacks the
ULPPLL (ultra-low power phase locked loop) which in
effect means that the timer clock is instead wired to
the 32768 Hz always-on clock.

This has some repercussions when enabling the timer
clock as the code as it stands will disable the timer
clock on these platforms (lacking the so-called
"doze mode") and obtaining the wrong rate of the timer
clock.

The timer frequency is of course needed very early in
the boot, and as a consequence, we need to shuffle
around the early PRCMU init code: whereas in the past
we did not need to look up the PRCMU firmware version
in the early init, but now we need to know the version
before the core system timers are registered so we
restructure the platform callbacks to the PRCMU so as
not to take any arguments and instead look up the
resources it needs directly from the device tree
when initializing.

As we do not yet support any platforms using this
firmware it is not a regression, but as PostmarketOS
is starting to support products with this firmware we
need to fix this up.

The low rate of 32kHz also makes the MTU timer unsuitable
as delay timer but this needs to be fixed in a separate
patch.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Stephan Gerhold <stephan@gerhold.net>
Acked-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Lee Jones <lee.jones@linaro.org>
ARM: ux500: Stop populating the PRCMU devices early 2019-07-23T07:17:06+00:00 Linus Walleij linus.walleij@linaro.org 2019-07-15T08:06:35+00:00 7a8689df21f425e77207b4245b0b89d3185866e7 The PRCMU devices are getting populated from the MFD driver and that is enough for them to come up. We already have an early quirk for the things that need to happen really early and the PRCMU timer that need to be registered really early will find its own node just fine as the timer/clocksource subsystem looks through the whole device tree for compatible nodes. Signed-off-by: Linus Walleij <linus.walleij@linaro.org> 
The PRCMU devices are getting populated from the MFD
driver and that is enough for them to come up. We already
have an early quirk for the things that need to happen
really early and the PRCMU timer that need to be registered
really early will find its own node just fine as the
timer/clocksource subsystem looks through the whole device
tree for compatible nodes.

Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500 2019-06-19T15:09:55+00:00 Thomas Gleixner tglx@linutronix.de 2019-06-04T08:11:33+00:00 d2912cb15bdda8ba4a5dd73396ad62641af2f520 Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
Based on 2 normalized pattern(s):

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation

  this program is free software you can redistribute it and or modify
  it under the terms of the gnu general public license version 2 as
  published by the free software foundation #

extracted by the scancode license scanner the SPDX license identifier

  GPL-2.0-only

has been chosen to replace the boilerplate/reference in 4122 file(s).

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Enrico Weigelt <info@metux.net>
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Allison Randal <allison@lohutok.net>
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>