The XUSB pad controller is responsible for supplying power to the PLLs
used to drive the various USB, PCI and SATA pads. Move the PLL power
supplies from the PCIe and XUSB controllers to the XUSB pad controller
to make sure they are available when needed.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Starting with commit 8947e396a8 ("Documentation: dt: mtd: replace
"nor-jedec" binding with "jedec, spi-nor"") we have "jedec,spi-nor"
binding indicating support for JEDEC identification.
Use it for all flashes that are supposed to support READ ID op according
to the datasheets.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
Acked-by: Brian Norris <computersforpeace@gmail.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add a generic /memory node in each Tegra DTSI (with empty reg property,
to be overidden by each DTS) and set proper unit address for /memory
nodes to fix the DTC warnings:
arch/arm/boot/dts/tegra20-harmony.dtb: Warning (unit_address_vs_reg):
/memory: node has a reg or ranges property, but no unit name
The DTB after the change is the same as before except adding
unit-address to /memory node.
Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org>
Reviewed-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This switches a few interrupt definitions that were using either
GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW as IRQ type, which is invalid.
This is mostly a cosmetic change, that doesn't affect any driver.
Analogous to Paul's commit 38333641b6 ("ARM: tegra: nyan: Use proper
IRQ type definitions").
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
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 <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove commas from unit addresses as suggested by Rob Herring upon me
posting initial Apalis TK1 support:
http://article.gmane.org/gmane.linux.ports.tegra/26608
Please keep the remaining 0, notation on the GPU node in place as a
former mainline U-Boot version was looking for that particular notation
in order to perform required fix-ups on it.
Signed-off-by: Marcel Ziswiler <marcel.ziswiler@toradex.com>
Acked-by: Stephen Warren <swarren@nvidia.com>
Tested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
This is a collection of a few late fixes and other misc. stuff that
had dependencies on things being merged from other trees.
The Renesas R-Car power domain handling, and the Nvidia Tegra USB
support both hand notable changes that required changing the DT binding
in a way that only provides compatibility with old DT blobs on new
kernels but not vice versa. As a consequence, the DT changes
are based on top of the driver changes and are now in this branch.
For NXP i.MX and Samsung Exynos, the changes in here depend on
other changes that got merged through the clk maintainer tree.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIVAwUAV0Sse2CrR//JCVInAQJoOg//VQwAUxayKGfYVzhJjhHdYbVA9kWYczHb
wizFbF51XPylQzfGgHxEZJgdO3y2Ks54J7xaCK7oSUPEBT0rHsLQunHhq0aVQpew
1c06vEysYMkRclG7C0zN7i4gwdig+L4r6kUguTvb+nyJS3RISg0LaSoANVU65dQ5
+g4DLRrX1QlZPBXR8Fc/S1gTFXU+dO1S0oJFnK9ZZTgmsGg4GA0qC60hdsv+WeSv
uzS4FJoxSy9MzoAFqmnWIa4jBV9I1Rg5vi7dfoBbTW1XOAMpq+GVLLU+Lvso0Jqw
xWjBSmPl6l/cZ7BhpzWq8knKOsEezh5LLrVRXViVCGfTIFdlObxyHzeKcJp25V1p
mL98MBXobn9Rly9hJxyzpeNWITZ6qJYR+IQy3Lsuk5KrdZG2f4uTErtoqmYRI3Pn
vuXoi13NUeoCrHZJZ+fNUGwx5a5/hgUQXP5u+98uucQSqIVxe0cGnQVnFm84X81r
Sj/dXxFlFBZfqfE8rf1cFd+YEbKtpF13vEURAQWrnEzBmJSTu7Cp8qdA5hX5CeK4
DW9bsu5hkWwnzoC2Ox/ZQVms4aI3q8s2xuu28GEJJdCE2IUiSnag/5vhGBzd4dTm
9R69RhE9y4EOhw+0z1O0LfoKoo6YyUQa+OUNVIwEfFjcCdZiMQIdZWi2PLv4jeAR
jBBbpcWtHLo=
=I0Be
-----END PGP SIGNATURE-----
Merge tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC late DT updates from Arnd Bergmann:
"This is a collection of a few late fixes and other misc stuff that had
dependencies on things being merged from other trees.
The Renesas R-Car power domain handling, and the Nvidia Tegra USB
support both hand notable changes that required changing the DT
binding in a way that only provides compatibility with old DT blobs on
new kernels but not vice versa. As a consequence, the DT changes are
based on top of the driver changes and are now in this branch.
For NXP i.MX and Samsung Exynos, the changes in here depend on other
changes that got merged through the clk maintainer tree"
* tag 'armsoc-late' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (35 commits)
ARM: dts: exynos: Add support of Bus frequency using VDD_INT for exynos5422-odroidxu3
ARM: dts: exynos: Add bus nodes using VDD_INT for Exynos542x SoC
ARM: dts: exynos: Add NoC Probe dt node for Exynos542x SoC
ARM: dts: exynos: Add support of bus frequency for exynos4412-trats/odroidu3
ARM: dts: exynos: Expand the voltage range of buck1/3 regulator for exynos4412-odroidu3
ARM: dts: exynos: Add support of bus frequency using VDD_INT for exynos3250-rinato
ARM: dts: exynos: Add exynos4412-ppmu-common dtsi to delete duplicate PPMU nodes
ARM: dts: exynos: Add bus nodes using VDD_MIF for Exynos4210
ARM: dts: exynos: Add bus nodes using VDD_INT for Exynos4x12
ARM: dts: exynos: Add bus nodes using VDD_MIF for Exynos4x12
ARM: dts: exynos: Add bus nodes using VDD_INT for Exynos3250
ARM: dts: exynos: Add DMC bus frequency for exynos3250-rinato/monk
ARM: dts: exynos: Add DMC bus node for Exynos3250
ARM: tegra: Enable XUSB on Nyan
ARM: tegra: Enable XUSB on Jetson TK1
ARM: tegra: Enable XUSB on Venice2
ARM: tegra: Add Tegra124 XUSB controller
ARM: tegra: Move Tegra124 to the new XUSB pad controller binding
ARM: dts: r8a7794: Use SYSC "always-on" PM Domain
ARM: dts: r8a7793: Use SYSC "always-on" PM Domain
...
Add XUSB pad controller and XUSB controller device tree nodes and enable
them with a configuration for the Venice2 board.
Signed-off-by: Thierry Reding <treding@nvidia.com>
For Tegra boards, the device-tree alias serial0 is used for the console
and so add the stdout-path information so that the console no longer
needs to be passed via the kernel boot parameters.
This has been tested on boards, tegra20-trimslice, tegra30-beaver,
tegra114-dalmore and tegra124-jetson-tk1.
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Though the keyboard and other driver will continue to support the legacy
"gpio-key,wakeup", "nvidia,wakeup-source" boolean property to enable the
wakeup source, "wakeup-source" is the new standard binding.
This patch replaces all the legacy wakeup properties with the unified
"wakeup-source" property in order to avoid any further copy-paste
duplication.
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Thierry Reding <thierry.reding@gmail.com>
Cc: Alexandre Courbot <gnurou@gmail.com>
Cc: linux-tegra@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Add the device-tree node for the GK20A GPU and leave it disabled.
It is the responsibility of the bootloader to enable it if the
VPR registers have been programmed such that the GPU can operate.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
eMMC is soldered on to the board, and as such isn't removable. Mark it
as non-removable so that operating systems can treat it appropriately.
Signed-off-by: Thierry Reding <treding@nvidia.com>
There are general changes pending to make the /aliases/serial* entries
number the serial ports on the system. On Tegra, so far the ports have
been just numbered dynamically as they are configured so that makes them
change.
To avoid this, add specific aliases per board to keep the old numbers.
This allows us to change the numbering by default on future SoCs while
keeping the numbering on existing boards.
Signed-off-by: Olof Johansson <olof@lixom.net>
Signed-off-by: Thierry Reding <treding@nvidia.com>
The defined mechanism for programming the Tegra pinmux is to perform all
of the following at once in order, before using any I/O controller that
is affected by the pinmux:
- Set the CLAMP_INPUTS_WHEN_TRISTATED PMC register bit.
- Set up any GPIO pins to their "initial" state.
- Program all pinmux settings in one go.
Other methods such as:
- Not setting CLAMP_INPUTS_WHEN_TRISTATED.
- Not setting GPIOs to their "initial" state before programming the
pinmux settings of the related pin, in particular the mux function.
- Not programming the entire pinmux at once, in order to avoid
possible conflicting settings.
... are not qualified or supported by NVIDIA ASIC/syseng. They could
cause glitches or undesired output levels on some pins, or controller
malfunction.
While we've been getting away with doing something different on many
Tegra boards without issue, I believe we've just been getting lucky.
I'd like to switch all Tegra124 systems to the correct scheme now so
they provide the right example to follow, and require that any new
boards we support upstream work in the same fashion.
While it would be nice to update boards containing older SoCs for
consistency, I don't anticipate doing so. It's too much churn to change
at this time. At least with all Tegra124 boards converted, the most
recent boards provide the correct example.
Since the bootloader needs to reprogram the pinmux to access certain
peripherals, it must program the entire pinmux due to the supported
rules above. As such, there is no need to program any part of the pinmux
from the kernel, unless dynamic pinmuxing is used. Given this, we couuld
simply remove the pinmux "default" state from the DT entirely. However,
some bootloaders parse the DT to perform their initial pinmux setup, so
it's useful to keep the pinmux data in DT. To allow this while avoiding
redundant work in the kernel, rename the "default" state to "boot". The
kernel won't apply this, but bootloaders can still look for this state
name and apply it. Note however that the DT provides zero information
about the required initial GPIO setup, so bootloaders using this approach
are not likely to operate correctly without an additional GPIO
initialization table somewhere. Previous discussions on the DT mailing
list have rejected adding such a table to DT...
The following U-Boot commits fully initialize the pinmux:
Jetson TK1: 4ff213b8e478 ARM: tegra: clamp inputs on Jetson TK1
Venice2: 3365479ce78a ARM: tegra: Venice2 pinmux spreadsheet updates
Both are part of U-Boot v2014.07 and later.
Without those commits, the only fallout I see from this change is that
HDMI on Venice2 no longer works. Given the very small user-base of this
platform, I feel that requiring a bootloader update is reasonable.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
These labels will be used by other boards in addition to Venice2, move
them to tegra124.dtsi so they are defined in a common place.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Venice2 contains an Atmel MXT touchpad. Add an I2C node for it to DT.
The Linux driver doesn't quite work on this platform yet, but adding
the DT node causes no issues, and will allow the device to work once
the driver is fixed.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
The property for enabling external rail control on the AS3722 is
ams,ext-control, not ams,external-control. Since the external rail
control property was previously being ignored, LP1 suspend on these
boards wasn't actually turning the CPU rail off at all.
Signed-off-by: Tuomas Tynkkynen <ttynkkynen@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Turn on the HDA controller in Venice2, it is used for HDMI audio.
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This adds the EC i2c tunnel (and devices under it) to the
tegra124-venice2 device tree.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Tested-by: Andrew Bresticker <abrestic@chromium.org>
Tested-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Venice2 can detect write-protect on the SD card. Add the required
DT entries to allow this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
[swarren: fixed GPIO polarity per Thierry's testing]
Tested-by: Thierry Reding <treding@nvidia.com>
Add HDMI +5V, VDD and PLL regulators and enable the DDC I2C controller.
Enable the HDMI device, provide the power supplies as well as the DDC
adapter and use the standard pin (PN7) for hotplug detection.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
VDDIO_SDMMC3 is the VQMMC (I/O) supply, not the VMMC (core) supply,
for the SD slot on Venice2.
Signed-off-by: Andrew Bresticker <abrestic@chromium.org>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This regulator supplies power to pretty much everything on the board, so
it doesn't make sense to allow it to turn off. Mark it boot-on and
always-on so it doesn't get turned off. Without this, I see issues with
the eMMC device; it can't be correctly detected during boot.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
A large part of the arm-soc patches are nowadays DT changes, adding support
for new SoCs, boards and devices without changing kernel source. The plan
is still to move the devicetree files out of the kernel tree and reduce
the amount of churn going on here, but we keep finding reasons to delay
doing that.
Changes are really all over the place, with little sticking out particularly.
We have contributions from a total of 116 people in this branch.
Unfortunately, the size of this branch also causes a significant number
of conflicts at the moment, typically when subsystem maintainers merge
patches that change the driver at the same time as the dts files. In
most cases this could be avoided because the dts changes are supposed
to be compatible in both ways, and we are asking everyone to send ARM
dts changes through our tree only.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIVAwUAUz/11WCrR//JCVInAQIIyRAA0DjdNNQ/A4G2i1nZCiTFH6a4oZy4JarN
ATVPkW/V8avhh+yVNe5FWA44Xe6CDC5TXwMaIsbK+w3Iclj3fplh/MsBkQ9ZT9Sl
LAjJoOjuYucCeDy0WLVioRKZ4PJEDoCu/oZTauIMnmWCOCRxLYpOM3FkAT9oN/Ti
lswpTSLiV1/U3ZSI4M3qn+Sx1VJL8c/hAIWbvf5if2diYkWPk3VOSKyxmD9zLWdD
Iqtb79J+ETVeOIM4sHnx79cG4ZCdpOfRAl7qx6hkJu0YATXESxWhpXVE2McTJuzM
qHKsRRNSfsfSWPeF4angll9o06X/qgdT6C4P2dfH49lGeG7llOttw3OaCx3hWCTe
U5bt26qtbwG2ZbzocaqvideP+rbpQrCH2vdO1embPv5Lu6peMoBWjxy6twSVXJBG
LIymJ0IbiGYxL7BReGqRXt6ehy0BDWBeTSTdsGqgEl2TnxHuS/kgGfJc4D5riiEk
aRPVq10p/k+yo4BZtq2GqXIOG6cqkIQ5lhl5Tg9+MfUlquAONqJP70FgRJDBIw9L
9uJp71bgSsA6eYg2tXoqJtpdjKplDWavgtACzIkFg2qFLyYmKvx+F0AXbeTIsrri
/mIchTyG+dgiIjWvj/Xsf7jhrdzRcl3uKsJwFmk927pIsh24HV8T+LKgHrf+sVcO
qEsEnKGYA6s=
=zl/N
-----END PGP SIGNATURE-----
Merge tag 'dt-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc
Pull ARM SoC device tree changes from Arnd Bergmann:
"A large part of the arm-soc patches are nowadays DT changes, adding
support for new SoCs, boards and devices without changing kernel
source. The plan is still to move the devicetree files out of the
kernel tree and reduce the amount of churn going on here, but we keep
finding reasons to delay doing that.
Changes are really all over the place, with little sticking out
particularly. We have contributions from a total of 116 people in
this branch.
Unfortunately, the size of this branch also causes a significant
number of conflicts at the moment, typically when subsystem
maintainers merge patches that change the driver at the same time as
the dts files. In most cases this could be avoided because the dts
changes are supposed to be compatible in both ways, and we are asking
everyone to send ARM dts changes through our tree only"
* tag 'dt-3.15' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc: (541 commits)
dts: stmmac: Document the clocks property in the stmmac base document
dts: socfpga: Add DTS entry for adding the stmmac glue layer for stmmac.
ARM: STi: stih41x: Add support for the FSM Serial Flash Controller
ARM: STi: stih416: Add support for the FSM Serial Flash Controller
ARM: tegra: fix Dalmore pinctrl configuration
ARM: dts: keystone: use common "ti,keystone" compatible instead of -evm
ARM: dts: k2hk-evm: set ubifs partition size for 512M NAND
ARM: dts: Build all keystone dt blobs
ARM: dts: keystone: Fix control register range for clktsip
ARM: dts: keystone: Fix domain register range for clkfftc1
ARM: dts: bcm28155-ap: leave camldo1 on to fix reboot
ARM: dts: add bcm590xx pmu support and enable for bcm28155-ap
ARM: dts: bcm21664: Add device tree files.
ARM: DT: bcm21664: Device tree bindings
ARM: efm32: properly namespace i2c location property
ARM: efm32: fix unit address part in USART2 device nodes' names
ARM: mvebu: Enable NAND controller in Armada 385-DB
ARM: mvebu: Add support for NAND controller in Armada 38x SoC
ARM: mvebu: Add the Core Divider clock to Armada 38x SoCs
ARM: mvebu: Add a 2 GHz fixed-clock on Armada 38x SoCs
...
Neither Tegra114 nor Tegra124 allow "low power mode" to be configured
on SDIO1 or SDIO3 drive groups. Remove the attempt to configure that
option from the Dalmore and Venice2 DTs.
The Venice2 DT contained duplicate configurations for most sdmmc1_*
pins. Remove the duplicate pins from one of the nodes, and fix the
configuration since the remaining clk pin is output-only.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Tegra124 can support 4GB of RAM. With that much RAM (plus some memory-
mapped IO peripherals), more than 32-bits of physical address space is
required. Hence, convert all Tegra124 DTs to use 2 DT cells for address
space.
(I think this was suggested by Olof Johansson, but I'm not 100% sure)
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Device tree node name should reflect the kind of device rather than the
specific name of the device.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Equal signs should always be preceded and followed by a single space in
device tree files.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
USB1 and USB3 are routed to two external connectors, while USB2 is used
for the integrated webcam.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Venice2 has a 12.9" (2560x1700) panel connected to the eDP output of the
Tegra124. The panel has an EDID to describe the video timings but needs
a few extra nodes to get the backlight to come up.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
The SDMMC3 interface is supplied with 1.8V by the PMICs LDO6.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Some of the regulators and the relationships to other regulators are
wrong. This commit attempts to rectify this by making them more similar
to what the schematics contain. This starts by adding a +VDD_MUX supply
that represents the 12V input and derives the main +3.3V_SYS and +5V_SYS
supplies from that. The majority of the other regulators derive from one
of those three.
While at it, rename the regulators to match the names in the schematics
to make them easier to match up.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Both USB_VBUS_EN0 and USB_VBUS_EN1 are configured the same way, so they
can be combined into a single node. While at it, don't configure them as
pull-up since they already have external pull-ups. Also U-Boot doesn't
configure them as pull-up either.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Venice2 contains an SPI Flash chip, which contains the bootloader.
Add this to the DT, so the kernel can access it.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Add system-power-controller property to system PMIC, ams AS3722,
node to enable power off functionality through PMIC.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Contrary to the rest of the keyboard, which is connected to the ChromeOS
embedded controller, the power key is hooked up to a GPIO. Add a device
tree node to handle it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
The keyboard on Venice2 is attached to the ChromeOS embedded controller.
Add the corresponding device tree nodes and use the MATRIX_KEY define to
encode keycodes.
Signed-off-by: Rhyland Klein <rklein@nvidia.com>
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This ensures that the PMIC RTC provides the system time, rather than
the on-SoC RTC, which is not battery-backed.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Add ams AS3722 entry for gpio/pincontrol and regulators
to venice2 DT.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Compare the initial population of default pinmux configuration of Venice2
with the chrome branch and add/fix the missing configurations.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
This pin needs to be configured in pull-down, non-tristate mode in order
for the backlight to work correctly.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Other boards use PULL_NONE for their debug UART pins, and without this
change, the board doesn't accept any serial input.
Don't set the I2S port pins to tristate mode, or no audio signal will
be sent out.
Fixes: 605ae5804385 ("ARM: tegra: add default pinctrl nodes for Venice2")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Add the default pinmux configuration for the Tegra124 based
Venice2 platform.
Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Subsequent patches will need to reference a PWM channel for backlight
support, so enable the PWM device and assign a label to it.
Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Venice2 uses the MAX98090 audio CODEC, and supports built-in speakers,
and a combo headphones/microphone jack. Add a top-level sound card node
to represent this.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Enable all the I2C controllers that are wired up on Venice2. I don't
know the correct I2C bus clock rates, so set them all to a conservative
100KHz for now.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Tegra124 has 4 MMC controllers just like previous versions of the SoC.
Note that there are some non-backwards-compatible HW differences, and
hence a new DT compatible value must be used to describe the HW.
Also enable the relevant controllers in the Venice2 board DT.
power-gpios property suggested by Thierry Reding.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
Thierry Reding