In accordance with the DWC USB3 bindings the corresponding node
name is suppose to comply with the Generic USB HCD DT schema, which
requires the USB nodes to have the name acceptable by the regexp:
"^usb(@.*)?" . Make sure the "snps,dwc3"-compatible nodes are correctly
named.
Signed-off-by: Serge Semin <Sergey.Semin@baikalelectronics.ru>
Acked-by: Krzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: Santosh Shilimkar <santosh.shilimkar@oracle.com>
Ux500 DTS updates for the v5.12 kernel cycle:
- A new DTS file for the Samsung GT-I9070 (Janice)
- Fix up ADC channel name attributes
- Add charger interrupts
- Add thermistors to the HREF boards
- Remove the non-existing AB8505 HW ADC IRQ
- Push down the VMMCI setting to each board
- Add the die temperature channel to teh AB8505
- Fix up the MMC host names to follow the standard
naming convention
* tag 'ux500-dts-v5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik:
ARM: dts: Fix up MMC host node names
ARM: dts: ux500: Add die temperature to AB8505
ARM: dts: ux500: Push VMMCI down to each tree
ARM: dts: ux500: Remove the GPADC HW IRQ
ARM: dts: ux500: Add thermistors to the HREF
ARM: dts: ux500: Add interrupts to charger
ARM: dts: ux500: Fix channel names attributes
ARM: dts: ux500: Add a device tree for Janice
Link: https://lore.kernel.org/r/CACRpkdbn=P63V9aEO2wKu2DwvVUcbjwCEV_JvKwWZ0netT75ig@mail.gmail.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The BreadBee and the BreadBee Crust are the same PCB with a different
SoC mounted. There are two top level dts to handle this.
To avoid deduplicating the parts that are more related to the PCB than
the SoC (i.e. the voltage regs and LEDs) add a common dtsi that can
be included in both top level dts.
Signed-off-by: Daniel Palmer <daniel@0x0f.com>
Link: https://lore.kernel.org/r/20201224020354.2212037-1-daniel@0x0f.com'
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
AT91 DT for 5.12:
- removing a property never documented nor used
- adding i2c recovery GPI for one more board
* tag 'at91-dt-5.12' of git://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
ARM: dts: at91: sama5d2: remove atmel,wakeup-type references
ARM: dts: at91-sama5d27_wlsom1: add i2c recovery
Link: https://lore.kernel.org/r/20210122145056.171283-1-nicolas.ferre@microchip.com
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Now the dtbs_check produces below warnings
sdhci@4f80000: clock-names:0: 'clk_ahb' was expected
sdhci@4f80000: clock-names:1: 'clk_xin' was expected
$nodename:0: 'sdhci@4f80000' does not match '^mmc(@.*)?$'
Fix above warnings by updating mmc DT definitions to follow
sdhci-am654.yaml bindings:
- rename sdhci dt nodes to 'mmc@'
- swap clk_xin/clk_ahb clocks, the clk_ahb clock expected to be defined
first
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Suman Anna <s-anna@ti.com>
Reviewed-by: Aswath Govindraju <a-govindraju@ti.com>
Link: https://lore.kernel.org/r/20210115193016.5581-1-grygorii.strashko@ti.com
The commit 3eb619b2f7 ("scripts/dtc: Update to upstream version
v1.6.0-11-g9d7888cbf19c") updated dtc version which also contained DTC
commit
"81e0919a3e21 checks: Add interrupt provider test"
where reasons for this checking are mentioned as
"A missing #address-cells property is less critical, but creates
ambiguities when used in interrupt-map properties, so warn about this as
well now."
That's why add address-cells property to gic and gpio nodes to get rid of
this warning.
CC: Andre Przywara <andre.przywara@arm.com>
Signed-off-by: Michal Simek <michal.simek@xilinx.com>
Link: https://lore.kernel.org/r/e4f54ddce33b79a783aa7c76e0dc6e9787933610.1606918493.git.michal.simek@xilinx.com
Late devicetree changes for omaps for v5.11 merge window
Here are few more late changes that would be nice to get into v5.11:
- More updates to use cpsw switchdev driver
- Enable gta04 PMIC power management
- Updates for dra7 for ECC support, 1.8GHz speed and keep the
ldo0 regulator always on as specified in the data manual
This adds a device-tree definition for the CSI0 MCLK pin,
which can be used for feeding MIPI CSI-2 sensors.
Signed-off-by: Paul Kocialkowski <contact@paulk.fr>
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The H6 SoC contains an undocumented but fully functional RSB controller.
Add support for it. The MMIO register address matches other SoCs of the
same generation, and the IRQ matches a hole in the documented IRQ list.
Signed-off-by: Samuel Holland <samuel@sholland.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
[wens@csie.org: Use raw numbers instead of macros for clock/reset index]
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
The node names for devices using the pwm-leds driver follow a certain
naming scheme (now). Parent node name is not enforced, but recommended
by DT project.
DTC arch/arm/boot/dts/stm32mp157c-lxa-mc1.dt.yaml
CHECK arch/arm/boot/dts/stm32mp157c-lxa-mc1.dt.yaml
/home/alex/build/linux/arch/arm/boot/dts/stm32mp157c-lxa-mc1.dt.yaml: led-rgb: 'led-blue', 'led-green', 'led-red' do not match any of the regexes: '^led(-[0-9a-f]+)?$', 'pinctrl-[0-9]+'
From schema: /home/alex/src/linux/leds/Documentation/devicetree/bindings/leds/leds-pwm.yaml
Signed-off-by: Alexander Dahl <post@lespocky.de>
Acked-by: Ahmad Fatoum <a.fatoum@pengutronix.de>
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
The GPIO hog node name should match regex '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$',
make it so and fix the following two make dtbs_check warnings:
arch/arm/boot/dts/stm32mp157c-dhcom-picoitx.dt.yaml: hog-usb-port-power: $nodename:0: 'hog-usb-port-power' does not match '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$'
arch/arm/boot/dts/stm32mp153c-dhcom-drc02.dt.yaml: hog-usb-hub: $nodename:0: 'hog-usb-hub' does not match '^(hog-[0-9]+|.+-hog(-[0-9]+)?)$'
Fixes: ac68793f49 ("ARM: dts: stm32: Add DHCOM based PicoITX board")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Alexandre Torgue <alexandre.torgue@st.com>
Cc: Maxime Coquelin <mcoquelin.stm32@gmail.com>
Cc: Patrice Chotard <patrice.chotard@st.com>
Cc: Patrick Delaunay <patrick.delaunay@st.com>
Cc: linux-stm32@st-md-mailman.stormreply.com
To: linux-arm-kernel@lists.infradead.org
Signed-off-by: Alexandre Torgue <alexandre.torgue@foss.st.com>
Two carveout reserved memory nodes each have been added for each of the
R5F remote processor devices within both the MCU and MAIN domains on the
TI J7200 EVM boards. These nodes are assigned to the respective rproc
device nodes as well. The first region will be used as the DMA pool for
the rproc device, and the second region will furnish the static carveout
regions for the firmware memory.
An additional reserved memory node is also added to reserve a portion of
the DDR memory to be used for performing inter-processor communication
between all the remote processors running RTOS. 8 MB of memory is reserved
for this purpose, and this accounts for all the vrings and vring buffers
between all the possible pairs of remote processors.
The current carveout addresses and sizes are defined statically for each
device. The R5F processors do not have an MMU, and as such require the
exact memory used by the firmwares to be set-aside. The firmware images
do not require any RSC_CARVEOUT entries in their resource tables either
to allocate the memory for firmware memory segments.
NOTE:
1. The R5F1 carveouts are needed only if the R5F cluster is running in
Split (non-LockStep) mode. The reserved memory nodes can be disabled
later on if there is no use-case defined to use the corresponding
remote processor.
2. The J7200 SoCs have no DSPs and one less R5F cluster compared to J721E
SoCs. So, while the carveout memories reserved for the R5F clusters
present on the SoC match to those on J721E, the overall memory map
reserved for firmwares is quite different.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210111184554.6748-4-s-anna@ti.com
Add the required 'mboxes' property to all the R5F processors for the
TI J7200 common processor board. The mailboxes and some shared memory
are required for running the Remote Processor Messaging (RPMsg) stack
between the host processor and each of the R5Fs. The nodes are therefore
added in the common k3-j7200-som-p0.dtsi file so that all of these can
be co-located.
The chosen sub-mailboxes match the values used in the current firmware
images. This can be changed, if needed, as per the system integration
needs after making appropriate changes on the firmware side as well.
Note that any R5F Core1 resources are needed and used only when that
R5F cluster is configured for Split-mode.
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210111184554.6748-3-s-anna@ti.com
The J7200 SoCs have 2 dual-core Arm Cortex-R5F processor (R5FSS)
subsystems/clusters. One R5F cluster is present within the MCU
domain (MCU_R5FSS0), and the other one is present within the MAIN
domain (MAIN_R5FSS0). Each of these can be configured at boot time
to be either run in a LockStep mode or in an Asymmetric Multi
Processing (AMP) fashion in Split-mode. These subsystems have 64 KB
each Tightly-Coupled Memory (TCM) internal memories for each core
split between two banks - ATCM and BTCM (further interleaved into
two banks). The TCMs of both Cores are combined in LockStep-mode
to provide a larger 128 KB of memory, but otherwise are functionally
similar to those on J721E SoCs.
Add the DT nodes for both the MCU and MAIN domain R5F cluster/subsystems,
the two R5F cores are added as child nodes to each of the R5F cluster
nodes. The clusters are configured to run in LockStep mode by default,
with the ATCMs enabled to allow the R5 cores to execute code from DDR
with boot-strapping code from ATCM. The inter-processor communication
between the main A72 cores and these processors is achieved through
shared memory and Mailboxes.
The following firmware names are used by default for these cores, and
can be overridden in a board dts file if desired:
MCU R5FSS0 Core0: j7200-mcu-r5f0_0-fw (both in LockStep and Split modes)
MCU R5FSS0 Core1: j7200-mcu-r5f0_1-fw (needed only in Split mode)
MAIN R5FSS0 Core0: j7200-main-r5f0_0-fw (both in LockStep & Split modes)
MAIN R5FSS0 Core1: j7200-main-r5f0_1-fw (needed only in Split mode)
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Nishanth Menon <nm@ti.com>
Reviewed-by: Lokesh Vutla <lokeshvutla@ti.com>
Link: https://lore.kernel.org/r/20210111184554.6748-2-s-anna@ti.com
In contrast to the H6 (and later) manuals, the A64 datasheet does not
specify any limitations in the maximum possible frequency for eMMC
controllers.
However experimentation has found that a 150 MHz limit similar to other
SoCs and also the MMC0 and MMC1 controllers on the A64 seems to exist
for the MMC2 controller.
Limit the frequency for the MMC2 controller to 150 MHz in the SoC .dtsi.
The Pinebook seems to be the an odd exception, since it apparently seems
to work with 200 MHz as well, so overwrite this in its board .dts file.
Tested on a Pine64-LTS: 200 MHz HS-200 fails, 150 MHz HS-200 works.
Fixes: 22be992fae ("arm64: allwinner: a64: Increase the MMC max frequency")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210113152630.28810-7-andre.przywara@arm.com
The H6 manual explicitly lists a frequency limit of 150 MHz for the bus
frequency of the MMC controllers. So far we had no explicit limits in the
DT, which limited eMMC to the spec defined frequencies, or whatever the
driver defines (both Linux and FreeBSD use 52 MHz here).
Put those maximum frequencies in the SoC .dtsi, to allow higher speed
modes (which still would need to be explicitly enabled, per board).
Tested with an eMMC using HS-200 on a Pine H64. Running at the spec'ed
200 MHz indeed fails with I/O errors, but 150 MHz seems to work stably.
Fixes: 8f54bd1595 ("arm64: allwinner: h6: add device tree nodes for MMC controllers")
Signed-off-by: Andre Przywara <andre.przywara@arm.com>
Acked-by: Chen-Yu Tsai <wens@csie.org>
Signed-off-by: Maxime Ripard <maxime@cerno.tech>
Link: https://lore.kernel.org/r/20210113152630.28810-6-andre.przywara@arm.com
