| Age | Commit message (Collapse) | Author |
|---|
|
This patch uses the vpermxor instruction to optimise the raid6 Q
syndrome. This instruction was made available with POWER8, ISA version
2.07. It allows for both vperm and vxor instructions to be done in a
single instruction. This has been tested for correctness on a ppc64le
vm with a basic RAID6 setup containing 5 drives.
The performance benchmarks are from the raid6test in the
/lib/raid6/test directory. These results are from an IBM Firestone
machine with ppc64le architecture. The benchmark results show a 35%
speed increase over the best existing algorithm for powerpc (altivec).
The raid6test has also been run on a big-endian ppc64 vm to ensure it
also works for big-endian architectures.
Performance benchmarks:
raid6: altivecx4 gen() 18773 MB/s
raid6: altivecx8 gen() 19438 MB/s
raid6: vpermxor4 gen() 25112 MB/s
raid6: vpermxor8 gen() 26279 MB/s
Signed-off-by: Matt Brown <matthew.brown.dev@gmail.com>
Reviewed-by: Daniel Axtens <dja@axtens.net>
[mpe: Add VPERMXOR macro so we can build with old binutils]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
|
|
These drivers haven't seen any recent bug fixing and are two of the last
drivers using the scsi_module.c infrastruture that has been deprecated
15 years ago.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
|
|
The DRM driver is now finalized for the Versatile board family,
so switch the defconfig to use this driver instead of the old
fbdev driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
This updates the Versatile defconfig to the latest savedefconfig
results reflecting changes in Kconfig. We add in the Flash memory
support that has been available upstream for a while now.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The DRM driver is now finalized for the RealView board family,
so switch the defconfig to use this driver instead of the old
fbdev driver.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
Just update with some new results from savedefconfig so we are
in sync with what has happened in Kconfig upstream.
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
This adds the actual VGA DAC bridge that is used in the
Versatile AB, and sets the mode to 640x480 VGA.
The "clcd" clock was incorrectly named, the proper name
(from bindings) is "clcdclk". So far drivers survived
by just getting the first clock, but future drivers will
use named clocks.
We add the panel connector to the
"arm,versatile-tft-panel" as well, the signals actually
fork on the board, reaching both the VGA DAC and the
display connector.
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The Versatile board can be equipped with a interface board
just named "IB2". This was created in the early 2000s for
prototyping GSM candybar phone form factor products.
The IB2 board contains:
- Cascaded interrupt controller
- Enfora Enabler GSM0308 quad-band module with antenna and
separate audio jack
- Keypad with joystick
- Sanyo 2.5" color display
- A 28-pin connector for mounting a camera
This adds a DTS file for the combination of the Versatile AB
with an IB2 daughterboard mounted, making the LED blink and
making the system controller available for drivers, such as
the panel driver.
The device tree bindings already exist in
Documentation/devicetree/bindings/arm/arm-boards.
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The PL111 in the ARM reference platforms are connected to
"panels" that are actually dumb VGA DAC connector bridges.
Now that we can support the proper bridges in the DRM driver,
fix this up.
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The PL111 in the ARM reference platforms are connected to
"panels" that are actually dumb VGA DAC connector bridges.
Now that we can support the proper bridges in the DRM driver,
fix this up.
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The PL111 in the ARM reference platforms are connected to
"panels" that are actually dumb VGA DAC connector bridges.
Now that we can support the proper bridges in the DRM driver,
fix this up.
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
The PL111 in the ARM reference platforms are connected to
"panels" that are actually dumb VGA DAC connector bridges.
Now that we can support the proper bridges in the DRM driver,
fix this up.
Cc: Mali DP Maintainers <malidp@foss.arm.com>
Reviewed-by: Liviu Dudau <liviu.dudau@arm.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
|
|
just use current_pt_regs()
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|
|
efuse is one time programmable, so it is safer to deny write request
to this memory, unless the user is savvy enough to remove the read-only
flag from DTB
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
The Mali-450 IP can run up to 744MHz, bump the frequency using
the GP0 PLL clock.
Cc: Michal Lazo <michal.lazo@gmail.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
|
|
The RTC core is always calling rtc_valid_tm after the read_time callback.
It is not necessary to call it just before returning from the callback.
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Helge Deller <deller@gmx.de>
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
|
|
The Cubieboard4 has a dumb VGA DAC connected to the output of LCD0,
providing VGA output through the onboard VGA connector. The DDC lines
are connected to i2c3.
The VGA DAC is a GM7123, which is compatible with Analog Devices'
ADV7123, except it only takes 3.3V power, and has a lower standby power
consumption. The datasheet found online lists "Chengdu GoldTel Electronical
Technology Co., Ltd." as its designer. The company changed its name in
2014 to "Chengdu Corpro Technology Co., Ltd.". Their website lists similar
ICs, but not actually the GM7123.
Enable the display pipeline with the VGA DAC and connector, and i2c3
for DDC.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The A80 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
for the needed pins.
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The Allwinner A80 SoC has 3 display pipelines, of which some parts are
documented:
- 3x display front ends (FE), documented
- 2x display enhancement units (DEU), undocumented
- 3x display back ends (BE), documented
- 2x dynamic range controller (DRC), undocumented
- 2x LCDC/TCONs, documented
- 1x LCDC/TCON, undocumented, and probably not useable
- 1x HDMI transmitter, undocumented but DesignWare compatible
- 1x MERGE block, function unknown
This patch adds device nodes for the first 2 documented pipelines:
FE0 - DEU0 - - BE0 - DRC0 - TCON0
x
FE1 - DEU1 - - BE1 - DRC1 - TCON1
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The TERES-I is an open hardware laptop built by Olimex using the
Allwinner A64 SoC.
Add the board specific .dts file, which includes the A64 .dtsi and
enables the peripherals that we support so far.
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
The A64 SoC features two display pipelines, one has a LCD output, the
other has a HDMI output.
Add support for simplefb for the LCD output. Tested on Teres I.
This patch was inspired by work of Icenowy Zheng.
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Add a watchdog node for the A64, automatically enabled on all boards.
Since the device is compatible with an existing driver, we only reserve
a new compatible string to be used together with the fall back.
Tested on Olimex Teres-I.
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Add the proper pin group node to reference in board files.
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Pine H64 is an Allwinner H6-based SBC from Pine64, with the following
features:
- 1GiB/2GiB/4GiB LPDDR3 DRAM (in 4GiB situation only 3GiB is
accessible)
- AXP805 PMIC
- Raspberry-Pi-compatible GPIO header, "Euler" GPIO header (not
compatible with the "Euler" on Pine A64) and "Expansion" pin header
- 2 USB 2.0 ports and 1 USB 3.0 ports
- Audio jack
- MicroSD slot and eMMC module slot
- on-board SPI NOR flash
- 1Gbps Ethernet port (via RTL8211E PHY)
- HDMI port
Adds initial support for it, including the UART on the Expansion pin
header.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Allwinner H6 is a new SoC with Cortex-A53 cores from Allwinner, with its
memory map fully reworked and some high-speed peripherals (PCIe, USB
3.0) introduced.
This commit adds the basical DTSI file of it, including the clock
support and UART support.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
|
|
Signed-off-by: Ingo Molnar <mingo@kernel.org>
|
|
The function SMCCC_ARCH_WORKAROUND_1 was introduced as part of SMC
V1.1 Calling Convention to mitigate CVE-2017-5715. This patch uses
the standard call SMCCC_ARCH_WORKAROUND_1 for Falkor chips instead
of Silicon provider service ID 0xC2001700.
Cc: <stable@vger.kernel.org> # 4.14+
Signed-off-by: Shanker Donthineni <shankerd@codeaurora.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
Expose the new features introduced by Arm v8.4 extensions to
Arm v8-A profile.
These include :
1) Data indpendent timing of instructions. (DIT, exposed as HWCAP_DIT)
2) Unaligned atomic instructions and Single-copy atomicity of loads
and stores. (AT, expose as HWCAP_USCAT)
3) LDAPR and STLR instructions with immediate offsets (extension to
LRCPC, exposed as HWCAP_ILRCPC)
4) Flag manipulation instructions (TS, exposed as HWCAP_FLAGM).
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Reviewed-by: Dave Martin <dave.martin@arm.com>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
Now that we started keeping modules within 4 GB of the core kernel
in all cases, we no longer need to special case the adr_l/ldr_l/str_l
macros for modules to deal with them being loaded farther away.
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
The printk symbol was intended as a generic address that is always
exported, however that turned out to be false with CONFIG_PRINTK=n:
ERROR: "printk" [arch/arm64/kernel/arm64-reloc-test.ko] undefined!
This changes the references to memstart_addr, which should be there
regardless of configuration.
Fixes: a257e02579e4 ("arm64/kernel: don't ban ADRP to work around Cortex-A53 erratum #843419")
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Will Deacon <will.deacon@arm.com>
|
|
We have a KVM_REG_ARM encoding that we use to expose KVM guest registers
to userspace. Define that bit 28 in this encoding indicates secure vs
nonsecure, so we can distinguish the secure and nonsecure banked versions
of a banked AArch32 register.
For KVM currently, all guest registers are nonsecure, but defining
the bit is useful for userspace. In particular, QEMU uses this
encoding as part of its on-the-wire migration format, and needs to be
able to describe secure-bank registers when it is migrating (fully
emulated) EL3-enabled CPUs.
Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
Resolve conflicts with current mainline
|
|
The schematic of the espressobin is publicly available, add a comment
where to find it.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
This extra clock is needed to access the registers of the PCIe host
controller used on CP110 component of the Armada 7K/8K SoCs.
This follow the changes already made in the binding documentation (as
well as in the driver): "PCI: armada8k: Fix clock resource by adding
a register clock"
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
This extra clock is needed to access the registers of the NAND controller
used on CP110 component of the Armada 7K/8K SoCs.
This follow the changes already made in the binding documentation (as
well as in the driver): "mtd: nand: marvell: Fix clock resource by adding
a register clock"
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
This extra clock is needed to access the registers of the safexcel EIP97
used on CP110 component of the Armada 7K/8K SoCs.
This follow the changes already made in the binding documentation (as
well as in the driver): "crypto: inside-secure - fix clock resource by
adding a register clock"
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
This extra clock is needed to access the registers of the harware RNG
used on CP110 component of the Armada 7K/8K SoCs.
This follow the changes already made in the binding documentation (as
well as in the driver): "hwrng: omap - Fix clock resource by adding a
register clock"
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
This extra clock is needed to access the registers of the XOR engine
controller used on CP110 component of the Armada 7K/8K SoCs.
This follow the changes already made in the binding documentation (as
well as in the driver): "dmaengine: mv_xor_v2: Fix clock resource by
adding a register clock"
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
This extra clock is needed to access the registers of the USB host
controller used on Armada 7K/8K SoCs.
This follow the changes already made in the binding documentation (as
well as in the driver): "usb: host: xhci-plat: Fix clock resource by
adding a register clock"
Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
|
|
Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for
ARM64") added this generic function with the intent of using it
everywhere and ultimately killing the old arch-specific implementations.
Let's get on with that eradication...
Signed-off-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
These macros are required for generic mmap.c implementation created by:
commit f719582435af ("PCI: Add pci_mmap_resource_range() and use it for
ARM64") which Microblaze is going to use.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Suggested-by: David Woodhouse <dwmw@amazon.co.uk>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
|
|
Cortex-A57 and A72 are vulnerable to the so-called "variant 3a" of
Meltdown, where an attacker can speculatively obtain the value
of a privileged system register.
By enabling ARM64_HARDEN_EL2_VECTORS on these CPUs, obtaining
VBAR_EL2 is not disclosing the hypervisor mappings anymore.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
We're now ready to map our vectors in weird and wonderful locations.
On enabling ARM64_HARDEN_EL2_VECTORS, a vector slot gets allocated
if this hasn't been already done via ARM64_HARDEN_BRANCH_PREDICTOR
and gets mapped outside of the normal RAM region, next to the
idmap.
That way, being able to obtain VBAR_EL2 doesn't reveal the mapping
of the rest of the hypervisor code.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
We're about to need to allocate hardening slots from other parts
of the kernel (in order to support ARM64_HARDEN_EL2_VECTORS).
Turn the counter into an atomic_t and make it available to the
rest of the kernel. Also add BP_HARDEN_EL2_SLOTS as the number of
slots instead of the hardcoded 4...
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
Until now, all EL2 executable mappings were derived from their
EL1 VA. Since we want to decouple the vectors mapping from
the rest of the hypervisor, we need to be able to map some
text somewhere else.
The "idmap" region (for lack of a better name) is ideally suited
for this, as we have a huge range that hardly has anything in it.
Let's extend the IO allocator to also deal with executable mappings,
thus providing the required feature.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
So far, the branch from the vector slots to the main vectors can at
most be 4GB from the main vectors (the reach of ADRP), and this
distance is known at compile time. If we were to remap the slots
to an unrelated VA, things would break badly.
A way to achieve VA independence would be to load the absolute
address of the vectors (__kvm_hyp_vector), either using a constant
pool or a series of movs, followed by an indirect branch.
This patches implements the latter solution, using another instance
of a patching callback. Note that since we have to save a register
pair on the stack, we branch to the *second* instruction in the
vectors in order to compensate for it. This also results in having
to adjust this balance in the invalid vector entry point.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
So far, we only reserve a single instruction in the BPI template in
order to branch to the vectors. As we're going to stuff a few more
instructions there, let's reserve a total of 5 instructions, which
we're going to patch later on as required.
We also introduce a small refactor of the vectors themselves, so that
we stop carrying the target branch around.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
There is no reason why the BP hardening vectors shouldn't be part
of the HYP text at compile time, rather than being mapped at runtime.
Also introduce a new config symbol that controls the compilation
of bpi.S.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
All our useful entry points into the hypervisor are starting by
saving x0 and x1 on the stack. Let's move those into the vectors
by introducing macros that annotate whether a vector is valid or
not, thus indicating whether we want to stash registers or not.
The only drawback is that we now also stash registers for el2_error,
but this should never happen, and we pop them back right at the
start of the handling sequence.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Reviewed-by: Andrew Jones <drjones@redhat.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
|
We currently provide the hyp-init code with a kernel VA, and expect
it to turn it into a HYP va by itself. As we're about to provide
the hypervisor with mappings that are not necessarily in the memory
range, let's move the kern_hyp_va macro to kvm_get_hyp_vector.
No functionnal change.
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
|
