| Age | Commit message (Collapse) | Author |
|---|
|
The RK3399 Ficus board is an Enterprise Edition board
manufactured by Vamrs Ltd., based on the Rockchip RK3399 SoC.
The board exposes a bunch of nice peripherals, including
SATA, HDMI, MIPI CSI, Ethernet, WiFi, and PCIe.
Signed-off-by: Ezequiel Garcia <ezequiel@collabora.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
|
|
The Libretech ALL-H3-CC has a high density connector for attaching
an eMMC module. The module form factor and connection is specific
to Libretech, and has provisions for split vmmc/vqmmc (core and I/O)
voltage supplies, but this board does not wire the vqmmc side. The
H2+/H3/H5 SoCs do not support alternate I/O voltages for eMMC either.
Only 3.3V is supported. A specific module that ties vqmmc to vmmc,
with both at 3.3V, must be used.
Given that a) eMMC is not designed to be hotplugged, b) power is
always provided on the pins, and c) MMC controllers can deal with
missing cards, we can enable this by default. If a module is attached
it will be picked up by the system.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Banana Pi M2 Zero board has a SY8113B regulator, which is controlled via
GPIO and capable of outputing 1.1V when the PL1 GPIO is set to output 0
or 1.1V when the PL6 GPIO is set to input or output 1, and the output is
the power supply of the ARM cores in H3 SoC.
Add the device tree node of this regulator and set the cpu's cpu-supply
property to it.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
On i.MX51/i.MX53 it is necessary to set the DBGEN bit in
ARM_GPC register in order to turn on the debug clocks.
The DBGEN bit of ARM_GPC register has the following description
in the i.MX53 Reference Manual:
"This allows the user to manually activate clocks within the debug
system. This register bit directly controls the platform's dbgen_out
output signal which connects to the DAP_SYS to enable all debug clocks.
Once enabled, the clocks cannot be disabled except by asserting the
disable_trace input of the DAP_SYS."
Based on a previous patch from Sebastian Reichel.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add a label for the PMU node so that the board dts may be able to
pass the 'secure-reg-access' property like this:
&pmu {
secure-reg-access;
};
This also makes it consistent with the PMU node in imx6qdl.dtsi
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Tested-by: Sebastian Reichel <sebastian.reichel@collabora.co.uk>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
As per the i.MX53 Reference Manual add an entry for the
'tigerp' region in the device tree.
This is needed for accessing the ARM_GPC register to set the
DBGEN bit, so that the debug clocks can be turned on.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
As per the i.MX51 Reference Manual add an entry for the
'tigerp' region in the device tree.
This is needed for accessing the ARM_GPC register to set the
DBGEN bit, so that the debug clocks can be turned on.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add PMU support in the device tree.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Configure the M4IF registers as per the vendor bootloader
to avoid visual artifacts during video playback.
This way we don't need to rely on the bootloader configuration for
optimal IPU/VPU bus priorities.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Sergey Lapin <sergey.lapin@cogentembedded.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
As per the i.MX51 Reference Manual the M4IF register region
starts at 0x83fd8000 and has a 4kB address range.
Add support for it.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Tested-by: Sergey Lapin <sergey.lapin@cogentembedded.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
i.MX6UL has GPIO clock gates in CCM CCGR, add
clock property for GPIO driver to make sure all
GPIO banks work as expected.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Memory layout is not fixed for noMMU xtensa configurations. Platforms
that need to use coherent DMA should implement platform_vaddr_* helpers
that check address type (cached/uncached) and convert addresses between
these types.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
Dynamic ftrace requires modifying the code segments that are usually
set to read-only. To do this, a per arch function is called both before
and after the ftrace modifications are performed. The "before" function
will set kernel code text to read-write to allow for ftrace to make the
modifications, and the "after" function will set the kernel code text
back to "read-only" to keep the kernel code text protected.
The issue happens when dynamic ftrace is tested at boot up. The test is
done before the kernel code text has been set to read-only. But the
"before" and "after" calls are still performed. The "after" call will
change the kernel code text to read-only prematurely, and other boot
code that expects this code to be read-write will fail.
The solution is to add a variable that is set when the kernel code text
is expected to be converted to read-only, and make the ftrace "before"
and "after" calls do nothing if that variable is not yet set. This is
similar to the x86 solution from commit 162396309745 ("ftrace, x86:
make kernel text writable only for conversions").
Link: http://lkml.kernel.org/r/20180620212906.24b7b66e@vmware.local.home
Reported-by: Stefan Agner <stefan@agner.ch>
Tested-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
An application that doesn't need kernel mapping of the DMA memory it
allocates may specify DMA_ATTR_NO_KERNEL_MAPPING attribute to allocation
function. Support this attribute and return address of the first struct
page that covers the allocation.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
Switch to the generic noncoherent direct mapping implementation.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
|
|
mprotect(EXEC) was failing for stack mappings as default vm flags was
missing MAYEXEC.
This was triggered by glibc test suite nptl/tst-execstack testcase
What is surprising is that despite running LTP for years on, we didn't
catch this issue as it lacks a directed test case.
gcc dejagnu tests with nested functions also requiring exec stack work
fine though because they rely on the GNU_STACK segment spit out by
compiler and handled in kernel elf loader.
This glibc case is different as the stack is non exec to begin with and
a dlopen of shared lib with GNU_STACK segment triggers the exec stack
proceedings using a mprotect(PROT_EXEC) which was broken.
CC: stable@vger.kernel.org
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
|
|
It does not matter if the caller of may_use_simd() migrates to
another cpu after the call, but it is still important that the
kernel_neon_busy percpu instance that is read matches the cpu the
task is running on at the time of the read.
This means that raw_cpu_read() is not sufficient. kernel_neon_busy
may appear true if the caller migrates during the execution of
raw_cpu_read() and the next task to be scheduled in on the initial
cpu calls kernel_neon_begin().
This patch replaces raw_cpu_read() with this_cpu_read() to protect
against this race.
Cc: <stable@vger.kernel.org>
Fixes: cb84d11e1625 ("arm64: neon: Remove support for nested or hardirq kernel-mode NEON")
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Dave Martin <Dave.Martin@arm.com>
Reviewed-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Yandong Zhao <yandong77520@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
Add support for the Zodiac Inflight Innovations i.MX51-base SCU3 Ethernet
Switch Board (ESB)
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: cphealy@gmail.com
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
With old bindings imx_gpc_onecell_data always sets num_domains to 2 so
the DISPMIX domain can't actually be referenced. The pd is still defined
and pm core shuts it down as "unused" so display can't work.
Fix this by converting to new gpc bindings by adding pgc nodes and
referencing the newly-defined &pu_disp domain from &lcdif.
Signed-off-by: Leonard Crestez <leonard.crestez@nxp.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The labels for RWDT device node were named as 2 types now:
- wdt0: r8a7795, r8a7796, r8a77965.
- rwdt: r8a77970, r8a77990, r8a77995.
To be made consistent, this patch unifis the labels as the hardware
name "rwdt".
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
|
|
i.MX6SX has a 16KB always-on ocram bank called
ocram_s, enable it as another mmio sram.
Signed-off-by: Anson Huang <Anson.Huang@nxp.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The imx6sl platform has two different cpuidle implementations,
and fails to link if we only want one of the two:
arch/arm/mach-imx/mach-imx6sl.o: In function `imx6sl_init_late':
mach-imx6sl.c:(.init.text+0x12): undefined reference to `imx6sx_cpuidle_init'
This makes the call into reference conditional on the configuration.
Fixes: e7fa1fb39b11 ("ARM: imx: add cpu idle support for i.MX6SLL")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The i.MX6SLL cpuidle support reuses the i.MX6SX implementation, but
the Makefile accidentally enables the i.MX6SL one as well, which
then fails with a link error unless the kernel also enables the
the i.MX6SL clock driver:
arch/arm/mach-imx/cpuidle-imx6sl.o: In function `imx6sl_enter_wait':
cpuidle-imx6sl.c:(.text+0x24): undefined reference to `imx6sl_set_wait_clk'
This changes the two lines that were just modified again, hopefully
getting every case right this time.
Fixes: e7fa1fb39b11 ("ARM: imx: add cpu idle support for i.MX6SLL")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
100/200MHz states for USDHC3 are not required since the SoC
does not support modes faster than DDR52 for the on board eMMC.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
VDDD is connected to VGEN4 of the PF0100. This rail should only
run at 1.8V since there are multiple consumer and they all
expect the rail to be at 1.8V.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Remove the 2.5V regulator, it does not exist. There is 3.3V and
3.3V_AUDIO provided to the module through the edge connector,
model those as fixed regulators like we use to do in other
Colibri device trees. The SGTL5000 uses 3.3V_AUDIO as VDDA. Note
that the driver derives the analog ground voltage (VAG) from this
supply. The new value should allow higher output swings before
clipping occurs. Refer to the SGTL5000 datasheet for details.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The fixed 1.8V regulator is not used, and there is in fact no
fixed 1.8V regulator on the module. Remove it.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Use the disable-wp to indicate that Apalis and Colibri iMX6 do not
make use of the native write-protect signal available on the i.MX 6
SoCs. This prevents warnings:
mmc0: host does not support reading read-only switch, assuming write-enable
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Use no-1-8-v device tree property to indicate that the board does
not support 1.8V signaling. The property voltage-ranges seems not
appropriate in our case since we do not have level shifters in
place.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add the 3.3V main supply on the carrier board. Currently as a fixed
supply since not all consumer are modeled yet. This gets also rid of
some missing supply warnings.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add Apalis UART1 as default serial console.
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
|
|
imx_set_aips is assuming that the address returned from of_iomap is
valid which it probably is in the normal case - as the call site
is void error propagation is not possible but never the less at least
a WARN_ON() seems warranted here.
Signed-off-by: Nicholas Mc Guire <hofrat@osadl.org>
Fixes: commit e57e4ab5fc2e ("ARM: i.MX: allow disabling supervisor protect via DT")
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Add support for the Zodiac Inflight Innovations SCU2 Mezz
board (i.MX51-based).
Cc: Fabio Estevam <fabio.estevam@nxp.com>
Cc: Nikita Yushchenko <nikita.yoush@cogentembedded.com>
Cc: Lucas Stach <l.stach@pengutronix.de>
Cc: cphealy@gmail.com
Cc: Rob Herring <robh+dt@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: devicetree@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Andrey Gusakov <andrey.gusakov@cogentembedded.com>
Signed-off-by: Andrey Smirnov <andrew.smirnov@gmail.com>
Tested-by: Chris Healy <cphealy@gmail.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
As documented in GCC naked functions should only use basic ASM
syntax. The extended ASM or mixture of basic ASM and "C" code is
not guaranteed. Currently this works because it was hard coded
to follow and check GCC behavior for arguments and register
placement.
Furthermore with clang using parameters in Extended asm in a
naked function is not supported:
arch/arm/firmware/trusted_foundations.c:47:10: error: parameter
references not allowed in naked functions
: "r" (type), "r" (arg1), "r" (arg2)
^
Use a regular function to be more portable. This aligns also with
the other SMC call implementations e.g. in qcom_scm-32.c and
bcm_kona_smc.c.
Cc: Dmitry Osipenko <digetx@gmail.com>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
|
|
Since commit 654f2b937b38 ("crypto: caam - allow retrieving 'era' from
register") the CAAM driver is capable of obtaining the era version by
reading the appropriate CAAM registers, so let the CAAM driver discover
the era version in run-time instead of hardcoding such information in the
device tree.
According to Documentation/devicetree/bindings/crypto/fsl-sec4.txt the
'fsl,sec-era' is an optional property and this can be safely removed
now.
Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
Implement calls to rseq_signal_deliver, rseq_handle_notify_resume
and rseq_syscall so that we can select HAVE_RSEQ on arm64.
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
The added DTS contains a combined description of LogicPD MX31 Lite
SoM devices, peripherals are routed to ports on a baseboard:
* PATA controller,
* SD/MMC controller,
* 2 GPIO LEDs,
* UART controllers,
* Freescale MC13783 MFD connected over SPI,
* SMSC LAN9117,
* ST Micro NAND SLC, 64 MiB,
* Intel NOR flash, 16 MiB.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
The change adds a number of basic peripherals found on i.MX31 SoC:
* GPIO controllers,
* I2C master controllers,
* SPI master controllers,
* ATA controller,
* SDHC controllers,
* RTC, watchdog and PWM contollers,
* SDMA,
* IRAM,
* NAND and WEIM controllers on EMI.
The added controller devices were tested on Freescale i.MX31 powered
LogicPD Lite SoM and baseboard.
DMA functionality was tested on SDHC and SPI controllers so far,
thus dmas properties are added to those device nodes only.
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
On i.MX31 powered boards with OF support Security Random Number
Generator Accelerator RNGA controller is initialized from device tree,
its registration as a platform device is redundant and actually it is
broken due to missing clock information:
mxc_rnga mxc_rnga: Could not get rng_clk!
mxc_rnga: probe of mxc_rnga failed with error -2
Signed-off-by: Vladimir Zapolskiy <vz@mleia.com>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
Signed-off-by: Shawn Guo <shawnguo@kernel.org>
|
|
PciIo->Attributes()
Hans de Goede reported that his mixed EFI mode Bay Trail tablet
would not boot at all any more, but enter a reboot loop without
any logs printed by the kernel.
Unbreak 64-bit Linux/x86 on 32-bit UEFI:
When it was first introduced, the EFI stub code that copies the
contents of PCI option ROMs originally only intended to do so if
the EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM attribute was *not* set.
The reason was that the UEFI spec permits PCI option ROM images
to be provided by the platform directly, rather than via the ROM
BAR, and in this case, the OS can only access them at runtime if
they are preserved at boot time by copying them from the areas
described by PciIo->RomImage and PciIo->RomSize.
However, it implemented this check erroneously, as can be seen in
commit:
dd5fc854de5fd ("EFI: Stash ROMs if they're not in the PCI BAR")
which introduced:
if (!attributes & EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM)
continue;
and given that the numeric value of EFI_PCI_IO_ATTRIBUTE_EMBEDDED_ROM
is 0x4000, this condition never becomes true, and so the option ROMs
were copied unconditionally.
This was spotted and 'fixed' by commit:
886d751a2ea99a160 ("x86, efi: correct precedence of operators in setup_efi_pci")
but inadvertently inverted the logic at the same time, defeating
the purpose of the code, since it now only preserves option ROM
images that can be read from the ROM BAR as well.
Unsurprisingly, this broke some systems, and so the check was removed
entirely in the following commit:
739701888f5d ("x86, efi: remove attribute check from setup_efi_pci")
It is debatable whether this check should have been included in the
first place, since the option ROM image provided to the UEFI driver by
the firmware may be different from the one that is actually present in
the card's flash ROM, and so whatever PciIo->RomImage points at should
be preferred regardless of whether the attribute is set.
As this was the only use of the attributes field, we can remove
the call to PciIo->Attributes() entirely, which is especially
nice because its prototype involves uint64_t type by-value
arguments which the EFI mixed mode has trouble dealing with.
Any mixed mode system with PCI is likely to be affected.
Tested-by: Wilfried Klaebe <linux-kernel@lebenslange-mailadresse.de>
Tested-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Matt Fleming <matt@codeblueprint.co.uk>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20180711090235.9327-2-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
With the recent syntax extension, Kconfig is now able to evaluate the
compiler / toolchain capability.
However, accumulating flags to 'LD' is not compatible with the way
it works; 'LD' must be passed to Kconfig to call $(ld-option,...)
from Kconfig files. If you tweak 'LD' in arch Makefile depending on
CONFIG_CPU_BIG_ENDIAN, this would end up with circular dependency
between Makefile and Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Exception return implies context synchronization, so we can hook up the
SYNC_CORE option to sys_membarrier() simply by selecting the Kconfig option,
just like we've done for arm64 already.
Cc: Orion Hodson <oth@google.com>
Acked-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
Greg reported that commit 3c24121039c9d ("ARM: 8756/1: NOMMU: Postpone
MPU activation till __after_proc_init") is causing breakage for the
old Versatile platform in no-MMU mode (with out-of-tree patches):
AS arch/arm/kernel/head-nommu.o
arch/arm/kernel/head-nommu.S: Assembler messages:
arch/arm/kernel/head-nommu.S:180: Error: selected processor does not support `isb' in ARM mode
scripts/Makefile.build:417: recipe for target 'arch/arm/kernel/head-nommu.o' failed
make[2]: *** [arch/arm/kernel/head-nommu.o] Error 1
Makefile:1034: recipe for target 'arch/arm/kernel' failed
make[1]: *** [arch/arm/kernel] Error 2
Since the code is common for all NOMMU builds usage of the isb was a
bad idea (please, note that isb also used in MPU related code which is
fine because MPU has dependency on CPU_V7/CPU_V7M), instead use more
robust instr_sync assembler macro.
Fixes: 3c24121039c9 ("ARM: 8756/1: NOMMU: Postpone MPU activation till __after_proc_init")
Reported-by: Greg Ungerer <gerg@kernel.org>
Tested-by: Greg Ungerer <gerg@kernel.org>
Signed-off-by: Vladimir Murzin <vladimir.murzin@arm.com>
Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
|
|
This adds a SRAM controller node for the H3, with support for the C1
SRAM region that is shared between the Video Engine and the CPU.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
[Maxime: Fixed the compatible and commit prefix]
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
This adds a SRAM controller node for the A23 and A33, with support for
the C1 SRAM region that is shared between the Video Engine and the CPU.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
[Maxime: Fixed the prefix and the compatibles]
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
This adds support for the C1 SRAM region (to be used with the SRAM
controller driver) for the A20 platform. The region is shared
between the Video Engine and the CPU.
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
[Maxime: Fixed the SRAM C size]
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
This adds support for the C1 SRAM region (to be used with the SRAM
controller driver) for sun5i-based platforms. The region is shared
between the Video Engine and the CPU.
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
[Maxime: Fixed the SRAM C size to take the C2 and C3 SRAM into account]
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
This switches the sun7i-a20 dtsi to use the most qualified compatibles
for the system-control block (previously named SRAM controller) as well
as the SRAM blocks. The sun4i-a10 compatibles are kept since these
hardware blocks are backward-compatible.
The node name for system control is also updated to reflect the fact that
the controller described is really about system control rather than SRAM
control.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
This switches the sun5i dtsi to use the most qualified compatibles for
the system-control block (previously named SRAM controller) as well as
the SRAM blocks.
The node name for system control is also updated to reflect the fact that
the controller described is really about system control rather than SRAM
control.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
[Maxime: Removed the A10 compatible for the driver]
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
