memory: atmel-sdramc: remove the driver

Driver does only clock request + enable for DDR clocks. DDR clocks are
enabled by bootloader and need to stay that way in Linux. To avoid having
these clocks

memory: atmel-sdramc: remove the driver

Driver does only clock request + enable for DDR clocks. DDR clocks are
enabled by bootloader and need to stay that way in Linux. To avoid having
these clocks disabled by clock subsystem in case there are no Linux
consumers for them the clocks were marked as critical in clock drivers
(in commit 68b3b6f1773d ("clk: at91: mark ddr clocks as critical")).
With this, there is no need to have a separate driver that only does
clock request + enable.

Signed-off-by: Claudiu Beznea <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

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 ...

memory: brcmstb_memc: Add Broadcom STB memory controller driver

Add support for configuring the Self Refresh Power Down (SRPD)
inactivity timeout on Broadcom STB chips. This is used to conserve powe

memory: brcmstb_memc: Add Broadcom STB memory controller driver

Add support for configuring the Self Refresh Power Down (SRPD)
inactivity timeout on Broadcom STB chips. This is used to conserve power
when the DRAM activity is reduced.

Signed-off-by: Florian Fainelli <[email protected]>
Signed-off-by: Krzysztof Kozlowski <[email protected]>
Link: https://lore.kernel.org/r/[email protected]

show more ...

memory: dfl-emif: add the DFL EMIF private feature driver

This driver is for the EMIF private feature implemented under FPGA
Device Feature List (DFL) framework. It is used to expose memory
interfac

memory: dfl-emif: add the DFL EMIF private feature driver

This driver is for the EMIF private feature implemented under FPGA
Device Feature List (DFL) framework. It is used to expose memory
interface status information as well as memory clearing control.

The purpose of memory clearing block is to zero out all private memory
when FPGA is to be reprogrammed. This gives users a reliable method to
prevent potential data leakage.

[[email protected]: Fixed up ABI doc]

Reviewed-by: Tom Rix <[email protected]>
Acked-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Xu Yilun <[email protected]>
Signed-off-by: Russ Weight <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

memory: brcmstb_dpfe: add separate entry for compile test

Add separate entry for Broadcom STB DPFE driver, enabled by default on
ARCH_BRCMSTB. This allows compile testing.

Signed-off-by: Krzysztof

memory: brcmstb_dpfe: add separate entry for compile test

Add separate entry for Broadcom STB DPFE driver, enabled by default on
ARCH_BRCMSTB. This allows compile testing.

Signed-off-by: Krzysztof Kozlowski <[email protected]>
Acked-by: Florian Fainelli <[email protected]>

show more ...

memory: stm32-fmc2-ebi: add STM32 FMC2 EBI controller driver

The driver adds the support for the STMicroelectronics FMC2 EBI controller
found on STM32MP SOCs.

Signed-off-by: Christophe Kerello <chr

memory: stm32-fmc2-ebi: add STM32 FMC2 EBI controller driver

The driver adds the support for the STMicroelectronics FMC2 EBI controller
found on STM32MP SOCs.

Signed-off-by: Christophe Kerello <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Link: https://lore.kernel.org/linux-mtd/[email protected]

show more ...

memory: add Renesas RPC-IF driver

Add the memory driver for Renesas RPC-IF which registers either SPI or
HyperFLash device depending on the contents of the device tree subnode.
It also provides the

memory: add Renesas RPC-IF driver

Add the memory driver for Renesas RPC-IF which registers either SPI or
HyperFLash device depending on the contents of the device tree subnode.
It also provides the absract "back end" device APIs that can be used by
the "front end" SPI/MTD drivers to talk to the real hardware.

Based on the original patch by Mason Yang <[email protected]>.

Signed-off-by: Sergei Shtylyov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[email protected]>

show more ...

memory: Add Baikal-T1 L2-cache Control Block driver

Baikal-T1 SoC provides a way to tune the MIPS P5600 CM2 L2-cache
performance up. It can be done by changing the L2-RAM Data/Tag/WS
latencies in a

memory: Add Baikal-T1 L2-cache Control Block driver

Baikal-T1 SoC provides a way to tune the MIPS P5600 CM2 L2-cache
performance up. It can be done by changing the L2-RAM Data/Tag/WS
latencies in a dedicated register exposed by the system controller.
The driver added by this commit provides a dts properties-based and
sysfs-based interface for it. The device DT node is supposed to be a
child of Baikal-T1 System Controller node.

Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Serge Semin <[email protected]>
Cc: Alexey Malahov <[email protected]>
Cc: Paul Burton <[email protected]>
Cc: Olof Johansson <[email protected]>
Cc: Rob Herring <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Arnd Bergmann <[email protected]>

show more ...

memory: ti-emif-sram: move driver-specific asm-offset.h to drivers/memory/

<generated/ti-emif-asm-offsets.h> is only generated and included
by drivers/memory/, so it does not need to reside in the g

memory: ti-emif-sram: move driver-specific asm-offset.h to drivers/memory/

<generated/ti-emif-asm-offsets.h> is only generated and included
by drivers/memory/, so it does not need to reside in the globally
visible include/generated/.

Signed-off-by: Masahiro Yamada <[email protected]>
Acked-by: Santosh Shilimkar <[email protected]>

show more ...

memory: move jedec_ddr_data.c from lib/ to drivers/memory/

jedec_ddr_data.c exports 3 symbols, and all of them are only
referenced from drivers/memory/{emif.c,of_memory.c}

drivers/memory/ is a bett

memory: move jedec_ddr_data.c from lib/ to drivers/memory/

jedec_ddr_data.c exports 3 symbols, and all of them are only
referenced from drivers/memory/{emif.c,of_memory.c}

drivers/memory/ is a better location than lib/.

I removed the Kconfig prompt "JEDEC DDR data" because it is only
select'ed by TI_EMIF, and there is no other user. There is no good
reason in making it a user-configurable CONFIG option.

Signed-off-by: Masahiro Yamada <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>

show more ...

memory: squash drivers/memory/Makefile.asm-offsets

drivers/memory/Makefile.asm-offsets is small enough, and included
from a single place.

Squash it into drivers/memory/Makefile.

Signed-off-by: Mas

memory: squash drivers/memory/Makefile.asm-offsets

drivers/memory/Makefile.asm-offsets is small enough, and included
from a single place.

Squash it into drivers/memory/Makefile.

Signed-off-by: Masahiro Yamada <[email protected]>

show more ...

memory: pl353: Add driver for arm pl353 static memory controller

Add driver for arm pl353 static memory controller. This controller is used in
Xilinx Zynq SoC for interfacing the NAND and NOR/SRAM m

memory: pl353: Add driver for arm pl353 static memory controller

Add driver for arm pl353 static memory controller. This controller is used in
Xilinx Zynq SoC for interfacing the NAND and NOR/SRAM memory devices.

Signed-off-by: Naga Sureshkumar Relli <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Michal Simek <[email protected]>

show more ...

memory: tegra: Squash tegra20-mc into common tegra-mc driver

Tegra30+ has some minor differences in registers / bits layout compared
to Tegra20. Let's squash Tegra20 driver into the common tegra-mc

memory: tegra: Squash tegra20-mc into common tegra-mc driver

Tegra30+ has some minor differences in registers / bits layout compared
to Tegra20. Let's squash Tegra20 driver into the common tegra-mc driver
in a preparation for the upcoming MC hot reset controls implementation,
avoiding code duplication.

Note that this currently doesn't report the value of MC_GART_ERROR_REQ
because it is located within the GART register area and cannot be safely
accessed from the MC driver (this happens to work only by accident). The
proper solution is to integrate the GART driver with the MC driver, much
like is done for the Tegra SMMU, but that is an invasive change and will
be part of a separate patch series.

Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>

show more ...

memory: ti-emif-sram: introduce relocatable suspend/resume handlers

Certain SoCs like Texas Instruments AM335x and AM437x require parts
of the EMIF PM code to run late in the suspend sequence from S

memory: ti-emif-sram: introduce relocatable suspend/resume handlers

Certain SoCs like Texas Instruments AM335x and AM437x require parts
of the EMIF PM code to run late in the suspend sequence from SRAM,
such as saving and restoring the EMIF context and placing the memory
into self-refresh.

One requirement for these SoCs to suspend and enter its lowest power
mode, called DeepSleep0, is that the PER power domain must be shut off.
Because the EMIF (DDR Controller) resides within this power domain, it
will lose context during a suspend operation, so we must save it so we
can restore once we resume. However, we cannot execute this code from
external memory, as it is not available at this point, so the code must
be executed late in the suspend path from SRAM.

This patch introduces a ti-emif-sram driver that includes several
functions written in ARM ASM that are relocatable so the PM SRAM
code can use them. It also allocates a region of writable SRAM to
be used by the code running in the executable region of SRAM to save
and restore the EMIF context. It can export a table containing the
absolute addresses of the available PM functions so that other SRAM
code can branch to them. This code is required for suspend/resume on
AM335x and AM437x to work.

In addition to this, to be able to share data structures between C and
the ti-emif-sram-pm assembly code, we can automatically generate all of
the C struct member offsets and sizes as macros by processing
emif-asm-offsets.c into assembly code and then extracting the relevant
data as is done for the generated platform asm-offsets.h files.

Acked-by: Tony Lindgren <[email protected]>
Acked-by: Russell King <[email protected]>
Signed-off-by: Dave Gerlach <[email protected]>
Signed-off-by: Santosh Shilimkar <[email protected]>

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

show more ...

memory: brcmstb: Add driver for DPFE

This driver allows access to DRAM properties, such as the refresh rate,
via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be
used as indirect i

memory: brcmstb: Add driver for DPFE

This driver allows access to DRAM properties, such as the refresh rate,
via the Broadcom STB DDR PHY Front End (DPFE). The refresh rate can be
used as indirect indicator of the DRAM temperature.

The driver also allows setting of the sampling interval.

Signed-off-by: Markus Mayer <[email protected]>
Signed-off-by: Florian Fainelli <[email protected]>

show more ...

memory: davinci: add support for da8xx DDR2/mDDR controller

Create a new driver for the da8xx DDR2/mDDR controller and implement
support for writing to the Peripheral Bus Burst Priority Register.

R

memory: davinci: add support for da8xx DDR2/mDDR controller

Create a new driver for the da8xx DDR2/mDDR controller and implement
support for writing to the Peripheral Bus Burst Priority Register.

Reviewed-by: Kevin Hilman <[email protected]>
Acked-by: Rob Herring <[email protected]>
Signed-off-by: Bartosz Golaszewski <[email protected]>
[[email protected]: subject line adjustment]
Signed-off-by: Sekhar Nori <[email protected]>

show more ...

memory: add Atmel EBI (External Bus Interface) driver

The EBI (External Bus Interface) is used to access external peripherals
(NOR, SRAM, NAND, and other specific devices like ethernet controllers).

memory: add Atmel EBI (External Bus Interface) driver

The EBI (External Bus Interface) is used to access external peripherals
(NOR, SRAM, NAND, and other specific devices like ethernet controllers).
Each device is assigned a CS line and an address range and can have its
own configuration (timings, access mode, bus width, ...).
This driver provides a generic DT binding to configure a device according
to its requirements.
For specific device controllers (like the NAND one) the SMC timings
should be configured by the controller driver through the matrix and
smc syscon regmaps.

Signed-off-by: Boris Brezillon <[email protected]>
Signed-off-by: Alexandre Belloni <[email protected]>

show more ...

memory: Add support for Exynos SROM driver

This patch adds Exynos SROM controller driver which will handle
save restore of SROM registers during S2R.

Signed-off-by: Pankaj Dubey <pankaj.dubey@samsu

memory: Add support for Exynos SROM driver

This patch adds Exynos SROM controller driver which will handle
save restore of SROM registers during S2R.

Signed-off-by: Pankaj Dubey <[email protected]>
Reviewed-by: Krzysztof Kozlowski <[email protected]>
[[email protected]: tested on SMDK5410]
Tested-by: Pavel Fedin <[email protected]>
Signed-off-by: Kukjin Kim <[email protected]>
[k.kozlowski: Minor COMPILE_TEST adjustments in Kconfig entries]
Signed-off-by: Krzysztof Kozlowski <[email protected]>

show more ...

memory: mediatek: Add SMI driver

This patch add SMI(Smart Multimedia Interface) driver. This driver
is responsible to enable/disable iommu and control the power domain
and clocks of each local arbit

memory: mediatek: Add SMI driver

This patch add SMI(Smart Multimedia Interface) driver. This driver
is responsible to enable/disable iommu and control the power domain
and clocks of each local arbiter.

Signed-off-by: Yong Wu <[email protected]>
Tested-by: Philipp Zabel <[email protected]>
Reviewed-by: Daniel Kurtz <[email protected]>
Tested-by: Daniel Kurtz <[email protected]>
Signed-off-by: Matthias Brugger <[email protected]>
Signed-off-by: Joerg Roedel <[email protected]>

show more ...

memory: add ARM PL172 MultiPort Memory Controller driver

This driver makes it possible to configure the static memory
chip selects on the ARM PL172 MultiPort Memory Controller
from a set of properti

memory: add ARM PL172 MultiPort Memory Controller driver

This driver makes it possible to configure the static memory
chip selects on the ARM PL172 MultiPort Memory Controller
from a set of properties in DT. Configuration of dynamic
memory is not supported and is left to the boot loader.

The intended usage is to setup timing and configuration for
static memory devices like NAND and NOR Flash before they
are probed by a driver.

Signed-off-by: Joachim Eastwood <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>

show more ...

memory: jz4780-nemc: driver for the NEMC on JZ4780 SoCs

Add a driver for the NAND/External Memory Controller (NEMC) on JZ4780
and later SoCs.

The primary function of this driver is to configure par

memory: jz4780-nemc: driver for the NEMC on JZ4780 SoCs

Add a driver for the NAND/External Memory Controller (NEMC) on JZ4780
and later SoCs.

The primary function of this driver is to configure parameters, such
as timings, for external memory devices using data supplied in the
device tree. Devices connected to the NEMC are represented in the DT
as children of the NEMC node, the driver uses optional properties
specified in these child nodes to configure the parameters of each
bank.

Signed-off-by: Alex Smith <[email protected]>
Signed-off-by: Zubair Lutfullah Kakakhel <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

memory: Add NVIDIA Tegra memory controller support

The memory controller on NVIDIA Tegra exposes various knobs that can be
used to tune the behaviour of the clients attached to it.

Currently this d

memory: Add NVIDIA Tegra memory controller support

The memory controller on NVIDIA Tegra exposes various knobs that can be
used to tune the behaviour of the clients attached to it.

Currently this driver sets up the latency allowance registers to the HW
defaults. Eventually an API should be exported by this driver (via a
custom API or a generic subsystem) to allow clients to register latency
requirements.

This driver also registers an IOMMU (SMMU) that's implemented by the
memory controller. It is supported on Tegra30, Tegra114 and Tegra124
currently. Tegra20 has a GART instead.

The Tegra SMMU operates on memory clients and SWGROUPs. A memory client
is a unidirectional, special-purpose DMA master. A SWGROUP represents a
set of memory clients that form a logical functional unit corresponding
to a single device. Typically a device has two clients: one client for
read transactions and one client for write transactions, but there are
also devices that have only read clients, but many of them (such as the
display controllers).

Because there is no 1:1 relationship between memory clients and devices
the driver keeps a table of memory clients and the SWGROUPs that they
belong to per SoC. Note that this is an exception and due to the fact
that the SMMU is tightly integrated with the rest of the Tegra SoC. The
use of these tables is discouraged in drivers for generic IOMMU devices
such as the ARM SMMU because the same IOMMU could be used in any number
of SoCs and keeping such tables for each SoC would not scale.

Acked-by: Joerg Roedel <[email protected]>
Signed-off-by: Thierry Reding <[email protected]>

show more ...

memory: gpmc: Move omap gpmc code to live under drivers

Just move to drivers as further clean-up can now happen there
finally.

Let's also add Roger and me to the MAINTAINERS so we get
notified for

memory: gpmc: Move omap gpmc code to live under drivers

Just move to drivers as further clean-up can now happen there
finally.

Let's also add Roger and me to the MAINTAINERS so we get
notified for any patches related to GPMC.

Cc: Arnd Bergmann <[email protected]>
Acked-by: Roger Quadros <[email protected]>
Signed-off-by: Tony Lindgren <[email protected]>

show more ...

memory: Freescale CoreNet Coherency Fabric error reporting driver

The CoreNet Coherency Fabric is part of the memory subsystem on
some Freescale QorIQ chips. It can report coherency violations (e.g

memory: Freescale CoreNet Coherency Fabric error reporting driver

The CoreNet Coherency Fabric is part of the memory subsystem on
some Freescale QorIQ chips. It can report coherency violations (e.g.
due to misusing memory that is mapped noncoherent) as well as
transactions that do not hit any local access window, or which hit a
local access window with an invalid target ID.

Signed-off-by: Scott Wood <[email protected]>
Reviewed-by: Bharat Bhushan <[email protected]>

show more ...