AuxXxilium/linux_dsm_epyc7002
1
0
Fork 0
mirror of https://github.com/AuxXxilium/linux_dsm_epyc7002.git synced 2024-12-22 16:23:29 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
3d2cbb6448
linux_dsm_epyc7002/arch/arm/boot/dts/tegra20-paz00.dts

680 lines
16 KiB
Plaintext
Raw Normal View History

License cleanup: add SPDX GPL-2.0 license identifier to files with no license 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>
2017-11-01 21:07:57 +07:00
// SPDX-License-Identifier: GPL-2.0
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
/dts-v1/;
ARM: tegra: convert device tree files to use key defines Use key code macros for all key code refernced for keys. For tegra20-seaboard.dts and tegra20-harmony.dts: The key comment for key (16th row and 1st column) is KEY_KPSLASH but code is 0x004e which is the key code for KEY_KPPLUS. As there other key exist with KY_KPPLUS, I am assuming key code is wrong and comment is fine. With this assumption, I am keeping the key code as KEY_KPSLASH. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-02 20:09:57 +07:00
#include <dt-bindings/input/input.h>
ARM: tegra: use #include for all device trees Replace /include/ (dtc) with #include (C pre-processor) for all Tegra DT files, so that gcc -E handles the entire include tree, and hence any of those files can #include some other file e.g. for constant definitions. This allows future use of #defines and header files in order to define names for various constants, such as the IDs and flags in GPIO specifiers. Use of those features will increase the readability of the device tree files. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-10-18 05:38:21 +07:00
#include "tegra20.dtsi"
ARM: tegra: paz00: Add CPU Operating Performance Points Utilize common Tegra20 CPU OPP table. CPU DVFS is available now on AC100. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:13 +07:00
#include "tegra20-cpu-opp.dtsi"
#include "tegra20-cpu-opp-microvolt.dtsi"
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
/ {
model = "Toshiba AC100 / Dynabook AZ";
compatible = "compal,paz00", "nvidia,tegra20";
ARM: tegra: set up /aliases entries for RTCs This ensures that the PMIC RTC provides the system time, rather than the on-SoC RTC, which is not battery-backed. tegra124-venice2.dts isn't touched yet since we haven't added any off- SoC RTC device to its device tree. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-10 04:43:59 +07:00
aliases {
rtc0 = "/i2c@7000d000/tps6586x@34";
rtc1 = "/rtc@7000e000";
ARM: dts: tegra: move serial aliases to per-board 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>
2014-11-12 03:49:30 +07:00
serial0 = &uarta;
serial1 = &uartc;
ARM: tegra: set up /aliases entries for RTCs This ensures that the PMIC RTC provides the system time, rather than the on-SoC RTC, which is not battery-backed. tegra124-venice2.dts isn't touched yet since we haven't added any off- SoC RTC device to its device tree. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-10 04:43:59 +07:00
};
ARM: tegra: Add stdout-path for various boards 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>
2016-02-09 20:51:59 +07:00
chosen {
stdout-path = "serial0:115200n8";
};
ARM: tegra: Fix unit_address_vs_reg DTC warnings for /memory 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>
2018-07-09 23:05:17 +07:00
memory@0 {
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
reg = <0x00000000 0x20000000>;
};
ARM: tegra: add missing unit addresses to DT DT node names should include a unit address iff the node has a reg property. For Tegra DTs at least, we were previously applying a different rule, namely that node names only needed to include a unit address if it was required to make the node name unique. Consequently, many unit addresses are missing. Add them. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-11-26 07:53:16 +07:00
host1x@50000000 {
ARM: tegra: paz00: Add LVDS support to device tree Add backlight and panel nodes for the PAZ00 TFT LCD panel. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-22 03:38:13 +07:00
dc@54200000 {
rgb {
status = "okay";
nvidia,panel = <&panel>;
};
};
ARM: tegra: add missing unit addresses to DT DT node names should include a unit address iff the node has a reg property. For Tegra DTs at least, we were previously applying a different rule, namely that node names only needed to include a unit address if it was required to make the node name unique. Consequently, many unit addresses are missing. Add them. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-11-26 07:53:16 +07:00
hdmi@54280000 {
ARM: tegra: paz00: enable HDMI port Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-01-03 04:53:22 +07:00
status = "okay";
vdd-supply = <&hdmi_vdd_reg>;
pll-supply = <&hdmi_pll_reg>;
nvidia,ddc-i2c-bus = <&hdmi_ddc>;
ARM: tegra: convert device tree files to use GPIO defines Use TEGRA_GPIO() macro to name all GPIOs referenced by GPIO properties, and some interrupts properties. Use standard GPIO flag defines too. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-13 07:25:15 +07:00
nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7)
GPIO_ACTIVE_HIGH>;
ARM: tegra: paz00: enable HDMI port Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-01-03 04:53:22 +07:00
};
};
ARM: tegra: add missing unit addresses to DT DT node names should include a unit address iff the node has a reg property. For Tegra DTs at least, we were previously applying a different rule, namely that node names only needed to include a unit address if it was required to make the node name unique. Consequently, many unit addresses are missing. Add them. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-11-26 07:53:16 +07:00
pinmux@70000014 {
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
pinctrl-names = "default";
pinctrl-0 = <&state_default>;
state_default: pinmux {
ata {
nvidia,pins = "ata", "atc", "atd", "ate",
"dap2", "gmb", "gmc", "gmd", "spia",
"spib", "spic", "spid", "spie";
nvidia,function = "gmi";
};
atb {
nvidia,pins = "atb", "gma", "gme";
nvidia,function = "sdio4";
};
cdev1 {
nvidia,pins = "cdev1";
nvidia,function = "plla_out";
};
cdev2 {
nvidia,pins = "cdev2";
nvidia,function = "pllp_out4";
};
crtp {
nvidia,pins = "crtp";
nvidia,function = "crt";
};
csus {
nvidia,pins = "csus";
nvidia,function = "pllc_out1";
};
dap1 {
nvidia,pins = "dap1";
nvidia,function = "dap1";
};
dap3 {
nvidia,pins = "dap3";
nvidia,function = "dap3";
};
dap4 {
nvidia,pins = "dap4";
nvidia,function = "dap4";
};
ddc {
nvidia,pins = "ddc";
nvidia,function = "i2c2";
};
dta {
nvidia,pins = "dta", "dtb", "dtc", "dtd", "dte";
nvidia,function = "rsvd1";
};
dtf {
nvidia,pins = "dtf";
nvidia,function = "i2c3";
};
gpu {
nvidia,pins = "gpu", "sdb", "sdd";
nvidia,function = "pwm";
};
gpu7 {
nvidia,pins = "gpu7";
nvidia,function = "rtck";
};
gpv {
nvidia,pins = "gpv", "slxa", "slxk";
nvidia,function = "pcie";
};
hdint {
nvidia,pins = "hdint", "pta";
nvidia,function = "hdmi";
};
i2cp {
nvidia,pins = "i2cp";
nvidia,function = "i2cp";
};
irrx {
nvidia,pins = "irrx", "irtx";
nvidia,function = "uarta";
};
kbca {
nvidia,pins = "kbca", "kbcc", "kbce", "kbcf";
nvidia,function = "kbc";
};
kbcb {
nvidia,pins = "kbcb", "kbcd";
nvidia,function = "sdio2";
};
lcsn {
nvidia,pins = "lcsn", "ld0", "ld1", "ld2",
"ld3", "ld4", "ld5", "ld6", "ld7",
"ld8", "ld9", "ld10", "ld11", "ld12",
"ld13", "ld14", "ld15", "ld16", "ld17",
"ldc", "ldi", "lhp0", "lhp1", "lhp2",
"lhs", "lm0", "lm1", "lpp", "lpw0",
"lpw1", "lpw2", "lsc0", "lsc1", "lsck",
"lsda", "lsdi", "lspi", "lvp0", "lvp1",
"lvs";
nvidia,function = "displaya";
};
owc {
nvidia,pins = "owc";
nvidia,function = "owr";
};
pmc {
nvidia,pins = "pmc";
nvidia,function = "pwr_on";
};
rm {
nvidia,pins = "rm";
nvidia,function = "i2c1";
};
sdc {
nvidia,pins = "sdc";
nvidia,function = "twc";
};
sdio1 {
nvidia,pins = "sdio1";
nvidia,function = "sdio1";
};
slxc {
nvidia,pins = "slxc", "slxd";
nvidia,function = "spi4";
};
spdi {
nvidia,pins = "spdi", "spdo";
nvidia,function = "rsvd2";
};
spif {
nvidia,pins = "spif", "uac";
nvidia,function = "rsvd4";
};
spig {
nvidia,pins = "spig", "spih";
nvidia,function = "spi2_alt";
};
uaa {
nvidia,pins = "uaa", "uab", "uda";
nvidia,function = "ulpi";
};
uad {
nvidia,pins = "uad";
nvidia,function = "spdif";
};
uca {
nvidia,pins = "uca", "ucb";
nvidia,function = "uartc";
};
conf_ata {
nvidia,pins = "ata", "atb", "atc", "atd", "ate",
ARM: dt: tegra: pinmux changes for USB ULPI Ensure that the USB ULPI signals are not tri-stated, and have no pull- up or pull-down. Ensure that the pingroup hosting the USB ULPI reset signal (GPIO PV0 or PV1 depending on the board, so UAC) is not tri-stated, and has no pull- up or pull-down. This change appears larger than it is due to the grouping and sorting of the pin configuration data. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-04-14 05:35:20 +07:00
"cdev1", "cdev2", "dap1", "dap2", "dtf",
"gma", "gmb", "gmc", "gmd", "gme",
"gpu", "gpu7", "gpv", "i2cp", "pta",
"rm", "sdio1", "slxk", "spdo", "uac",
"uda";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_ck32 {
nvidia,pins = "ck32", "ddrc", "pmca", "pmcb",
"pmcc", "pmcd", "pmce", "xm2c", "xm2d";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_crtp {
nvidia,pins = "crtp", "dap3", "dap4", "dtb",
"dtc", "dte", "slxa", "slxc", "slxd",
"spdi";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,pull = <TEGRA_PIN_PULL_NONE>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_csus {
nvidia,pins = "csus", "spia", "spib", "spid",
"spif";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_ddc {
nvidia,pins = "ddc", "irrx", "irtx", "kbca",
"kbcb", "kbcc", "kbcd", "kbce", "kbcf",
"spic", "spig", "uaa", "uab";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_DISABLE>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_dta {
nvidia,pins = "dta", "dtd", "owc", "sdc", "sdd",
"spie", "spih", "uad", "uca", "ucb";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,pull = <TEGRA_PIN_PULL_UP>;
nvidia,tristate = <TEGRA_PIN_ENABLE>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_hdint {
nvidia,pins = "hdint", "ld0", "ld1", "ld2",
"ld3", "ld4", "ld5", "ld6", "ld7",
"ld8", "ld9", "ld10", "ld11", "ld12",
"ld13", "ld14", "ld15", "ld16", "ld17",
"ldc", "ldi", "lhs", "lsc0", "lspi",
"lvs", "pmc";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,tristate = <TEGRA_PIN_DISABLE>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_lc {
nvidia,pins = "lc", "ls";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,pull = <TEGRA_PIN_PULL_UP>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_lcsn {
nvidia,pins = "lcsn", "lhp0", "lhp1", "lhp2",
"lm0", "lm1", "lpp", "lpw0", "lpw1",
"lpw2", "lsc1", "lsck", "lsda", "lsdi",
"lvp0", "lvp1", "sdb";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,tristate = <TEGRA_PIN_ENABLE>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
conf_ld17_0 {
nvidia,pins = "ld17_0", "ld19_18", "ld21_20",
"ld23_22";
ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines Use Tegra pinconrol dt-binding macro to set the values of different pinmux properties of Tegra20 platforms. Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-05 17:44:08 +07:00
nvidia,pull = <TEGRA_PIN_PULL_DOWN>;
ARM: dt: tegra20: add pinmux to device tree This adds a complete pinmux configuration to all Tegra20 device tree files. This allows removal of board-dt-tegra20.c's use of the pinmux board files, and the special device tree handling in board-pinmux.c. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Olof Johansson <olof@lixom.net>
2012-03-16 05:27:36 +07:00
};
};
};
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
i2s@70002800 {
status = "okay";
ARM: dt: tegra: sort nodes based on bus order Sort the nodes according to the following rules: * First, any overrides for properties or nodes created by included files, in the order they appeared in the include file. * Second, any nodes with a reg property, in numerical order. * Third, any nodes without a reg property, in alphabetical order of node name. The second sorting rule at least will probably help if/when we need to explicitly insert nodes for the various busses in Tegra; that will just be an indentation change rather than also a node re-ordering. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:03:26 +07:00
};
serial@70006000 {
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
ARM: dt: tegra: sort nodes based on bus order Sort the nodes according to the following rules: * First, any overrides for properties or nodes created by included files, in the order they appeared in the include file. * Second, any nodes with a reg property, in numerical order. * Third, any nodes without a reg property, in alphabetical order of node name. The second sorting rule at least will probably help if/when we need to explicitly insert nodes for the various busses in Tegra; that will just be an indentation change rather than also a node re-ordering. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:03:26 +07:00
};
serial@70006200 {
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
ARM: dt: tegra: sort nodes based on bus order Sort the nodes according to the following rules: * First, any overrides for properties or nodes created by included files, in the order they appeared in the include file. * Second, any nodes with a reg property, in numerical order. * Third, any nodes without a reg property, in alphabetical order of node name. The second sorting rule at least will probably help if/when we need to explicitly insert nodes for the various busses in Tegra; that will just be an indentation change rather than also a node re-ordering. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:03:26 +07:00
};
ARM: tegra: paz00: Add LVDS support to device tree Add backlight and panel nodes for the PAZ00 TFT LCD panel. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-22 03:38:13 +07:00
pwm: pwm@7000a000 {
status = "okay";
};
lvds_ddc: i2c@7000c000 {
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
clock-frequency = <400000>;
ARM: dt: tegra: Enable device tree audio codec on PAZ00 board. This patch adds initial device tree support of ALC5632 sound codec and machine driver for PAZ00 board. The implementation is based on the WM8903 codec. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Leon Romanovsky <leon@leon.nu> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-02-03 03:13:35 +07:00
alc5632: alc5632@1e {
compatible = "realtek,alc5632";
reg = <0x1e>;
gpio-controller;
#gpio-cells = <2>;
};
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
};
ARM: tegra: paz00: enable HDMI port Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-01-03 04:53:22 +07:00
hdmi_ddc: i2c@7000c400 {
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
ARM: tegra: paz00: enable HDMI port Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-01-03 04:53:22 +07:00
clock-frequency = <100000>;
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
};
ARM: tegra: add missing unit addresses to DT DT node names should include a unit address iff the node has a reg property. For Tegra DTs at least, we were previously applying a different rule, namely that node names only needed to include a unit address if it was required to make the node name unique. Consequently, many unit addresses are missing. Add them. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-11-26 07:53:16 +07:00
nvec@7000c500 {
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
compatible = "nvidia,nvec";
ARM: dt: tegra: consistenly use lower-case for hex constants Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 05:28:59 +07:00
reg = <0x7000c500 0x100>;
ARM: tegra: convert device tree files to use IRQ defines Use the GIC and standard IRQ binding defines in all IRQ specifiers. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-14 02:51:51 +07:00
interrupts = <GIC_SPI 92 IRQ_TYPE_LEVEL_HIGH>;
ARM: dt: tegra: consistent basic property ordering Put properties in order compatible, reg, interrupts, then anything else the node has. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:12:52 +07:00
#address-cells = <1>;
#size-cells = <0>;
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
clock-frequency = <80000>;
ARM: tegra: convert device tree files to use GPIO defines Use TEGRA_GPIO() macro to name all GPIOs referenced by GPIO properties, and some interrupts properties. Use standard GPIO flag defines too. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-13 07:25:15 +07:00
request-gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_HIGH>;
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
slave-addr = <138>;
ARM: tegra20: convert device tree files to use CLK defines Use the Tegra20 CAR binding header (tegra20-car.h) to replace magic numbers in the device tree. For example, - clocks = <&tegra_car 28>; + clocks = <&tegra_car CLK_HOST1X>; Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> [swarren, updated since tegra20-car.h moved for consistency] Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-05-22 23:45:32 +07:00
clocks = <&tegra_car TEGRA20_CLK_I2C3>,
ARM: tegra: tegra20: Fix mixed tabs-spaces indentation Fix indentation and alignment when spaces were used instead of tabs. This fixes checkpatch errors like: ERROR: code indent should use tabs where possible #306: FILE: arch/arm/boot/dts/tegra20-paz00.dts:306: +^I^I <&tegra_car TEGRA20_CLK_PLL_P_OUT3>;$ Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-08-31 00:21:53 +07:00
<&tegra_car TEGRA20_CLK_PLL_P_OUT3>;
ARM: tegra: paz00: add clock information to DT Add clock i2c clock information to device node. Signed-off-by: Prashant Gaikwad <pgaikwad@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-01-11 15:01:23 +07:00
clock-names = "div-clk", "fast-clk";
ARM: tegra: update DT files to add reset properties An earlier patch updated the Tegra DT bindings to require resets and reset-names properties to be filled in. This patch updates the DT files to include those properties. Note that any legacy clocks and clock-names entries that are replaced by reset properties are not yet removed; the drivers must be updated to use the new resets and reset-names properties first. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-11-07 04:01:16 +07:00
resets = <&tegra_car 67>;
reset-names = "i2c";
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
};
ARM: dts: tegra20: paz00: Add memory timings PAZ00 board has two variants of DDR2 SDRAM devices for External Memory: one is Hynix HY5PS1G831CLFP-Y5 and the other is Micron MT47H128M8CF-25:H. The Micron variant doesn't have official timings in the wild, hence only timings for the Hynix are added. The memory frequency-scaling was tested using the Tegra20 devfreq driver. Tested-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-12-19 01:59:57 +07:00
memory-controller@7000f400 {
nvidia,use-ram-code;
emc-tables@hynix {
nvidia,ram-code = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
emc-table@166500 {
reg = <166500>;
compatible = "nvidia,tegra20-emc-table";
clock-frequency = <166500>;
nvidia,emc-registers = <0x0000000a 0x00000016
0x00000008 0x00000003 0x00000004 0x00000004
0x00000002 0x0000000c 0x00000003 0x00000003
0x00000002 0x00000001 0x00000004 0x00000005
0x00000004 0x00000009 0x0000000d 0x000004df
0x00000000 0x00000003 0x00000003 0x00000003
0x00000003 0x00000001 0x0000000a 0x000000c8
0x00000003 0x00000006 0x00000004 0x00000008
0x00000002 0x00000000 0x00000000 0x00000002
0x00000000 0x00000000 0x00000083 0xe03b0323
0x007fe010 0x00001414 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000>;
};
emc-table@333000 {
reg = <333000>;
compatible = "nvidia,tegra20-emc-table";
clock-frequency = <333000>;
nvidia,emc-registers = <0x00000018 0x00000033
0x00000012 0x00000004 0x00000004 0x00000005
0x00000003 0x0000000c 0x00000006 0x00000006
0x00000003 0x00000001 0x00000004 0x00000005
0x00000004 0x00000009 0x0000000d 0x00000bff
0x00000000 0x00000003 0x00000003 0x00000006
0x00000006 0x00000001 0x00000011 0x000000c8
0x00000003 0x0000000e 0x00000007 0x00000008
0x00000002 0x00000000 0x00000000 0x00000002
0x00000000 0x00000000 0x00000083 0xf0440303
0x007fe010 0x00001414 0x00000000 0x00000000
0x00000000 0x00000000 0x00000000 0x00000000>;
};
};
};
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
i2c@7000d000 {
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
clock-frequency = <400000>;
ARM: dt: tegra: add ADT7461 temperature sensor to paz00 device tree Add the ADT7461 temperature monitoring IC which is connected via the DVC controller. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-02-01 01:53:21 +07:00
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
pmic: tps6586x@34 {
compatible = "ti,tps6586x";
reg = <0x34>;
ARM: tegra: convert device tree files to use IRQ defines Use the GIC and standard IRQ binding defines in all IRQ specifiers. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-14 02:51:51 +07:00
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
#gpio-cells = <2>;
gpio-controller;
sys-supply = <&p5valw_reg>;
vin-sm0-supply = <&sys_reg>;
vin-sm1-supply = <&sys_reg>;
vin-sm2-supply = <&sys_reg>;
vinldo01-supply = <&sm2_reg>;
vinldo23-supply = <&sm2_reg>;
vinldo4-supply = <&sm2_reg>;
vinldo678-supply = <&sm2_reg>;
vinldo9-supply = <&sm2_reg>;
regulators {
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
sys_reg: sys {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "vdd_sys";
regulator-always-on;
};
ARM: tegra: paz00: Set up voltage regulators for DVFS Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators. Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:12 +07:00
core_vdd_reg: sm0 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+1.2vs_sm0,vdd_core";
regulator-min-microvolt = <1200000>;
ARM: tegra: paz00: Set up voltage regulators for DVFS Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators. Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:12 +07:00
regulator-max-microvolt = <1225000>;
regulator-coupled-with = <&rtc_vdd_reg &cpu_vdd_reg>;
regulator-coupled-max-spread = <170000 450000>;
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-always-on;
ARM: tegra: paz00: Set up voltage regulators for DVFS Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators. Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:12 +07:00
nvidia,tegra-core-regulator;
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
};
ARM: tegra: paz00: Set up voltage regulators for DVFS Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators. Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:12 +07:00
cpu_vdd_reg: sm1 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+1.0vs_sm1,vdd_cpu";
ARM: tegra: paz00: Set up voltage regulators for DVFS Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators. Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:12 +07:00
regulator-min-microvolt = <750000>;
regulator-max-microvolt = <1100000>;
regulator-coupled-with = <&core_vdd_reg &rtc_vdd_reg>;
regulator-coupled-max-spread = <450000 450000>;
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-always-on;
ARM: tegra: paz00: Set up voltage regulators for DVFS Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators. Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:12 +07:00
nvidia,tegra-cpu-regulator;
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
};
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
sm2_reg: sm2 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+3.7vs_sm2,vin_ldo*";
regulator-min-microvolt = <3700000>;
regulator-max-microvolt = <3700000>;
regulator-always-on;
};
/* LDO0 is not connected to anything */
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
ldo1 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+1.1vs_ldo1,avdd_pll*";
regulator-min-microvolt = <1100000>;
regulator-max-microvolt = <1100000>;
regulator-always-on;
};
ARM: tegra: paz00: Set up voltage regulators for DVFS Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators. Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:12 +07:00
rtc_vdd_reg: ldo2 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+1.2vs_ldo2,vdd_rtc";
regulator-min-microvolt = <1200000>;
ARM: tegra: paz00: Set up voltage regulators for DVFS Set minimum and maximum voltages, and couple CPU/CORE/RTC regulators. Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:12 +07:00
regulator-max-microvolt = <1225000>;
regulator-coupled-with = <&core_vdd_reg &cpu_vdd_reg>;
regulator-coupled-max-spread = <170000 450000>;
regulator-always-on;
nvidia,tegra-rtc-regulator;
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
};
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
ldo3 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+3.3vs_ldo3,avdd_usb*";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
ldo4 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+1.8vs_ldo4,avdd_osc,vddio_sys";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
regulator-always-on;
};
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
ldo5 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+2.85vs_ldo5,vcore_mmc";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
ldo6 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
/*
* Research indicates this should be
* 1.8v; other boards that use this
* rail for the same purpose need it
* set to 1.8v. The schematic signal
* name is incorrect; perhaps copied
* from an incorrect NVIDIA reference.
*/
regulator-name = "+2.85vs_ldo6,avdd_vdac";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
ARM: tegra: paz00: enable HDMI port Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-01-03 04:53:22 +07:00
hdmi_vdd_reg: ldo7 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+3.3vs_ldo7,avdd_hdmi";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
};
ARM: tegra: paz00: enable HDMI port Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-01-03 04:53:22 +07:00
hdmi_pll_reg: ldo8 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+1.8vs_ldo8,avdd_hdmi_pll";
regulator-min-microvolt = <1800000>;
regulator-max-microvolt = <1800000>;
};
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
ldo9 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+2.85vs_ldo9,vdd_ddr_rx";
regulator-min-microvolt = <2850000>;
regulator-max-microvolt = <2850000>;
regulator-always-on;
};
ARM: tegra: update *.dts for regulator-compatible deprecation Commit 13511de "regulator: deprecate regulator-compatible DT property" now allows for simpler content within the regulators node within a PMIC. Modify all the Tegra device tree files to take advantage of this. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Thierry Reding <thierry.reding@avionic-design.de>
2012-09-21 06:04:06 +07:00
ldo_rtc {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulator-name = "+3.3vs_rtc";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
regulator-always-on;
};
};
};
ARM: dt: tegra: add ADT7461 temperature sensor to paz00 device tree Add the ADT7461 temperature monitoring IC which is connected via the DVC controller. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-02-01 01:53:21 +07:00
adt7461@4c {
compatible = "adi,adt7461";
reg = <0x4c>;
};
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
};
ARM: tegra: add missing unit addresses to DT DT node names should include a unit address iff the node has a reg property. For Tegra DTs at least, we were previously applying a different rule, namely that node names only needed to include a unit address if it was required to make the node name unique. Consequently, many unit addresses are missing. Add them. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-11-26 07:53:16 +07:00
pmc@7000e400 {
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
nvidia,invert-interrupt;
ARM: tegra: enable LP1 suspend mode Enabling the LP1 suspend mode for Tegra devices. Tested-by: Marc Dietrich <marvin24@gmx.de> # paz00 board Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-08-12 16:40:07 +07:00
nvidia,suspend-mode = <1>;
ARM: dts: tegra: add the PM configurations of PMC Adding the PM configuration of PMC when the platform support suspend function. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-04-03 18:31:52 +07:00
nvidia,cpu-pwr-good-time = <2000>;
nvidia,cpu-pwr-off-time = <0>;
nvidia,core-pwr-good-time = <3845 3845>;
nvidia,core-pwr-off-time = <0>;
nvidia,sys-clock-req-active-high;
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
};
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
usb@c5000000 {
ARM: tegra: Enable UDC on AC100 Override the compatible string of the first USB controller to enable device mode. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-08-16 17:32:45 +07:00
compatible = "nvidia,tegra20-udc";
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
ARM: tegra: Enable UDC on AC100 Override the compatible string of the first USB controller to enable device mode. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Tested-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2017-08-16 17:32:45 +07:00
dr_mode = "peripheral";
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
};
ARM: tegra: update device trees for USB binding rework This patch updates all Tegra board files so that they contain all the properties required by the updated USB DT binding. Note that this patch only adds the new properties and does not yet remove the old properties, in order to maintain bisectability. The old properties will be removed once the driver has been updated to assume the new bindings. Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com> [swarren: fixed some newly added regulator-name properties to better match schematic, avoided duplicate regulator-name on Whistler.] Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-05-16 21:12:57 +07:00
usb-phy@c5000000 {
status = "okay";
};
ARM: dt: tegra: sort nodes based on bus order Sort the nodes according to the following rules: * First, any overrides for properties or nodes created by included files, in the order they appeared in the include file. * Second, any nodes with a reg property, in numerical order. * Third, any nodes without a reg property, in alphabetical order of node name. The second sorting rule at least will probably help if/when we need to explicitly insert nodes for the various busses in Tegra; that will just be an indentation change rather than also a node re-ordering. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:03:26 +07:00
usb@c5004000 {
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
ARM: tegra: convert device tree files to use GPIO defines Use TEGRA_GPIO() macro to name all GPIOs referenced by GPIO properties, and some interrupts properties. Use standard GPIO flag defines too. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-13 07:25:15 +07:00
nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 0)
GPIO_ACTIVE_LOW>;
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
};
ARM: tegra: modify ULPI reset GPIO properties 1. All Tegra20 ULPI reset GPIO DT properties are modified to indicate active low nature of the GPIO. 2. Placed USB PHY DT node immediately below the EHCI controller DT nodes and corrected reg value in the name of USB PHY DT node. Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-05-16 21:12:56 +07:00
usb-phy@c5004000 {
ARM: tegra: update device trees for USB binding rework This patch updates all Tegra board files so that they contain all the properties required by the updated USB DT binding. Note that this patch only adds the new properties and does not yet remove the old properties, in order to maintain bisectability. The old properties will be removed once the driver has been updated to assume the new bindings. Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com> [swarren: fixed some newly added regulator-name properties to better match schematic, avoided duplicate regulator-name on Whistler.] Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-05-16 21:12:57 +07:00
status = "okay";
ARM: tegra: convert device tree files to use GPIO defines Use TEGRA_GPIO() macro to name all GPIOs referenced by GPIO properties, and some interrupts properties. Use standard GPIO flag defines too. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-13 07:25:15 +07:00
nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 0)
GPIO_ACTIVE_LOW>;
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
};
ARM: tegra: modify ULPI reset GPIO properties 1. All Tegra20 ULPI reset GPIO DT properties are modified to indicate active low nature of the GPIO. 2. Placed USB PHY DT node immediately below the EHCI controller DT nodes and corrected reg value in the name of USB PHY DT node. Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-05-16 21:12:56 +07:00
usb@c5008000 {
status = "okay";
ARM: tegra: Add reset GPIO information to PHY DT node As reset GPIO information is PHY specific detail, adding it to PHY DT node. Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-01-24 17:16:46 +07:00
};
ARM: tegra: update device trees for USB binding rework This patch updates all Tegra board files so that they contain all the properties required by the updated USB DT binding. Note that this patch only adds the new properties and does not yet remove the old properties, in order to maintain bisectability. The old properties will be removed once the driver has been updated to assume the new bindings. Signed-off-by: Venu Byravarasu <vbyravarasu@nvidia.com> [swarren: fixed some newly added regulator-name properties to better match schematic, avoided duplicate regulator-name on Whistler.] Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-05-16 21:12:57 +07:00
usb-phy@c5008000 {
status = "okay";
};
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
sdhci@c8000000 {
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
ARM: tegra: convert device tree files to use GPIO defines Use TEGRA_GPIO() macro to name all GPIOs referenced by GPIO properties, and some interrupts properties. Use standard GPIO flag defines too. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-13 07:25:15 +07:00
cd-gpios = <&gpio TEGRA_GPIO(V, 5) GPIO_ACTIVE_LOW>;
wp-gpios = <&gpio TEGRA_GPIO(H, 1) GPIO_ACTIVE_HIGH>;
power-gpios = <&gpio TEGRA_GPIO(V, 1) GPIO_ACTIVE_HIGH>;
mmc: dt: Consolidate DT bindings This patch unifies the current DT MMC bindings documentation and code, adds generic MMC DT bindings documentation, and updates .dts files for consistency. [cjb: typo fixes, addition of max-frequency property] Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2012-05-13 11:14:24 +07:00
bus-width = <4>;
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
};
sdhci@c8000600 {
ARM: dt: tegra: invert status=disable vs status=okay In tegra*.dtsi, set status="disable" for all HW modules that the board design may choose not to use. Update all boards to specifically enable any of those modules that are useful by setting status="okay". This makes board files say which features they do use, rather than which they don't, which feels more logical. It also makes the .dts files slightly smaller, at least for existing content. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:32:56 +07:00
status = "okay";
mmc: dt: Consolidate DT bindings This patch unifies the current DT MMC bindings documentation and code, adds generic MMC DT bindings documentation, and updates .dts files for consistency. [cjb: typo fixes, addition of max-frequency property] Signed-off-by: Chris Ball <cjb@laptop.org> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2012-05-13 11:14:24 +07:00
bus-width = <8>;
ARM: tegra: add non-removable and keep-power-in-suspend property for MMC This patch adds "non-removable" property of MMC host where the eMMC device is for Tegra platform. And the "keep-power-in-suspend" property was used for the SDIO device that need this to go into suspend mode (e.g. BRCM43xx series). Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-04-04 03:34:39 +07:00
non-removable;
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
};
ARM: dt: tegra: add the power gpio key to paz00 device tree This adds the wakeup gpio which is connected to the embedded controller to the device tree of paz00. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-01-29 02:03:07 +07:00
ARM: tegra: paz00: Add LVDS support to device tree Add backlight and panel nodes for the PAZ00 TFT LCD panel. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-22 03:38:13 +07:00
backlight: backlight {
compatible = "pwm-backlight";
enable-gpios = <&gpio TEGRA_GPIO(U, 4) GPIO_ACTIVE_HIGH>;
pwms = <&pwm 0 5000000>;
brightness-levels = <0 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 255>;
default-brightness-level = <10>;
backlight-boot-off;
};
ARM: tegra: add clock source of PMC to device trees Adding the bindings of the clock source of PMC in DT. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-04-03 18:31:27 +07:00
clocks {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
ARM: tegra: add missing unit addresses to DT DT node names should include a unit address iff the node has a reg property. For Tegra DTs at least, we were previously applying a different rule, namely that node names only needed to include a unit address if it was required to make the node name unique. Consequently, many unit addresses are missing. Add them. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-11-26 07:53:16 +07:00
clk32k_in: clock@0 {
ARM: tegra: add clock source of PMC to device trees Adding the bindings of the clock source of PMC in DT. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-04-03 18:31:27 +07:00
compatible = "fixed-clock";
ARM: tegra: Add spaces around = in properties This seems to have been copied and pasted since the beginning of time, though only until Tegra124, likely because that DT was written from scratch or it was fixed along the way. Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-06-10 23:55:24 +07:00
reg = <0>;
ARM: tegra: add clock source of PMC to device trees Adding the bindings of the clock source of PMC in DT. Signed-off-by: Joseph Lo <josephl@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-04-03 18:31:27 +07:00
#clock-cells = <0>;
clock-frequency = <32768>;
};
};
ARM: dt: tegra: add the power gpio key to paz00 device tree This adds the wakeup gpio which is connected to the embedded controller to the device tree of paz00. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-01-29 02:03:07 +07:00
gpio-keys {
compatible = "gpio-keys";
ARM: dts: paz00: fix wakeup gpio keycode The power key is controlled solely by the EC, which only tiggeres this gpio after wakeup. Fixes immediately return to suspend after wake from LP1. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-08-02 15:45:40 +07:00
wakeup {
label = "Wakeup";
ARM: tegra: convert device tree files to use GPIO defines Use TEGRA_GPIO() macro to name all GPIOs referenced by GPIO properties, and some interrupts properties. Use standard GPIO flag defines too. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-13 07:25:15 +07:00
gpios = <&gpio TEGRA_GPIO(J, 7) GPIO_ACTIVE_LOW>;
ARM: dts: paz00: fix wakeup gpio keycode The power key is controlled solely by the EC, which only tiggeres this gpio after wakeup. Fixes immediately return to suspend after wake from LP1. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Tested-by: Nicolas Chauvet <kwizart@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-08-02 15:45:40 +07:00
linux,code = <KEY_WAKEUP>;
ARM: tegra: Replace legacy *,wakeup property with wakeup-source 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>
2016-02-09 04:55:43 +07:00
wakeup-source;
ARM: dt: tegra: add the power gpio key to paz00 device tree This adds the wakeup gpio which is connected to the embedded controller to the device tree of paz00. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-01-29 02:03:07 +07:00
};
};
ARM: dt: tegra: add the wifi led to paz00 device tree This adds the wifi led bound to the rfkill0 event to the device tree of paz00. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-01-29 02:03:08 +07:00
gpio-leds {
compatible = "gpio-leds";
wifi {
label = "wifi-led";
ARM: tegra: convert device tree files to use GPIO defines Use TEGRA_GPIO() macro to name all GPIOs referenced by GPIO properties, and some interrupts properties. Use standard GPIO flag defines too. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-13 07:25:15 +07:00
gpios = <&gpio TEGRA_GPIO(D, 0) GPIO_ACTIVE_HIGH>;
ARM: dt: tegra: add the wifi led to paz00 device tree This adds the wifi led bound to the rfkill0 event to the device tree of paz00. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Olof Johansson <olof@lixom.net>
2012-01-29 02:03:08 +07:00
linux,default-trigger = "rfkill0";
};
};
ARM: tegra: add USB ULPI PHY reset GPIO to device tree ULPI PHYs have a reset signal, and different boards use a different GPIO for this task. Add a property to device tree to represent this. I'm not sure if adding this property to the EHCI controller node is entirely correct; perhaps eventually we should have explicit separate nodes for the various PHYs. However, we don't have that right now, so this binding seems like a reasonable choice. Cc: <devicetree-discuss@lists.ozlabs.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <linux-usb@vger.kernel.org> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-04-13 04:46:49 +07:00
ARM: tegra: paz00: Add LVDS support to device tree Add backlight and panel nodes for the PAZ00 TFT LCD panel. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-22 03:38:13 +07:00
panel: panel {
compatible = "samsung,ltn101nt05", "simple-panel";
ddc-i2c-bus = <&lvds_ddc>;
power-supply = <&vdd_pnl_reg>;
enable-gpios = <&gpio TEGRA_GPIO(M, 6) GPIO_ACTIVE_HIGH>;
backlight = <&backlight>;
};
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
regulators {
compatible = "simple-bus";
#address-cells = <1>;
#size-cells = <0>;
p5valw_reg: regulator@0 {
compatible = "regulator-fixed";
reg = <0>;
regulator-name = "+5valw";
regulator-min-microvolt = <5000000>;
regulator-max-microvolt = <5000000>;
regulator-always-on;
};
ARM: tegra: paz00: Add LVDS support to device tree Add backlight and panel nodes for the PAZ00 TFT LCD panel. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-22 03:38:13 +07:00
vdd_pnl_reg: regulator@1 {
compatible = "regulator-fixed";
reg = <1>;
regulator-name = "+3VS,vdd_pnl";
regulator-min-microvolt = <3300000>;
regulator-max-microvolt = <3300000>;
ARM: tegra: paz00: Mark panel regulator as enabled on boot Current U-Boot enables the display already. Marking the regulator as enabled on boot fixes sporadic panel initialization failures. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Tested-by: Misha Komarovskiy <zombah@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2016-12-09 16:20:38 +07:00
regulator-boot-on;
ARM: tegra: paz00: Add LVDS support to device tree Add backlight and panel nodes for the PAZ00 TFT LCD panel. Signed-off-by: Marc Dietrich <marvin24@gmx.de> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-12-22 03:38:13 +07:00
gpio = <&gpio TEGRA_GPIO(A, 4) GPIO_ACTIVE_HIGH>;
enable-active-high;
};
ARM: dt: tegra: paz00: add regulators The Toshiba AC100/PAZ00 uses a TPS6586x regulator. Instantiate this. Three data sources were used for the data encoded here: * The HW defaults, as extracted from real HW. * The schematic, which specifies a voltage for each rail in the signal names. * The AC100 kernel used by the Ubuntu port: repo git://gitorious.org/~marvin24/ac100/marvin24s-kernel.git branch chromeos-ac100-3.0 file arch/arm/mach-tegra/board-paz00-power.c For many rails, the constraints in that tree specified differing min and max voltages. In all cases, the min value was ignored, since there's no need currently to vary any of the voltages at run-time. DVFS might change this in the future. In most cases these sources all matched. Differences are: sm0: HW defaults and schematic match at 1.2v. marvin24's kernel had a max of 1.3v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. sm1: HW defaults and schematic match at 1.0v. marvin24's kernel had a max of 1.125v, but this higher voltage was only applied to HW by DVFS code, which isn't currently supported in mainline. ldo3: The HW default is on. marvin24's kernel didn't specify always-on, but since the board wasn't marked as having fully constrained regulators, the rail was not turned off, so the difference had no effect. The rail is needed for USB. ldo6: The HW default is 2.85v. The schematics indicate 2.85v. However, since this regulator is used for the same purpose as on other boards that require 1.8v, this is set to 1.8v. Note that this regulator feeds the CRT VDAC on Tegra, and so in practice is unlikely to be used, even though it is actaully hooked up in HW. Portions based on work by Laxman Dewangan <ldewangan@nvidia.com> Signed-off-by: Stephen Warren <swarren@nvidia.com> Tested-by: Marc Dietrich <marvin24@gmx.de> # v2 Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
2012-06-22 03:24:57 +07:00
};
ARM: dt: tegra: sort nodes based on bus order Sort the nodes according to the following rules: * First, any overrides for properties or nodes created by included files, in the order they appeared in the include file. * Second, any nodes with a reg property, in numerical order. * Third, any nodes without a reg property, in alphabetical order of node name. The second sorting rule at least will probably help if/when we need to explicitly insert nodes for the various busses in Tegra; that will just be an indentation change rather than also a node re-ordering. Signed-off-by: Stephen Warren <swarren@nvidia.com> Acked-by: Olof Johansson <olof@lixom.net>
2012-05-12 06:03:26 +07:00
sound {
compatible = "nvidia,tegra-audio-alc5632-paz00",
"nvidia,tegra-audio-alc5632";
nvidia,model = "Compal PAZ00";
nvidia,audio-routing =
"Int Spk", "SPKOUT",
"Int Spk", "SPKOUTN",
"Headset Mic", "MICBIAS1",
"MIC1", "Headset Mic",
"Headset Stereophone", "HPR",
"Headset Stereophone", "HPL",
"DMICDAT", "Digital Mic";
nvidia,audio-codec = <&alc5632>;
nvidia,i2s-controller = <&tegra_i2s1>;
ARM: tegra: convert device tree files to use GPIO defines Use TEGRA_GPIO() macro to name all GPIOs referenced by GPIO properties, and some interrupts properties. Use standard GPIO flag defines too. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-02-13 07:25:15 +07:00
nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2)
GPIO_ACTIVE_HIGH>;
ARM: tegra: add clocks property to sound nodes Audio-related clocks need to be represented in the device tree. Update bindings to describe which clocks are needed, and DT files to include those clocks. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-03-27 05:45:52 +07:00
ARM: tegra20: convert device tree files to use CLK defines Use the Tegra20 CAR binding header (tegra20-car.h) to replace magic numbers in the device tree. For example, - clocks = <&tegra_car 28>; + clocks = <&tegra_car CLK_HOST1X>; Signed-off-by: Hiroshi Doyu <hdoyu@nvidia.com> [swarren, updated since tegra20-car.h moved for consistency] Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-05-22 23:45:32 +07:00
clocks = <&tegra_car TEGRA20_CLK_PLL_A>,
ARM: tegra: tegra20: Fix mixed tabs-spaces indentation Fix indentation and alignment when spaces were used instead of tabs. This fixes checkpatch errors like: ERROR: code indent should use tabs where possible #306: FILE: arch/arm/boot/dts/tegra20-paz00.dts:306: +^I^I <&tegra_car TEGRA20_CLK_PLL_P_OUT3>;$ Signed-off-by: Krzysztof Kozlowski <krzk@kernel.org> Acked-by: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2018-08-31 00:21:53 +07:00
<&tegra_car TEGRA20_CLK_PLL_A_OUT0>,
<&tegra_car TEGRA20_CLK_CDEV1>;
ARM: tegra: add clocks property to sound nodes Audio-related clocks need to be represented in the device tree. Update bindings to describe which clocks are needed, and DT files to include those clocks. Signed-off-by: Stephen Warren <swarren@nvidia.com>
2013-03-27 05:45:52 +07:00
clock-names = "pll_a", "pll_a_out0", "mclk";
ARM: tegra: add USB ULPI PHY reset GPIO to device tree ULPI PHYs have a reset signal, and different boards use a different GPIO for this task. Add a property to device tree to represent this. I'm not sure if adding this property to the EHCI controller node is entirely correct; perhaps eventually we should have explicit separate nodes for the various PHYs. However, we don't have that right now, so this binding seems like a reasonable choice. Cc: <devicetree-discuss@lists.ozlabs.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: <linux-usb@vger.kernel.org> Signed-off-by: Stephen Warren <swarren@nvidia.com>
2012-04-13 04:46:49 +07:00
};
ARM: tegra: paz00: Add CPU Operating Performance Points Utilize common Tegra20 CPU OPP table. CPU DVFS is available now on AC100. Signed-off-by: Dmitry Osipenko <digetx@gmail.com> Signed-off-by: Thierry Reding <treding@nvidia.com>
2019-10-25 05:14:13 +07:00
cpus {
cpu0: cpu@0 {
cpu-supply = <&cpu_vdd_reg>;
operating-points-v2 = <&cpu0_opp_table>;
};
cpu@1 {
cpu-supply = <&cpu_vdd_reg>;
operating-points-v2 = <&cpu0_opp_table>;
};
};
arm/dt: tegra: add dts file for paz00 This adds a dts file for paz00. As a side effect, this also enables the embedded controller which controls the keyboard, touchpad, power, leds, and some other functions. Cc: Grant Likely <grant.likely@secretlab.ca> Signed-off-by: Marc Dietrich <marvin24@gmx.de> Acked-by: Stephen Warren <swarren@nvidia.com> Signed-off-by: Olof Johansson <olof@lixom.net>
2011-11-01 17:37:05 +07:00
};
Reference in New Issue Copy Permalink