History log of /linux-6.15/arch/arm/common/Makefile (Results 1 – 25 of 41)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6, v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6, v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5, v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6, v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6, v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8, v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3
# a2faac39 24-Oct-2022 Nick Desaulniers <[email protected]>

ARM: 9263/1: use .arch directives instead of assembler command line flags

Similar to commit a6c30873ee4a ("ARM: 8989/1: use .fpu assembler
directives instead of assembler arguments").

GCC and GNU b

ARM: 9263/1: use .arch directives instead of assembler command line flags

Similar to commit a6c30873ee4a ("ARM: 8989/1: use .fpu assembler
directives instead of assembler arguments").

GCC and GNU binutils support setting the "sub arch" via -march=,
-Wa,-march, target function attribute, and .arch assembler directive.

Clang was missing support for -Wa,-march=, but this was implemented in
clang-13.

The behavior of both GCC and Clang is to
prefer -Wa,-march= over -march= for assembler and assembler-with-cpp
sources, but Clang will warn about the -march= being unused.

clang: warning: argument unused during compilation: '-march=armv6k'
[-Wunused-command-line-argument]

Since most assembler is non-conditionally assembled with one sub arch
(modulo arch/arm/delay-loop.S which conditionally is assembled as armv4
based on CONFIG_ARCH_RPC, and arch/arm/mach-at91/pm-suspend.S which is
conditionally assembled as armv7-a based on CONFIG_CPU_V7), prefer the
.arch assembler directive.

Add a few more instances found in compile testing as found by Arnd and
Nathan.

Link: https://github.com/llvm/llvm-project/commit/1d51c699b9e2ebc5bcfdbe85c74cc871426333d4
Link: https://bugs.llvm.org/show_bug.cgi?id=48894
Link: https://github.com/ClangBuiltLinux/linux/issues/1195
Link: https://github.com/ClangBuiltLinux/linux/issues/1315

Suggested-by: Arnd Bergmann <[email protected]>
Suggested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Tested-by: Nathan Chancellor <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Signed-off-by: Russell King (Oracle) <[email protected]>

show more ...


Revision tags: v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6, v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6, v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5, v5.18-rc4
# e3217540 19-Apr-2022 Christoph Hellwig <[email protected]>

ARM/dma-mapping: remove dmabounce

Remove the now unused dmabounce code.

Signed-off-by: Christoph Hellwig <[email protected]>
Reviewed-by: Arnd Bergmann <[email protected]>


Revision tags: v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6, v5.17-rc5, v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6, v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6, v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6, v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6
# 6da5238f 14-Jul-2020 Mike Rapoport <[email protected]>

ARM: 8993/1: remove it8152 PCI controller driver

The it8152 PCI host controller was only used by cm-x2xx platforms.
Since these platforms were removed, there is no point to keep it8152
driver.

Acke

ARM: 8993/1: remove it8152 PCI controller driver

The it8152 PCI host controller was only used by cm-x2xx platforms.
Since these platforms were removed, there is no point to keep it8152
driver.

Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Mike Rapoport <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...


Revision tags: v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6, v5.6-rc7, v5.6-rc6, v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7, v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6, v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2, v5.2-rc7, v5.2-rc6, v5.2-rc5, v5.2-rc4, v5.2-rc3, v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6, v5.1-rc5, v5.1-rc4, v5.1-rc3, v5.1-rc2, v5.1-rc1, v5.0, v5.0-rc8, v5.0-rc7, v5.0-rc6, v5.0-rc5, v5.0-rc4, v5.0-rc3, v5.0-rc2, v5.0-rc1, v4.20, v4.20-rc7, v4.20-rc6, v4.20-rc5, v4.20-rc4, v4.20-rc3, v4.20-rc2, v4.20-rc1, v4.19, v4.19-rc8, v4.19-rc7, v4.19-rc6, v4.19-rc5, v4.19-rc4, v4.19-rc3, v4.19-rc2, v4.19-rc1
# 36d68f64 14-Aug-2018 Stephen Boyd <[email protected]>

ARM: Add Krait L2 register accessor functions

Krait CPUs have a handful of L2 cache controller registers that
live behind a cp15 based indirection register. First you program
the indirection registe

ARM: Add Krait L2 register accessor functions

Krait CPUs have a handful of L2 cache controller registers that
live behind a cp15 based indirection register. First you program
the indirection register (l2cpselr) to point the L2 'window'
register (l2cpdr) at what you want to read/write. Then you
read/write the 'window' register to do what you want. The
l2cpselr register is not banked per-cpu so we must lock around
accesses to it to prevent other CPUs from re-pointing l2cpdr
underneath us.

Cc: Mark Rutland <[email protected]>
Cc: Russell King <[email protected]>
Acked-by: Bjorn Andersson <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>
Signed-off-by: Sricharan R <[email protected]>
Tested-by: Craig Tatlor <[email protected]>
Signed-off-by: Stephen Boyd <[email protected]>

show more ...


Revision tags: v4.18, v4.18-rc8, v4.18-rc7, v4.18-rc6, v4.18-rc5, v4.18-rc4, v4.18-rc3, v4.18-rc2, v4.18-rc1
# 0fff9001 06-Jun-2018 Geert Uytterhoeven <[email protected]>

ARM: Always build secure_cntvoff.S on ARM V7 to fix shmobile !SMP build

If CONFIG_SMP=n, building a kernel for R-Car Gen2 fails with:

arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar

ARM: Always build secure_cntvoff.S on ARM V7 to fix shmobile !SMP build

If CONFIG_SMP=n, building a kernel for R-Car Gen2 fails with:

arch/arm/mach-shmobile/setup-rcar-gen2.o: In function `rcar_gen2_timer_init':
setup-rcar-gen2.c:(.init.text+0x30): undefined reference to `secure_cntvoff_init'

Indeed, on R-Car Gen2 SoCs, secure_cntvoff_init() is not only needed for
secondary CPUs, but also for the boot CPU. This is most visible on SoCs
with Cortex A7 cores (e.g. R-Car E2, cfr. commit 9ce3fa6816c2fb59 ("ARM:
shmobile: rcar-gen2: Add CA7 arch_timer initialization for r8a7794")),
but Cortex A15 is affected, too.

Fix this by always providing secure_cntvoff_init() when building for ARM
V7.

Reported-by: Arnd Bergmann <[email protected]>
Fixes: 7c607944bc657616 ("ARM: smp: Add initialization of CNTVOFF")
Fixes: cad160ed0a94927e ("ARM: shmobile: Convert file to use cntvoff")
Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Maxime Ripard <[email protected]>
Reviewed-by: Simon Horman <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>

show more ...


Revision tags: v4.17, v4.17-rc7, v4.17-rc6, v4.17-rc5, v4.17-rc4
# 7c607944 04-May-2018 Mylène Josserand <[email protected]>

ARM: smp: Add initialization of CNTVOFF

The CNTVOFF register from arch timer is uninitialized.
It should be done by the bootloader but it is currently not the case,
even for boot CPU because this So

ARM: smp: Add initialization of CNTVOFF

The CNTVOFF register from arch timer is uninitialized.
It should be done by the bootloader but it is currently not the case,
even for boot CPU because this SoC is booting in secure mode.
It leads to an random offset value meaning that each CPU will have a
different time, which isn't working very well.

Add assembly code used for boot CPU and secondary CPU cores to make
sure that the CNTVOFF register is initialized. Because this code can
be used by different platforms, add this assembly file in ARM's common
folder.

Signed-off-by: Mylène Josserand <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Tested-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Marc Zyngier <[email protected]>
Signed-off-by: Maxime Ripard <[email protected]>

show more ...


Revision tags: v4.17-rc3, v4.17-rc2, v4.17-rc1, v4.16, v4.16-rc7, v4.16-rc6, v4.16-rc5, v4.16-rc4, v4.16-rc3, v4.16-rc2, v4.16-rc1, v4.15, v4.15-rc9, v4.15-rc8, v4.15-rc7, v4.15-rc6, v4.15-rc5, v4.15-rc4, v4.15-rc3, v4.15-rc2, v4.15-rc1, v4.14, v4.14-rc8
# b2441318 01-Nov-2017 Greg Kroah-Hartman <[email protected]>

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 <[email protected]>
Reviewed-by: Philippe Ombredanne <[email protected]>
Reviewed-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...


Revision tags: v4.14-rc7, v4.14-rc6, v4.14-rc5, v4.14-rc4, v4.14-rc3, v4.14-rc2, v4.14-rc1, v4.13, v4.13-rc7, v4.13-rc6, v4.13-rc5, v4.13-rc4, v4.13-rc3, v4.13-rc2, v4.13-rc1, v4.12, v4.12-rc7, v4.12-rc6, v4.12-rc5, v4.12-rc4, v4.12-rc3, v4.12-rc2, v4.12-rc1, v4.11, v4.11-rc8, v4.11-rc7, v4.11-rc6, v4.11-rc5, v4.11-rc4, v4.11-rc3, v4.11-rc2, v4.11-rc1, v4.10, v4.10-rc8, v4.10-rc7
# ba3fae06 01-Feb-2017 Linus Walleij <[email protected]>

ARM/clk: move the ICST library to drivers/clk

This moves the ICST clock divider helper library from
arch/arm/common to drivers/clk/versatile so it is maintained
with the other clock drivers.

We kee

ARM/clk: move the ICST library to drivers/clk

This moves the ICST clock divider helper library from
arch/arm/common to drivers/clk/versatile so it is maintained
with the other clock drivers.

We keep the structure as a helper library intact and do not
fuse it with the clk-icst.c Versatile ICST clock driver: there
may be other users out there that need to use this library for
their clocking, and then it will be helpful to keep the
library contained. (The icst.[c|h] files could just be moved
to drivers/clk/lib or a similar location to share the library.)

Acked-by: Stephen Boyd <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...


Revision tags: v4.10-rc6, v4.10-rc5, v4.10-rc4, v4.10-rc3, v4.10-rc2, v4.10-rc1, v4.9, v4.9-rc8, v4.9-rc7, v4.9-rc6, v4.9-rc5, v4.9-rc4, v4.9-rc3, v4.9-rc2, v4.9-rc1, v4.8, v4.8-rc8, v4.8-rc7, v4.8-rc6, v4.8-rc5, v4.8-rc4, v4.8-rc3, v4.8-rc2, v4.8-rc1, v4.7, v4.7-rc7, v4.7-rc6, v4.7-rc5, v4.7-rc4, v4.7-rc3, v4.7-rc2, v4.7-rc1, v4.6, v4.6-rc7, v4.6-rc6, v4.6-rc5, v4.6-rc4, v4.6-rc3, v4.6-rc2, v4.6-rc1, v4.5, v4.5-rc7, v4.5-rc6, v4.5-rc5, v4.5-rc4, v4.5-rc3, v4.5-rc2, v4.5-rc1, v4.4, v4.4-rc8, v4.4-rc7, v4.4-rc6, v4.4-rc5, v4.4-rc4, v4.4-rc3, v4.4-rc2, v4.4-rc1, v4.3, v4.3-rc7, v4.3-rc6
# 2b6b3b74 14-Oct-2015 Peter Ujfalusi <[email protected]>

ARM/dmaengine: edma: Merge the two drivers under drivers/dma/

Move the code out from arch/arm/common and merge it inside of the dmaengine
driver.
This change is done with as minimal (if eny) functio

ARM/dmaengine: edma: Merge the two drivers under drivers/dma/

Move the code out from arch/arm/common and merge it inside of the dmaengine
driver.
This change is done with as minimal (if eny) functional change to the code
as possible to avoid introducing regression.

Signed-off-by: Peter Ujfalusi <[email protected]>
Acked-by: Tony Lindgren <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>

show more ...


Revision tags: v4.3-rc5, v4.3-rc4, v4.3-rc3, v4.3-rc2, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4
# 0b7402dc 18-May-2015 Sudeep Holla <[email protected]>

ARM: 8366/1: move Dual-Timer SP804 driver to drivers/clocksource

The ARM Dual-Timer SP804 module is peripheral found not only on ARM32
platforms but also on ARM64 platforms.

This patch moves the dr

ARM: 8366/1: move Dual-Timer SP804 driver to drivers/clocksource

The ARM Dual-Timer SP804 module is peripheral found not only on ARM32
platforms but also on ARM64 platforms.

This patch moves the driver out of arch/arm to driver/clocksource
so that it can be used on ARM64 platforms also.

Cc: Daniel Lezcano <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: Arnd Bergmann <[email protected]>
Cc: Catalin Marinas <[email protected]>
Cc: Olof Johansson <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Sudeep Holla <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...


Revision tags: v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6, v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2, v3.15-rc1, v3.14, v3.14-rc8, v3.14-rc7, v3.14-rc6, v3.14-rc5, v3.14-rc4, v3.14-rc3
# ea36d2ab 14-Feb-2014 Dave Martin <[email protected]>

ARM: 7962/2: Make all mcpm functions notrace

The functions in mcpm_entry.c are mostly intended for use during
scary cache and coherency disabling sequences, or do other things
which confuse trace ..

ARM: 7962/2: Make all mcpm functions notrace

The functions in mcpm_entry.c are mostly intended for use during
scary cache and coherency disabling sequences, or do other things
which confuse trace ... like powering a CPU down and not
returning. Similarly for the backend code.

For simplicity, this patch just makes whole files notrace.
There should be more than enough traceable points on the paths to
these functions, but we can be more fine-grained later if there is
a need for it.

Jon Medhurst:
Also added spc.o to the list of files as it contains functions used by
MCPM code which have comments comments like: "might be used in code
paths where normal cacheable locks are not working"

Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Jon Medhurst <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...


Revision tags: v3.14-rc2, v3.14-rc1, v3.13, v3.13-rc8, v3.13-rc7, v3.13-rc6, v3.13-rc5, v3.13-rc4, v3.13-rc3, v3.13-rc2, v3.13-rc1, v3.12, v3.12-rc7, v3.12-rc6, v3.12-rc5, v3.12-rc4, v3.12-rc3, v3.12-rc2, v3.12-rc1
# 136dfa5e 03-Sep-2013 Linus Walleij <[email protected]>

ARM: delete mach-shark

The Shark machine sub-architecture (also known as DNARD, the
DIGITAL Network Appliance Reference Design) lacks a maintainer
able to apply and test patches to modernize the arc

ARM: delete mach-shark

The Shark machine sub-architecture (also known as DNARD, the
DIGITAL Network Appliance Reference Design) lacks a maintainer
able to apply and test patches to modernize the architecture.

It is suspected that the current kernel, while it compiles,
does not even boot on this machine. The listed maintainer has
expressed that he will not be able to spend any time on the
maintenance for the coming year.

So let's delete it from the kernel for now. It can always be
resurrected with git revert if maintenance is resumed.

As the VIA82c505 PCI adapter was only used by this
architecture, that gets deleted too.

Cc: [email protected]
Cc: Alexander Schulz <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>

show more ...


Revision tags: v3.11, v3.11-rc7, v3.11-rc6, v3.11-rc5, v3.11-rc4, v3.11-rc3, v3.11-rc2, v3.11-rc1, v3.10, v3.10-rc7, v3.10-rc6, v3.10-rc5, v3.10-rc4, v3.10-rc3, v3.10-rc2, v3.10-rc1, v3.9, v3.9-rc8, v3.9-rc7, v3.9-rc6, v3.9-rc5, v3.9-rc4, v3.9-rc3, v3.9-rc2, v3.9-rc1, v3.8, v3.8-rc7, v3.8-rc6, v3.8-rc5, v3.8-rc4, v3.8-rc3, v3.8-rc2, v3.8-rc1, v3.7, v3.7-rc8, v3.7-rc7, v3.7-rc6, v3.7-rc5, v3.7-rc4, v3.7-rc3, v3.7-rc2, v3.7-rc1, v3.6, v3.6-rc7, v3.6-rc6, v3.6-rc5, v3.6-rc4, v3.6-rc3, v3.6-rc2, v3.6-rc1, v3.5, v3.5-rc7, v3.5-rc6, v3.5-rc5, v3.5-rc4, v3.5-rc3, v3.5-rc2, v3.5-rc1, v3.4, v3.4-rc7, v3.4-rc6, v3.4-rc5, v3.4-rc4, v3.4-rc3
# b22537c6 12-Apr-2012 Nicolas Pitre <[email protected]>

ARM: bL_switcher: add a simple /dev user interface for debugging purposes

Only the basic call to aid debugging.

*** NOT FOR PRODUCTION ***

Usage:

echo <cpuid>,<clusterid> > /dev/b.L_switcher

wh

ARM: bL_switcher: add a simple /dev user interface for debugging purposes

Only the basic call to aid debugging.

*** NOT FOR PRODUCTION ***

Usage:

echo <cpuid>,<clusterid> > /dev/b.L_switcher

where <cpuid> is the logical CPU number, and <clusterid> is 0 for the
first cluster and 1 for the second cluster.

Signed-off-by: nicolas Pitre <[email protected]>

show more ...


# 1c33be57 12-Apr-2012 Nicolas Pitre <[email protected]>

ARM: b.L: core switcher code

This is the core code implementing big.LITTLE switcher functionality.
Rationale for this code is available here:

http://lwn.net/Articles/481055/

The main entry point f

ARM: b.L: core switcher code

This is the core code implementing big.LITTLE switcher functionality.
Rationale for this code is available here:

http://lwn.net/Articles/481055/

The main entry point for a switch request is:

void bL_switch_request(unsigned int cpu, unsigned int new_cluster_id)

If the calling CPU is not the wanted one, this wrapper takes care of
sending the request to the appropriate CPU with schedule_work_on().

At the moment the core switch operation is handled by bL_switch_to()
which must be called on the CPU for which a switch is requested.

What this code does:

* Return early if the current cluster is the wanted one.

* Close the gate in the kernel entry vector for both the inbound
and outbound CPUs.

* Wake up the inbound CPU so it can perform its reset sequence in
parallel up to the kernel entry vector gate.

* Migrate all interrupts in the GIC targeting the outbound CPU
interface to the inbound CPU interface, including SGIs. This is
performed by gic_migrate_target() in drivers/irqchip/irq-gic.c.

* Call cpu_pm_enter() which takes care of flushing the VFP state to
RAM and save the CPU interface config from the GIC to RAM.

* Modify the cpu_logical_map to refer to the inbound physical CPU.

* Call cpu_suspend() which saves the CPU state (general purpose
registers, page table address) onto the stack and store the
resulting stack pointer in an array indexed by the updated
cpu_logical_map, then call the provided shutdown function.
This happens in arch/arm/kernel/sleep.S.

At this point, the provided shutdown function executed by the outbound
CPU ungates the inbound CPU. Therefore the inbound CPU:

* Picks up the saved stack pointer in the array indexed by its MPIDR
in arch/arm/kernel/sleep.S.

* The MMU and caches are re-enabled using the saved state on the
provided stack, just like if this was a resume operation from a
suspended state.

* Then cpu_suspend() returns, although this is on the inbound CPU
rather than the outbound CPU which called it initially.

* The function cpu_pm_exit() is called which effect is to restore the
CPU interface state in the GIC using the state previously saved by
the outbound CPU.

* Exit of bL_switch_to() to resume normal kernel execution on the
new CPU.

However, the outbound CPU is potentially still running in parallel while
the inbound CPU is resuming normal kernel execution, hence we need
per CPU stack isolation to execute bL_do_switch(). After the outbound
CPU has ungated the inbound CPU, it calls mcpm_cpu_power_down() to:

* Clean its L1 cache.

* If it is the last CPU still alive in its cluster (last man standing),
it also cleans its L2 cache and disables cache snooping from the other
cluster.

* Power down the CPU (or whole cluster).

Code called from bL_do_switch() might end up referencing 'current' for
some reasons. However, 'current' is derived from the stack pointer.
With any arbitrary stack, the returned value for 'current' and any
dereferenced values through it are just random garbage which may lead to
segmentation faults.

The active page table during the execution of bL_do_switch() is also a
problem. There is no guarantee that the inbound CPU won't destroy the
corresponding task which would free the attached page table while the
outbound CPU is still running and relying on it.

To solve both issues, we borrow some of the task space belonging to
the init/idle task which, by its nature, is lightly used and therefore
is unlikely to clash with our usage. The init task is also never going
away.

Right now the logical CPU number is assumed to be equivalent to the
physical CPU number within each cluster. The kernel should also be
booted with only one cluster active. These limitations will be lifted
eventually.

Signed-off-by: Nicolas Pitre <[email protected]>

show more ...


# 3ad7a42d 06-Mar-2013 Matt Porter <[email protected]>

ARM: davinci: move private EDMA API to arm/common

Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.

Signed-off-by: Matt Porter <[email protected]>
Acked

ARM: davinci: move private EDMA API to arm/common

Move mach-davinci/dma.c to common/edma.c so it can be used
by OMAP (specifically AM33xx) as well.

Signed-off-by: Matt Porter <[email protected]>
Acked-by: Chris Ball <[email protected]> # davinci_mmc.c
Acked-by: Mark Brown <[email protected]>
Acked-by: Olof Johansson <[email protected]>
[[email protected]: dropped davinci sffsdr changes]
Signed-off-by: Sekhar Nori <[email protected]>

show more ...


# 70100a02 02-May-2013 Dave Martin <[email protected]>

ARM: 7709/1: mcpm: Add explicit AFLAGS to support v6/v7 multiplatform kernels

The full mcpm layer is not likely to be relevant to v6 based
platforms, so a multiplatform kernel won't use that code if

ARM: 7709/1: mcpm: Add explicit AFLAGS to support v6/v7 multiplatform kernels

The full mcpm layer is not likely to be relevant to v6 based
platforms, so a multiplatform kernel won't use that code if booted
on v6 hardware.

This patch modifies the AFLAGS for affected mcpm .S files to
specify armv7-a explicitly for that code.

Signed-off-by: Dave Martin <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Acked-by: Nicolas Pitre <[email protected]>
Signed-off-by: Russell King <[email protected]>

show more ...


# 9ff221ba 19-Nov-2012 Nicolas Pitre <[email protected]>

ARM: mcpm: generic SMP secondary bringup and hotplug support

Now that the cluster power API is in place, we can use it for SMP secondary
bringup and CPU hotplug in a generic fashion.

Signed-off-by:

ARM: mcpm: generic SMP secondary bringup and hotplug support

Now that the cluster power API is in place, we can use it for SMP secondary
bringup and CPU hotplug in a generic fashion.

Signed-off-by: Nicolas Pitre <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Reviewed-by: Will Deacon <[email protected]>

show more ...


# 1ae98561 17-Aug-2012 Dave Martin <[email protected]>

ARM: mcpm_head.S: vlock-based first man election

Instead of requiring the first man to be elected in advance (which
can be suboptimal in some situations), this patch uses a per-
cluster mutex to co-

ARM: mcpm_head.S: vlock-based first man election

Instead of requiring the first man to be elected in advance (which
can be suboptimal in some situations), this patch uses a per-
cluster mutex to co-ordinate selection of the first man.

This should also make it more feasible to reuse this code path for
asynchronous cluster resume (as in CPUidle scenarios).

We must ensure that the vlock data doesn't share a cacheline with
anything else, or dirty cache eviction could corrupt it.

Signed-off-by: Dave Martin <[email protected]>
Signed-off-by: Nicolas Pitre <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Reviewed-by: Will Deacon <[email protected]>

show more ...


# e8db288e 12-Apr-2012 Nicolas Pitre <[email protected]>

ARM: multi-cluster PM: secondary kernel entry code

CPUs in cluster based systems, such as big.LITTLE, have special needs
when entering the kernel due to a hotplug event, or when resuming from
a deep

ARM: multi-cluster PM: secondary kernel entry code

CPUs in cluster based systems, such as big.LITTLE, have special needs
when entering the kernel due to a hotplug event, or when resuming from
a deep sleep mode.

This is vectorized so multiple CPUs can enter the kernel in parallel
without serialization.

The mcpm prefix stands for "multi cluster power management", however
this is usable on single cluster systems as well. Only the basic
structure is introduced here. This will be extended with later patches.

In order not to complexify things more than they currently have to,
the planned work to make runtime adjusted MPIDR based indexing and
dynamic memory allocation for cluster states is postponed to a later
cycle. The MAX_NR_CLUSTERS and MAX_CPUS_PER_CLUSTER static definitions
should be sufficient for those systems expected to be available in the
near future.

Signed-off-by: Nicolas Pitre <[email protected]>
Reviewed-by: Santosh Shilimkar <[email protected]>
Reviewed-by: Will Deacon <[email protected]>

show more ...


# 7366b92a 11-Dec-2012 Tomasz Figa <[email protected]>

ARM: Add interface for registering and calling firmware-specific operations

Some boards are running with secure firmware running in TrustZone secure
world, which changes the way some things have to

ARM: Add interface for registering and calling firmware-specific operations

Some boards are running with secure firmware running in TrustZone secure
world, which changes the way some things have to be initialized.

This patch adds an interface for platforms to specify available firmware
operations and call them.

A wrapper macro, call_firmware_op(), checks if the operation is provided
and calls it if so, otherwise returns -ENOSYS to allow fallback to
legacy operation..

By default no operations are provided.

Example of use:

In code using firmware ops:

__raw_writel(virt_to_phys(exynos4_secondary_startup),
CPU1_BOOT_REG);

/* Call Exynos specific smc call */
if (call_firmware_op(cpu_boot, cpu) == -ENOSYS)
cpu_boot_legacy(...); /* Try legacy way */

gic_raise_softirq(cpumask_of(cpu), 1);

In board-/platform-specific code:

static int platformX_do_idle(void)
{
/* tell platformX firmware to enter idle */
return 0;
}

static int platformX_cpu_boot(int i)
{
/* tell platformX firmware to boot CPU i */
return 0;
}

static const struct firmware_ops platformX_firmware_ops = {
.do_idle = exynos_do_idle,
.cpu_boot = exynos_cpu_boot,
/* other operations not available on platformX */
};

static void __init board_init_early(void)
{
register_firmware_ops(&platformX_firmware_ops);
}

Signed-off-by: Kyungmin Park <[email protected]>
Signed-off-by: Tomasz Figa <[email protected]>
Signed-off-by: Kukjin Kim <[email protected]>

show more ...


# 44430ec0 27-Oct-2012 Rob Herring <[email protected]>

irqchip: Move ARM VIC to drivers/irqchip

Now that we have drivers/irqchip, move VIC irqchip to drivers/irqchip.

Signed-off-by: Rob Herring <[email protected]>
Cc: Russell King <[email protected]

irqchip: Move ARM VIC to drivers/irqchip

Now that we have drivers/irqchip, move VIC irqchip to drivers/irqchip.

Signed-off-by: Rob Herring <[email protected]>
Cc: Russell King <[email protected]>
Cc: Thomas Gleixner <[email protected]>

show more ...


# 81243e44 21-Nov-2012 Rob Herring <[email protected]>

irqchip: Move ARM GIC to drivers/irqchip

Now that we have drivers/irqchip, move GIC irqchip to drivers/irqchip. This
is necessary to share the GIC with arm and arm64.

Signed-off-by: Rob Herring <ro

irqchip: Move ARM GIC to drivers/irqchip

Now that we have drivers/irqchip, move GIC irqchip to drivers/irqchip. This
is necessary to share the GIC with arm and arm64.

Signed-off-by: Rob Herring <[email protected]>
Cc: Russell King <[email protected]>
Cc: Thomas Gleixner <[email protected]>

show more ...


Revision tags: v3.4-rc2, v3.4-rc1
# c65f2abf 31-Mar-2012 Rob Herring <[email protected]>

ARM: remove ixp23xx and ixp2000 platforms

ixp2xxx platforms have had no real changes since ~2006 and the maintainer
has said on irc that they can be removed:

13:05 < nico> do you still care about i

ARM: remove ixp23xx and ixp2000 platforms

ixp2xxx platforms have had no real changes since ~2006 and the maintainer
has said on irc that they can be removed:

13:05 < nico> do you still care about ixp2000?
13:22 < lennert> not really, no
13:58 < nico> do you think we could remove it from the kernel tree?
14:01 < lennert> go for it, and remove ixp23xx too while you're at it

Removing will help simplify ARM consolidation in general and PCI re-work
specifically.

Signed-off-by: Rob Herring <[email protected]>
Cc: Randy Dunlap <[email protected]>
Acked-by: Lennert Buytenhek <[email protected]>

show more ...


Revision tags: v3.3, v3.3-rc7, v3.3-rc6
# a1be5d64 01-Mar-2012 Russell King <[email protected]>

ARM: riscpc: move time-acorn.c to mach-rpc

Nothing but RiscPC makes use of the Acorn timekeeping code, so move
it into mach-rpc.

Signed-off-by: Russell King <[email protected]>


Revision tags: v3.3-rc5, v3.3-rc4, v3.3-rc3, v3.3-rc2, v3.3-rc1, v3.2
# b7d861d9 26-Dec-2011 Boojin Kim <[email protected]>

DMA: PL330: Merge PL330 driver into drivers/dma/

Currently there were two part of DMAC PL330 driver for
support old styled s3c-pl330 which has been merged into
drivers/dma/pl330.c driver. Actually,

DMA: PL330: Merge PL330 driver into drivers/dma/

Currently there were two part of DMAC PL330 driver for
support old styled s3c-pl330 which has been merged into
drivers/dma/pl330.c driver. Actually, there is no reason
to separate them now.

Basically this patch merges arch/arm/common/pl330.c into
drivers/dma/pl330.c driver and removes useless exported
symbol, externed function and so on.

The newer pl330 driver tested on SMDKV310 and SMDK4212 boards

Cc: Jassi Brar <[email protected]>
Cc: Russell King <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Vinod Koul <[email protected]>
Signed-off-by: Boojin Kim <[email protected]>
Signed-off-by: Kukjin Kim <[email protected]>
Acked-by: Jassi Brar <[email protected]>
Signed-off-by: Vinod Koul <[email protected]>

show more ...


12