IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The debug UART is very useful to have. I2C10 is enabled as an example
of a I2C port we can talk on for now. Eventually we'll want to put
peripherals under it.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
This adds nodes to SDM845-dtsi for all the I2C ports, all the SPI
ports, and UART9. Note that I2C / SPI / UART are a bit strange on
sdm845 because each "serial engine" has 4 pins associated with it and
depending on which firmware has been loaded into the serial engine
(loaded by the BIOS) the serial engine can behave like an I2C port, a
SPI port, or a UART. As per the landed bindings that means that we
need to create one node for each possible mode that the port could be
in. With 16 serial engines that means 16 x 3 = 48 nodes.
We get away with only creating 33 nodes for now because it seems very
likely that SDM845-based boards will actually all use the same UART
(UART 9) for debug purposes. While another UART could be used for
something like Bluetooth communication we can cross that path when we
come to it. Some documentation that I saw implied that using a UART
for "high speed" communications actually needs yet another different
serial engine firmware anyway.
Note that quick measurements adding all these nodes adds <10k of extra
space per dtb that they're included with. If this becomes a problem
we may need to think of a different way to structure this so that
boards only get the nodes they need (or figure out how to get dtc to
strip 'disabled' nodes). For now it seems OK.
These nodes were programmatically generated with a fairly dumb python
script. See http://crosreview.com/1091631 for the source.
NOTE: at the moment SPI chip select doesn't appear to work in my tests
with the latest posted SPI driver. All testing of SPI with this patch
has been done by hacking SPI to GPIO chip select.
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
Add basic support for the pm8005 and pm8998 PMICs. For now just support
the GPIO controllers.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Evan Green <evgreen@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
The get/set events helpers to do some work to check reserved
and padding fields are zero. This is useful on 32bit too.
Move this code into virt/kvm/arm/arm.c, and give the arch
code some underscores.
This is temporarily hidden behind __KVM_HAVE_VCPU_EVENTS until
32bit is wired up.
Signed-off-by: James Morse <james.morse@arm.com>
Reviewed-by: Dongjiu Geng <gengdongjiu@huawei.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
For the arm64 RAS Extension, user space can inject a virtual-SError
with specified ESR. So user space needs to know whether KVM support
to inject such SError, this interface adds this query for this capability.
KVM will check whether system support RAS Extension, if supported, KVM
returns true to user space, otherwise returns false.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
[expanded documentation wording]
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
For the migrating VMs, user space may need to know the exception
state. For example, in the machine A, KVM make an SError pending,
when migrate to B, KVM also needs to pend an SError.
This new IOCTL exports user-invisible states related to SError.
Together with appropriate user space changes, user space can get/set
the SError exception state to do migrate/snapshot/suspend.
Signed-off-by: Dongjiu Geng <gengdongjiu@huawei.com>
Reviewed-by: James Morse <james.morse@arm.com>
[expanded documentation wording]
Signed-off-by: James Morse <james.morse@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
When running on a non-VHE system, we initialize tpidr_el2 to
contain the per-CPU offset required to reach per-cpu variables.
Actually, we initialize it twice: the first time as part of the
EL2 initialization, by copying tpidr_el1 into its el2 counterpart,
and another time by calling into __kvm_set_tpidr_el2.
It turns out that the first part is wrong, as it includes the
distance between the kernel mapping and the linear mapping, while
EL2 only cares about the linear mapping. This was the last vestige
of the first per-cpu use of tpidr_el2 that came in with SDEI.
The only caller then was hyp_panic(), and its now using the
pc-relative get_host_ctxt() stuff, instead of kimage addresses
from the literal pool.
It is not a big deal, as we override it straight away, but it is
slightly confusing. In order to clear said confusion, let's
set this directly as part of the hyp-init code, and drop the
ad-hoc HYP helper.
Reviewed-by: James Morse <james.morse@arm.com>
Acked-by: Christoffer Dall <christoffer.dall@arm.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
Add the CPU PMU on sdm845 to get perf support for hardware events.
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Andy Gross <andy.gross@linaro.org>
The Tanix TX3 Mini is a TV box based on the Amlogic S905W chipset.
There are two variants:
- 1 GiB or 2 GiB of DDR3 memory
- 8 GB or 16 GB eMMC flash
Both variants come with:
- 802.11 b/g/n wifi (Silicon Valley Microelectronics SSV6051, does not
support Bluetooth)
- an LED 7 segment display with an FD628 controller
- HDMI and AV (CVBS) output
- 2x USB (utilizing both USB ports provided by the SoC)
- micro SD card slot
- serial console (uart_AO) has to be soldered after opening the case
The board seems to be very similar to the P23x and Q20x reference
boards, which is why it includes meson-gx-p23x-q20x.dtsi:
- eMMC reset routed to BOOT_9
- the SDIO wifi chip's reset line is routed to GPIOX_6 and the reference
clock is 32.768KHz on PWM_E
- SD card detection is routed to CARD_6
- vqmmc of all MMC controllers is hard-wired to 1.8V (VDDIO_BOOT)
- uart_AO can be accessed after opening the case and soldering RX, TX
and GND lines onto the exposed solder points (marked with RX, TX and
GND)
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
S905W is a new SoC from the GXL series. It is a cost-reduced version of
the S905X.
The P281 development board from Amlogic uses the same layout as the P231
(S905D development board). Thus the new P281 board inherits
meson-gx-p23x-q20x.dtsi to avoid code-duplication.
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add the audio clock controller which is part of the audio bus
This controller takes 8 input plls, and the usual clock gate, from the
main clock controller. It provides the clocs for the all the devices of
the audio subsystem, such as tdms, spdif, pdm, etc.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add initial device tree support for Mediatek X20 Development Board
based on MT6797 Deca core SoC. This board is one of the 96Boards
Consumer Edition platform.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Matthias Brugger <matthias.bgg@gmail.com>
Spdif out in not multiplexed on gpio A7 (spdif in is)
Remove this entry to fix the problem.
Fixes: 53c03b0aff36 ("ARM64: dts: meson-axg: add spdif output pins")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Regulator should not be defined inside the SoC dtsi file.
vddio_ao18 is already defined in the S400 board dts anyway.
Fixes: bb8a2ebd0498 ("ARM64: dts: meson-axg: add saradc support")
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add the DT info for SAR ADC of the Amlogic's Meson-AXG SoC.
Signed-off-by: Xingyu Chen <xingyu.chen@amlogic.com>
Signed-off-by: Yixun Lan <yixun.lan@amlogic.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
The Amlogic P241 board is the Reference Design board for the S805X
variant of the Amlogic Meson GXL SoC family.
The P241 board has the following features :
- 1GiB DDR4 Memory
- HDMI Connector with CEC
- A/V jack with Stereo Audio and CVBS
- 10/100 Ethernet
- 2x USB2.0 Type-A
- On-board WiFi SDIO Module
- On-board eMMC storage
- Infraread Received
- Factory Reset button
- UART connector
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Acked-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[khilman: s/arm64/ARM64/ in Subject]
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add the different pin configurations for the spdif output
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add the first of the two tas5707 power amplifier present on the
speaker daughter board.
According to the schematics of the S400 v3, only I2SB_DIN3 and
I2SC_DOUT2 will be available to the speaker board.
9R83, 9R84 and 9R18 are not connected so no audio signal will be
provided to the second amplifier. There is no point in enabling it
even if it is visible on the i2c bus.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Add a fixed regulator for the main 12v which is the main power supply
of the board.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
The microphone card connected to the s400 has 6 leds controlled
through an additional i2c gpio controller.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
The Amlogic Meson GXBB based Nanopi-K2 board has an HDMI connector
with CEC and CVBS available on the 40pin header.
This patch adds the nodes to enable HDMI, CEC and CVBS functionnalities.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
meson-gx-p23x-q20x.dtsi is currently used by five boards:
- Amlogic P230 and P231 (which should be identical, apart from the
external RGMII PHY on P230 whereas P231 can only use the internal PHY)
- Amlogic Q200 (identical to P230 but with an S912 GXM SoC instead of a
GXL S905D SoC) and Q201 (identical to P231 but with an S912 GXM SoC
instead of a GXL S905D SoC)
- NEXBOX A1 (based on the S912 GXM SoC)
The Amlogic P230 board uses a Broadcom BCM4356 SDIO wifi chip. Since the
other Amlogic reference design boards are very similar it's safe to
assume that these also use a Broadcom based SDIO wifi chip (which is
also how it was configured in meson-gx-p23x-q20x.dtsi).
However, NEXBOX A1 comes with a "longsys LTM8830" SDIO wifi module,
which is based on the "Qualcomm Atheros QCA9377-3(QCA1023-0)" chipset.
Thus move the wifi node from meson-gx-p23x-q20x.dtsi to each of the
four Amlogic reference board's .dts files.
There are no devicetree bindings for the QCA9377 SDIO wifi module yet,
so nothing is added to meson-gxm-nexbox-a1.dts.
Fixes: f51b454549b812 ("ARM64: dts: meson-gxm: Add support for the Nexbox A1")
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
meson-gxl-s905d-p230.dts and meson-gxm-q200.dts enable the saradc node
(and configure it's vref-supply "VDDIO_AO18") in their corresponding
.dts file.
Move both (the saradc node as well as the VDDIO_AO18 regulator) to
remove some duplicate code.
As a positive side-effect this enables the saradc also for the P231 (GXL
S905D) and Q201 (GXM S912) development boards which are similar to the
P230/Q200 boards (P231 and Q201 use the internal 100Mbit/s PHY, while
P230 and Q200 have an external RGMII PHY).
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Reviewed-by: Neil Armstrong <narmstrong@baylibre.com>
Signed-off-by: Kevin Hilman <khilman@baylibre.com>
Describe the INTC-EX interrupt controller in the R8A77980 device tree.
Based on the original (and large) patch by Vladimir Barinov.
Signed-off-by: Vladimir Barinov <vladimir.barinov@cogentembedded.com>
Signed-off-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
This patch adds and USB3.0 host device node and enable it for
R-Car E3 Ebisu board.
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>
This patch adds the device nodes for SCIF {0,1,3,4,5} and all HSCIF serial
ports, incl. clocks, power domain and DMAs.
Signed-off-by: Takeshi Kihara <takeshi.kihara.df@renesas.com>
Signed-off-by: Ulrich Hecht <ulrich.hecht+renesas@gmail.com>
Signed-off-by: Simon Horman <horms+renesas@verge.net.au>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
arm64: dts: add ufs node for Hisilicon.
Signed-off-by: Li Wei <liwei213@huawei.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Tested-by: John Stultz <john.stultz@linaro.org>
Acked-by: Wei Xu <xuwei5@hisilicon.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
The Pine H64 board have a MicroSD slot connected to MMC0 controller of
the H6 SoC and a eMMC slot connected to MMC2.
Enable them in the device tree.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
The Allwinner H6 SoC have 3 MMC controllers.
Add device tree nodes for them.
Signed-off-by: Icenowy Zheng <icenowy@aosc.io>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
address-cells/size-cells is unnecessary for dwmac-sun8i node.
It was in early days, but since a mdio node is used, it could be
removed.
This patch fix the following DT warning:
Warning (avoid_unnecessary_addr_size): /soc/ethernet@1c50000: unnecessary #address-cells/#size-cells without "ranges" or child "reg" property
Signed-off-by: Corentin Labbe <clabbe@baylibre.com>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
Avnet Ultra96 rev1 board is commercialized Xilinx zcu100 revC/D
internal board. The patch is reusing zcu100 revC files but changing
model description and compatible strings which are used for example by
libmraa.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
dts reports incorrect usage of these properties in gpio-keys node.
Warning (avoid_unnecessary_addr_size): /gpio-keys: unnecessary
The patch is removing these useless properties.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Mainline started to use serdev interface for uart attached devices.
Change description to reflect it.
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
This patch adds GPIO for headphone detection on LD11 global board.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
This patch adds GPIO for headphone detection on LD20 global board.
Signed-off-by: Katsuhiro Suzuki <suzuki.katsuhiro@socionext.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The EValuation Module(EVM) platform for AM654 consists of a
common Base board + one or more of daughter cards, which include:
a) "Personality Modules", which can be specific to a profile, such as
ICSSG enabled or Multi-media (including audio).
b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
c) Camera daughter card
d) various display panels
Among other options. There are two basic configurations defined which
include an "EVM" configuration and "IDK" (Industrial development kit)
which differ in the specific combination of daughter cards that are
used.
To simplify support, we choose to support just the base board as the
core device tree file and all daughter cards would be expected to be
device tree overlays.
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.
Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subsystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
GPIO
See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7
NOTE:
1. AM654 is the first of the device variants, hence we introduce a
generic am65.dtsi.
2. We indicate the proper bus topology, the ranges are elaborated in
each bus segment instead of using the top level ranges to make sure
that peripherals in each segment use the address space accurately.
3. Peripherals in each bus segment is maintained in a separate dtsi
allowing for reuse in different bus segment representation from a
different core such as R5. This is also the reason for maintaining a
1-1 address map in the ranges.
4. Cache descriptions follow the ARM64 standard description.
Further tweaks may be necessary as we introduce more complex devices,
but can be introduced in context of the device introduction.
Reviewed-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Benjamin Fair <b-fair@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
The vDSO needs to have a unique build id in a similar manner
to the kernel and modules. Use the build salt macro.
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Laura Abbott <labbott@redhat.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
The cooling device properties, like "#cooling-cells" and
"dynamic-power-coefficient", should either be present for all the CPUs
of a cluster or none. If these are present only for a subset of CPUs of
a cluster then things will start falling apart as soon as the CPUs are
brought online in a different order. For example, this will happen
because the operating system looks for such properties in the CPU node
it is trying to bring up, so that it can register a cooling device.
Add such missing properties.
Do minor rearrangement as well to keep ordering consistent.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Wei Xu <xuwei5@hisilicon.com>
