tegra: Move tegra20 towards the 'new' display bindings
Subsystems (4)
cover tegra: Move tegra20 towards the 'new' display bindings
The original tegra20 display driver was written before Linux had device tree bindings for display. Since then Linux has developed a robust set of bindings covering various aspects of enabling a display.
This series moves closer to those bindings by using the panel and backlight as separate drivers. The device tree files for seaboard, ventana and harmony thereby become almost the same as Linux.
Unfortunately this breaks the other boards, which will need a similar sync. So I'm not sure how easy it will be to accept this series. Still, it seems worth sending it out in the hope that board maintainers can help. I have kept this series separate so that it can progress separately.
Simon Glass (4):
tegra: dts: Sync seaboard device tree file with Linux
video: tegra: Move to using simple-panel and pwm-backlight
tegra: video: Always use write-through cache on LCD
fdt: Drop some unused compatible strings
arch/arm/dts/tegra20-harmony.dts | 751 ++++++++++++++++++++++++++++-- arch/arm/dts/tegra20-seaboard.dts | 934 ++++++++++++++++++++++++++++++++++---- arch/arm/dts/tegra20-ventana.dts | 685 ++++++++++++++++++++++++++-- configs/colibri_t20_defconfig | 5 +- configs/harmony_defconfig | 5 +- configs/medcom-wide_defconfig | 5 +- configs/paz00_defconfig | 5 +- configs/seaboard_defconfig | 5 +- configs/tec_defconfig | 5 +- configs/ventana_defconfig | 5 +- drivers/video/tegra.c | 333 +++----------- include/fdtdec.h | 4 - lib/fdtdec.c | 4 - 13 files changed, 2307 insertions(+), 439 deletions(-)
Signature · 1 line
2.6.0.rc2.230.g3dd15c0
PATCH 1/4 tegra: dts: Sync seaboard device tree file with Linux
Sync everything except the display panel, which will come in a future patch. One USB port is left disabled since we don't want to support it in U-Boot.
---
arch/arm/dts/tegra20-seaboard.dts | 889 +++++++++++++++++++++++++++++++++++--- 1 file changed, 822 insertions(+), 67 deletions(-)
arch/arm/dts/tegra20-seaboard.dts +822 -67
@@ -1,19 +1,12 @@ /dts-v1/; +#include <dt-bindings/input/input.h> #include "tegra20.dtsi" / { model = "NVIDIA Seaboard"; compatible = "nvidia,seaboard", "nvidia,tegra20"; - chosen { - bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk1p3 rw rootwait"; - }; - - chosen { - stdout-path = &uartd; - }; - aliases { /* This defines the order of our ports */ usb0 = "/usb at c5008000";
@@ -22,13 +15,23 @@ i2c1 = "/i2c at 7000c000"; i2c2 = "/i2c at 7000c400"; i2c3 = "/i2c at 7000c500"; + rtc0 = "/i2c at 7000d000/tps6586x at 34"; + rtc1 = "/rtc at 7000e000"; + serial0 = &uartd; sdhci0 = "/sdhci at c8000600"; sdhci1 = "/sdhci at c8000400"; }; + chosen { + bootargs = "vmalloc=192M video=tegrafb console=ttyS0,115200n8 root=/dev/mmcblk1p3 rw rootwait"; + }; + + chosen { + stdout-path = &uartd; + }; + memory { - device_type = "memory"; - reg = < 0x00000000 0x40000000 >; + reg = <0x00000000 0x40000000>; }; host1x at 50000000 {
@@ -37,35 +40,309 @@ status = "okay"; rgb { status = "okay"; - nvidia,panel = <&lcd_panel>; + + nvidia,panel = <&panel>; }; }; dc at 54240000 { status = "disabled"; }; + + hdmi at 54280000 { + status = "okay"; + + vdd-supply = <&hdmi_vdd_reg>; + pll-supply = <&hdmi_pll_reg>; + hdmi-supply = <&vdd_hdmi>; + + nvidia,ddc-i2c-bus = <&hdmi_ddc>; + nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7) + GPIO_ACTIVE_HIGH>; + }; }; - /* This is not used in U-Boot, but is expected to be in kernel .dts */ - i2c at 7000d000 { - status = "okay"; - clock-frequency = <100000>; - pmic at 34 { - compatible = "ti,tps6586x"; - reg = <0x34>; + pinmux at 70000014 { + pinctrl-names = "default"; + pinctrl-0 = <&state_default>; + + state_default: pinmux { + ata { + nvidia,pins = "ata"; + nvidia,function = "ide"; + }; + atb { + nvidia,pins = "atb", "gma", "gme"; + nvidia,function = "sdio4"; + }; + atc { + nvidia,pins = "atc"; + nvidia,function = "nand"; + }; + atd { + nvidia,pins = "atd", "ate", "gmb", "spia", + "spib", "spic"; + nvidia,function = "gmi"; + }; + cdev1 { + nvidia,pins = "cdev1"; + nvidia,function = "plla_out"; + }; + cdev2 { + nvidia,pins = "cdev2"; + nvidia,function = "pllp_out4"; + }; + crtp { + nvidia,pins = "crtp", "lm1"; + nvidia,function = "crt"; + }; + csus { + nvidia,pins = "csus"; + nvidia,function = "vi_sensor_clk"; + }; + dap1 { + nvidia,pins = "dap1"; + nvidia,function = "dap1"; + }; + dap2 { + nvidia,pins = "dap2"; + nvidia,function = "dap2"; + }; + dap3 { + nvidia,pins = "dap3"; + nvidia,function = "dap3"; + }; + dap4 { + nvidia,pins = "dap4"; + nvidia,function = "dap4"; + }; + dta { + nvidia,pins = "dta", "dtb", "dtc", "dtd", "dte"; + nvidia,function = "vi"; + }; + dtf { + nvidia,pins = "dtf"; + nvidia,function = "i2c3"; + }; + gmc { + nvidia,pins = "gmc"; + nvidia,function = "uartd"; + }; + gmd { + nvidia,pins = "gmd"; + nvidia,function = "sflash"; + }; + gpu { + nvidia,pins = "gpu"; + nvidia,function = "pwm"; + }; + gpu7 { + nvidia,pins = "gpu7"; + nvidia,function = "rtck"; + }; + gpv { + nvidia,pins = "gpv", "slxa", "slxk"; + nvidia,function = "pcie"; + }; + hdint { + nvidia,pins = "hdint", "lpw0", "lpw2", "lsc1", + "lsck", "lsda"; + nvidia,function = "hdmi"; + }; + i2cp { + nvidia,pins = "i2cp"; + nvidia,function = "i2cp"; + }; + irrx { + nvidia,pins = "irrx", "irtx"; + nvidia,function = "uartb"; + }; + kbca { + nvidia,pins = "kbca", "kbcb", "kbcc", "kbcd", + "kbce", "kbcf"; + nvidia,function = "kbc"; + }; + lcsn { + nvidia,pins = "lcsn", "ldc", "lm0", "lpw1", + "lsdi", "lvp0"; + nvidia,function = "rsvd4"; + }; + ld0 { + nvidia,pins = "ld0", "ld1", "ld2", "ld3", "ld4", + "ld5", "ld6", "ld7", "ld8", "ld9", + "ld10", "ld11", "ld12", "ld13", "ld14", + "ld15", "ld16", "ld17", "ldi", "lhp0", + "lhp1", "lhp2", "lhs", "lpp", "lsc0", + "lspi", "lvp1", "lvs"; + nvidia,function = "displaya"; + }; + owc { + nvidia,pins = "owc", "spdi", "spdo", "uac"; + nvidia,function = "rsvd2"; + }; + pmc { + nvidia,pins = "pmc"; + nvidia,function = "pwr_on"; + }; + rm { + nvidia,pins = "rm"; + nvidia,function = "i2c1"; + }; + sdb { + nvidia,pins = "sdb", "sdc", "sdd"; + nvidia,function = "sdio3"; + }; + sdio1 { + nvidia,pins = "sdio1"; + nvidia,function = "sdio1"; + }; + slxc { + nvidia,pins = "slxc", "slxd"; + nvidia,function = "spdif"; + }; + spid { + nvidia,pins = "spid", "spie", "spif"; + nvidia,function = "spi1"; + }; + spig { + nvidia,pins = "spig", "spih"; + nvidia,function = "spi2_alt"; + }; + uaa { + nvidia,pins = "uaa", "uab", "uda"; + nvidia,function = "ulpi"; + }; + uad { + nvidia,pins = "uad"; + nvidia,function = "irda"; + }; + uca { + nvidia,pins = "uca", "ucb"; + nvidia,function = "uartc"; + }; + conf_ata { + nvidia,pins = "ata", "atb", "atc", "atd", + "cdev1", "cdev2", "dap1", "dap2", + "dap4", "ddc", "dtf", "gma", "gmc", "gmd", + "gme", "gpu", "gpu7", "i2cp", "irrx", + "irtx", "pta", "rm", "sdc", "sdd", + "slxd", "slxk", "spdi", "spdo", "uac", + "uad", "uca", "ucb", "uda"; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + conf_ate { + nvidia,pins = "ate", "csus", "dap3", + "gpv", "owc", "slxc", "spib", "spid", + "spie"; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + nvidia,tristate = <TEGRA_PIN_ENABLE>; + }; + conf_ck32 { + nvidia,pins = "ck32", "ddrc", "pmca", "pmcb", + "pmcc", "pmcd", "pmce", "xm2c", "xm2d"; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + }; + conf_crtp { + nvidia,pins = "crtp", "gmb", "slxa", "spia", + "spig", "spih"; + nvidia,pull = <TEGRA_PIN_PULL_UP>; + nvidia,tristate = <TEGRA_PIN_ENABLE>; + }; + conf_dta { + nvidia,pins = "dta", "dtb", "dtc", "dtd"; + nvidia,pull = <TEGRA_PIN_PULL_DOWN>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + conf_dte { + nvidia,pins = "dte", "spif"; + nvidia,pull = <TEGRA_PIN_PULL_DOWN>; + nvidia,tristate = <TEGRA_PIN_ENABLE>; + }; + conf_hdint { + nvidia,pins = "hdint", "lcsn", "ldc", "lm1", + "lpw1", "lsc1", "lsck", "lsda", "lsdi", + "lvp0"; + nvidia,tristate = <TEGRA_PIN_ENABLE>; + }; + conf_kbca { + nvidia,pins = "kbca", "kbcb", "kbcc", "kbcd", + "kbce", "kbcf", "sdio1", "spic", "uaa", + "uab"; + nvidia,pull = <TEGRA_PIN_PULL_UP>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + conf_lc { + nvidia,pins = "lc", "ls"; + nvidia,pull = <TEGRA_PIN_PULL_UP>; + }; + conf_ld0 { + nvidia,pins = "ld0", "ld1", "ld2", "ld3", "ld4", + "ld5", "ld6", "ld7", "ld8", "ld9", + "ld10", "ld11", "ld12", "ld13", "ld14", + "ld15", "ld16", "ld17", "ldi", "lhp0", + "lhp1", "lhp2", "lhs", "lm0", "lpp", + "lpw0", "lpw2", "lsc0", "lspi", "lvp1", + "lvs", "pmc", "sdb"; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + conf_ld17_0 { + nvidia,pins = "ld17_0", "ld19_18", "ld21_20", + "ld23_22"; + nvidia,pull = <TEGRA_PIN_PULL_DOWN>; + }; + drive_sdio1 { + nvidia,pins = "drive_sdio1"; + nvidia,high-speed-mode = <TEGRA_PIN_DISABLE>; + nvidia,schmitt = <TEGRA_PIN_DISABLE>; + nvidia,low-power-mode = <TEGRA_PIN_LP_DRIVE_DIV_1>; + nvidia,pull-down-strength = <31>; + nvidia,pull-up-strength = <31>; + nvidia,slew-rate-rising = <TEGRA_PIN_SLEW_RATE_SLOWEST>; + nvidia,slew-rate-falling = <TEGRA_PIN_SLEW_RATE_SLOWEST>; + }; + }; + + state_i2cmux_ddc: pinmux_i2cmux_ddc { + ddc { + nvidia,pins = "ddc"; + nvidia,function = "i2c2"; + }; + pta { + nvidia,pins = "pta"; + nvidia,function = "rsvd4"; + }; + }; - clk_32k: clock { - compatible = "fixed-clock"; - /* - * leave out for now due to CPP: - * #clock-cells = <0>; - */ - clock-frequency = <32768>; + state_i2cmux_pta: pinmux_i2cmux_pta { + ddc { + nvidia,pins = "ddc"; + nvidia,function = "rsvd4"; + }; + pta { + nvidia,pins = "pta"; + nvidia,function = "i2c2"; + }; + }; + + state_i2cmux_idle: pinmux_i2cmux_idle { + ddc { + nvidia,pins = "ddc"; + nvidia,function = "rsvd4"; + }; + pta { + nvidia,pins = "pta"; + nvidia,function = "rsvd4"; }; }; }; + i2s at 70002800 { + status = "okay"; + }; + serial at 70006300 { + status = "okay"; clock-frequency = < 216000000 >; };
@@ -79,56 +356,376 @@ }; }; + pwm: pwm at 7000a000 { + status = "okay"; + }; + i2c at 7000c000 { status = "okay"; - clock-frequency = <100000>; + clock-frequency = <400000>; + + wm8903: wm8903 at 1a { + compatible = "wlf,wm8903"; + reg = <0x1a>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(X, 3) IRQ_TYPE_LEVEL_HIGH>; + + gpio-controller; + #gpio-cells = <2>; + + micdet-cfg = <0>; + micdet-delay = <100>; + gpio-cfg = <0xffffffff 0xffffffff 0 0xffffffff 0xffffffff>; + }; + + /* ALS and proximity sensor */ + isl29018 at 44 { + compatible = "isil,isl29018"; + reg = <0x44>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(Z, 2) IRQ_TYPE_LEVEL_HIGH>; + }; + + gyrometer at 68 { + compatible = "invn,mpu3050"; + reg = <0x68>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(Z, 4) IRQ_TYPE_LEVEL_HIGH>; + }; }; i2c at 7000c400 { status = "okay"; + clock-frequency = <100000>; + }; + + i2cmux { + compatible = "i2c-mux-pinctrl"; + #address-cells = <1>; + #size-cells = <0>; + + i2c-parent = <&{/i2c@7000c400}>; + + pinctrl-names = "ddc", "pta", "idle"; + pinctrl-0 = <&state_i2cmux_ddc>; + pinctrl-1 = <&state_i2cmux_pta>; + pinctrl-2 = <&state_i2cmux_idle>; + + hdmi_ddc: i2c at 0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + lvds_ddc: i2c at 1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + smart-battery at b { + compatible = "ti,bq20z75", "smart-battery-1.1"; + reg = <0xb>; + ti,i2c-retry-count = <2>; + ti,poll-retry-count = <10>; + }; + }; }; i2c at 7000c500 { status = "okay"; - clock-frequency = <100000>; + clock-frequency = <400000>; + }; + + i2c at 7000d000 { + status = "okay"; + clock-frequency = <400000>; + + magnetometer at c { + compatible = "asahi-kasei,ak8975"; + reg = <0xc>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(N, 5) IRQ_TYPE_LEVEL_HIGH>; + }; + + pmic: tps6586x at 34 { + compatible = "ti,tps6586x"; + reg = <0x34>; + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>; + + ti,system-power-controller; + + #gpio-cells = <2>; + gpio-controller; + + sys-supply = <&vdd_5v0_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 { + sys_reg: sys { + regulator-name = "vdd_sys"; + regulator-always-on; + }; + + sm0 { + regulator-name = "vdd_sm0,vdd_core"; + regulator-min-microvolt = <1300000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + }; + + sm1 { + regulator-name = "vdd_sm1,vdd_cpu"; + regulator-min-microvolt = <1125000>; + regulator-max-microvolt = <1125000>; + regulator-always-on; + }; + + sm2_reg: sm2 { + regulator-name = "vdd_sm2,vin_ldo*"; + regulator-min-microvolt = <3700000>; + regulator-max-microvolt = <3700000>; + regulator-always-on; + }; + + /* LDO0 is not connected to anything */ + + ldo1 { + regulator-name = "vdd_ldo1,avdd_pll*"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + }; + + ldo2 { + regulator-name = "vdd_ldo2,vdd_rtc"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + + ldo3 { + regulator-name = "vdd_ldo3,avdd_usb*"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + ldo4 { + regulator-name = "vdd_ldo4,avdd_osc,vddio_sys"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + }; + + ldo5 { + regulator-name = "vdd_ldo5,vcore_mmc"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <2850000>; + regulator-always-on; + }; + + ldo6 { + regulator-name = "vdd_ldo6,avdd_vdac,vddio_vi,vddio_cam"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + hdmi_vdd_reg: ldo7 { + regulator-name = "vdd_ldo7,avdd_hdmi,vdd_fuse"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + hdmi_pll_reg: ldo8 { + regulator-name = "vdd_ldo8,avdd_hdmi_pll"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + ldo9 { + regulator-name = "vdd_ldo9,avdd_2v85,vdd_ddr_rx"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <2850000>; + regulator-always-on; + }; + + ldo_rtc { + regulator-name = "vdd_rtc_out,vdd_cell"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + }; + }; + + temperature-sensor at 4c { + compatible = "onnn,nct1008"; + reg = <0x4c>; + }; }; kbc at 7000e200 { status = "okay"; - linux,keymap = <0x00020011 0x0003001f 0x0004001e 0x0005002c - 0x000701d0 0x0107007d 0x02060064 0x02070038 0x03000006 - 0x03010005 0x03020013 0x03030012 0x03040021 0x03050020 - 0x0306002d 0x04000008 0x04010007 0x04020014 0x04030023 - 0x04040022 0x0405002f 0x0406002e 0x04070039 0x0500000a - 0x05010009 0x05020016 0x05030015 0x05040024 0x05050031 - 0x05060030 0x0507002b 0x0600000c 0x0601000b 0x06020018 - 0x06030017 0x06040026 0x06050025 0x06060033 0x06070032 - 0x0701000d 0x0702001b 0x0703001c 0x0707008b 0x08040036 - 0x0805002a 0x09050061 0x0907001d 0x0b00001a 0x0b010019 - 0x0b020028 0x0b030027 0x0b040035 0x0b050034 0x0c000044 - 0x0c010043 0x0c02000e 0x0c030004 0x0c040003 0x0c050067 - 0x0c0600d2 0x0c070077 0x0d00006e 0x0d01006f 0x0d030068 - 0x0d04006d 0x0d05006a 0x0d06006c 0x0d070069 0x0e000057 - 0x0e010058 0x0e020042 0x0e030010 0x0e04003e 0x0e05003d - 0x0e060002 0x0e070041 0x0f000001 0x0f010029 0x0f02003f - 0x0f03000f 0x0f04003b 0x0f05003c 0x0f06003a 0x0f070040 - 0x14000047 0x15000049 0x15010048 0x1502004b 0x1504004f - 0x16010062 0x1602004d 0x1603004c 0x16040051 0x16050050 - 0x16070052 0x1b010037 0x1b03004a 0x1b04004e 0x1b050053 - 0x1c050073 0x1d030066 0x1d04006b 0x1d0500e0 0x1d060072 - 0x1d0700e1 0x1e000045 0x1e010046 0x1e020071 - 0x1f04008a>; - linux,fn-keymap = <0x05040002>; - }; - - emc at 7000f400 { - #address-cells = <1>; - #size-cells = <0>; + nvidia,debounce-delay-ms = <32>; + nvidia,repeat-delay-ms = <160>; + nvidia,ghost-filter; + nvidia,kbc-row-pins = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>; + nvidia,kbc-col-pins = <16 17 18 19 20 21 22 23>; + linux,keymap = <MATRIX_KEY(0x00, 0x02, KEY_W) + MATRIX_KEY(0x00, 0x03, KEY_S) + MATRIX_KEY(0x00, 0x04, KEY_A) + MATRIX_KEY(0x00, 0x05, KEY_Z) + MATRIX_KEY(0x00, 0x07, KEY_FN) + + MATRIX_KEY(0x01, 0x07, KEY_LEFTMETA) + MATRIX_KEY(0x02, 0x06, KEY_RIGHTALT) + MATRIX_KEY(0x02, 0x07, KEY_LEFTALT) + + MATRIX_KEY(0x03, 0x00, KEY_5) + MATRIX_KEY(0x03, 0x01, KEY_4) + MATRIX_KEY(0x03, 0x02, KEY_R) + MATRIX_KEY(0x03, 0x03, KEY_E) + MATRIX_KEY(0x03, 0x04, KEY_F) + MATRIX_KEY(0x03, 0x05, KEY_D) + MATRIX_KEY(0x03, 0x06, KEY_X) + + MATRIX_KEY(0x04, 0x00, KEY_7) + MATRIX_KEY(0x04, 0x01, KEY_6) + MATRIX_KEY(0x04, 0x02, KEY_T) + MATRIX_KEY(0x04, 0x03, KEY_H) + MATRIX_KEY(0x04, 0x04, KEY_G) + MATRIX_KEY(0x04, 0x05, KEY_V) + MATRIX_KEY(0x04, 0x06, KEY_C) + MATRIX_KEY(0x04, 0x07, KEY_SPACE) + + MATRIX_KEY(0x05, 0x00, KEY_9) + MATRIX_KEY(0x05, 0x01, KEY_8) + MATRIX_KEY(0x05, 0x02, KEY_U) + MATRIX_KEY(0x05, 0x03, KEY_Y) + MATRIX_KEY(0x05, 0x04, KEY_J) + MATRIX_KEY(0x05, 0x05, KEY_N) + MATRIX_KEY(0x05, 0x06, KEY_B) + MATRIX_KEY(0x05, 0x07, KEY_BACKSLASH) + + MATRIX_KEY(0x06, 0x00, KEY_MINUS) + MATRIX_KEY(0x06, 0x01, KEY_0) + MATRIX_KEY(0x06, 0x02, KEY_O) + MATRIX_KEY(0x06, 0x03, KEY_I) + MATRIX_KEY(0x06, 0x04, KEY_L) + MATRIX_KEY(0x06, 0x05, KEY_K) + MATRIX_KEY(0x06, 0x06, KEY_COMMA) + MATRIX_KEY(0x06, 0x07, KEY_M) + + MATRIX_KEY(0x07, 0x01, KEY_EQUAL) + MATRIX_KEY(0x07, 0x02, KEY_RIGHTBRACE) + MATRIX_KEY(0x07, 0x03, KEY_ENTER) + MATRIX_KEY(0x07, 0x07, KEY_MENU) + + MATRIX_KEY(0x08, 0x04, KEY_RIGHTSHIFT) + MATRIX_KEY(0x08, 0x05, KEY_LEFTSHIFT) + + MATRIX_KEY(0x09, 0x05, KEY_RIGHTCTRL) + MATRIX_KEY(0x09, 0x07, KEY_LEFTCTRL) + + MATRIX_KEY(0x0B, 0x00, KEY_LEFTBRACE) + MATRIX_KEY(0x0B, 0x01, KEY_P) + MATRIX_KEY(0x0B, 0x02, KEY_APOSTROPHE) + MATRIX_KEY(0x0B, 0x03, KEY_SEMICOLON) + MATRIX_KEY(0x0B, 0x04, KEY_SLASH) + MATRIX_KEY(0x0B, 0x05, KEY_DOT) + + MATRIX_KEY(0x0C, 0x00, KEY_F10) + MATRIX_KEY(0x0C, 0x01, KEY_F9) + MATRIX_KEY(0x0C, 0x02, KEY_BACKSPACE) + MATRIX_KEY(0x0C, 0x03, KEY_3) + MATRIX_KEY(0x0C, 0x04, KEY_2) + MATRIX_KEY(0x0C, 0x05, KEY_UP) + MATRIX_KEY(0x0C, 0x06, KEY_PRINT) + MATRIX_KEY(0x0C, 0x07, KEY_PAUSE) + + MATRIX_KEY(0x0D, 0x00, KEY_INSERT) + MATRIX_KEY(0x0D, 0x01, KEY_DELETE) + MATRIX_KEY(0x0D, 0x03, KEY_PAGEUP ) + MATRIX_KEY(0x0D, 0x04, KEY_PAGEDOWN) + MATRIX_KEY(0x0D, 0x05, KEY_RIGHT) + MATRIX_KEY(0x0D, 0x06, KEY_DOWN) + MATRIX_KEY(0x0D, 0x07, KEY_LEFT) + + MATRIX_KEY(0x0E, 0x00, KEY_F11) + MATRIX_KEY(0x0E, 0x01, KEY_F12) + MATRIX_KEY(0x0E, 0x02, KEY_F8) + MATRIX_KEY(0x0E, 0x03, KEY_Q) + MATRIX_KEY(0x0E, 0x04, KEY_F4) + MATRIX_KEY(0x0E, 0x05, KEY_F3) + MATRIX_KEY(0x0E, 0x06, KEY_1) + MATRIX_KEY(0x0E, 0x07, KEY_F7) + + MATRIX_KEY(0x0F, 0x00, KEY_ESC) + MATRIX_KEY(0x0F, 0x01, KEY_GRAVE) + MATRIX_KEY(0x0F, 0x02, KEY_F5) + MATRIX_KEY(0x0F, 0x03, KEY_TAB) + MATRIX_KEY(0x0F, 0x04, KEY_F1) + MATRIX_KEY(0x0F, 0x05, KEY_F2) + MATRIX_KEY(0x0F, 0x06, KEY_CAPSLOCK) + MATRIX_KEY(0x0F, 0x07, KEY_F6) + + /* Software Handled Function Keys */ + MATRIX_KEY(0x14, 0x00, KEY_KP7) + + MATRIX_KEY(0x15, 0x00, KEY_KP9) + MATRIX_KEY(0x15, 0x01, KEY_KP8) + MATRIX_KEY(0x15, 0x02, KEY_KP4) + MATRIX_KEY(0x15, 0x04, KEY_KP1) + + MATRIX_KEY(0x16, 0x01, KEY_KPSLASH) + MATRIX_KEY(0x16, 0x02, KEY_KP6) + MATRIX_KEY(0x16, 0x03, KEY_KP5) + MATRIX_KEY(0x16, 0x04, KEY_KP3) + MATRIX_KEY(0x16, 0x05, KEY_KP2) + MATRIX_KEY(0x16, 0x07, KEY_KP0) + + MATRIX_KEY(0x1B, 0x01, KEY_KPASTERISK) + MATRIX_KEY(0x1B, 0x03, KEY_KPMINUS) + MATRIX_KEY(0x1B, 0x04, KEY_KPPLUS) + MATRIX_KEY(0x1B, 0x05, KEY_KPDOT) + + MATRIX_KEY(0x1C, 0x05, KEY_VOLUMEUP) + + MATRIX_KEY(0x1D, 0x03, KEY_HOME) + MATRIX_KEY(0x1D, 0x04, KEY_END) + MATRIX_KEY(0x1D, 0x05, KEY_BRIGHTNESSDOWN) + MATRIX_KEY(0x1D, 0x06, KEY_VOLUMEDOWN) + MATRIX_KEY(0x1D, 0x07, KEY_BRIGHTNESSUP) + + MATRIX_KEY(0x1E, 0x00, KEY_NUMLOCK) + MATRIX_KEY(0x1E, 0x01, KEY_SCROLLLOCK) + MATRIX_KEY(0x1E, 0x02, KEY_MUTE) + + MATRIX_KEY(0x1F, 0x04, KEY_HELP)>; + }; + + pmc at 7000e400 { + nvidia,invert-interrupt; + nvidia,suspend-mode = <1>; + nvidia,cpu-pwr-good-time = <5000>; + nvidia,cpu-pwr-off-time = <5000>; + nvidia,core-pwr-good-time = <3845 3845>; + nvidia,core-pwr-off-time = <3875>; + nvidia,sys-clock-req-active-high; + }; + + memory-controller at 7000f400 { emc-table at 190000 { - reg = < 190000 >; + reg = <190000>; compatible = "nvidia,tegra20-emc-table"; - clock-frequency = < 190000 >; - nvidia,emc-registers = < 0x0000000c 0x00000026 + clock-frequency = <190000>; + nvidia,emc-registers = <0x0000000c 0x00000026 0x00000009 0x00000003 0x00000004 0x00000004 0x00000002 0x0000000c 0x00000003 0x00000003 0x00000002 0x00000001 0x00000004 0x00000005
@@ -139,13 +736,14 @@ 0x00000002 0x00000000 0x00000000 0x00000002 0x00000000 0x00000000 0x00000083 0xa06204ae 0x007dc010 0x00000000 0x00000000 0x00000000 - 0x00000000 0x00000000 0x00000000 0x00000000 >; + 0x00000000 0x00000000 0x00000000 0x00000000>; }; + emc-table at 380000 { - reg = < 380000 >; + reg = <380000>; compatible = "nvidia,tegra20-emc-table"; - clock-frequency = < 380000 >; - nvidia,emc-registers = < 0x00000017 0x0000004b + clock-frequency = <380000>; + nvidia,emc-registers = <0x00000017 0x0000004b 0x00000012 0x00000006 0x00000004 0x00000005 0x00000003 0x0000000c 0x00000006 0x00000006 0x00000003 0x00000001 0x00000004 0x00000005
@@ -156,7 +754,7 @@ 0x00000002 0x00000000 0x00000000 0x00000002 0x00000000 0x00000000 0x00000083 0xe044048b 0x007d8010 0x00000000 0x00000000 0x00000000 - 0x00000000 0x00000000 0x00000000 0x00000000 >; + 0x00000000 0x00000000 0x00000000 0x00000000>; }; };
@@ -166,14 +764,39 @@ dr_mode = "otg"; }; + usb-phy at c5000000 { + status = "okay"; + vbus-supply = <&vbus_reg>; + dr_mode = "otg"; + }; + usb at c5004000 { status = "disabled"; + nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1) + GPIO_ACTIVE_LOW>; + }; + + usb-phy at c5004000 { + status = "okay"; + nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1) + GPIO_ACTIVE_LOW>; }; usb at c5008000 { status = "okay"; }; + usb-phy at c5008000 { + status = "okay"; + }; + + sdhci at c8000000 { + status = "okay"; + power-gpios = <&gpio TEGRA_GPIO(K, 6) GPIO_ACTIVE_HIGH>; + bus-width = <4>; + keep-power-in-suspend; + }; + sdhci at c8000400 { status = "okay"; cd-gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
@@ -185,6 +808,18 @@ sdhci at c8000600 { status = "okay"; bus-width = <8>; + non-removable; + }; + + backlight: backlight { + compatible = "pwm-backlight"; + + enable-gpios = <&gpio TEGRA_GPIO(D, 4) GPIO_ACTIVE_HIGH>; + power-supply = <&vdd_bl_reg>; + pwms = <&pwm 2 5000000>; + + brightness-levels = <0 4 8 16 32 64 128 255>; + default-brightness-level = <6>; }; clocks {
@@ -200,11 +835,27 @@ }; }; - pwm: pwm at 7000a000 { - status = "okay"; + gpio-keys { + compatible = "gpio-keys"; + + power { + label = "Power"; + gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>; + linux,code = <KEY_POWER>; + gpio-key,wakeup; + }; + + lid { + label = "Lid"; + gpios = <&gpio TEGRA_GPIO(C, 7) GPIO_ACTIVE_HIGH>; + linux,input-type = <5>; /* EV_SW */ + linux,code = <0>; /* SW_LID */ + debounce-interval = <1>; + gpio-key,wakeup; + }; }; - lcd_panel: panel { + panel: panel { /* Seaboard has 1366x768 */ clock = <70600000>; xres = <1366>;
@@ -228,4 +879,108 @@ GPIO_ACTIVE_HIGH>; nvidia,panel-timings = <400 4 203 17 15>; }; + + regulators { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <0>; + + vdd_5v0_reg: regulator at 0 { + compatible = "regulator-fixed"; + reg = <0>; + regulator-name = "vdd_5v0"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + regulator-always-on; + }; + + regulator at 1 { + compatible = "regulator-fixed"; + reg = <1>; + regulator-name = "vdd_1v5"; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + gpio = <&pmic 0 GPIO_ACTIVE_HIGH>; + }; + + regulator at 2 { + compatible = "regulator-fixed"; + reg = <2>; + regulator-name = "vdd_1v2"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + gpio = <&pmic 1 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vbus_reg: regulator at 3 { + compatible = "regulator-fixed"; + reg = <3>; + regulator-name = "vdd_vbus_wup1"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + enable-active-high; + gpio = <&gpio TEGRA_GPIO(D, 0) 0>; + regulator-always-on; + regulator-boot-on; + }; + + vdd_pnl_reg: regulator at 4 { + compatible = "regulator-fixed"; + reg = <4>; + regulator-name = "vdd_pnl"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + gpio = <&gpio TEGRA_GPIO(C, 6) GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vdd_bl_reg: regulator at 5 { + compatible = "regulator-fixed"; + reg = <5>; + regulator-name = "vdd_bl"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + gpio = <&gpio TEGRA_GPIO(W, 0) GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vdd_hdmi: regulator at 6 { + compatible = "regulator-fixed"; + reg = <6>; + regulator-name = "VDDIO_HDMI"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + gpio = <&gpio TEGRA_GPIO(V, 5) GPIO_ACTIVE_HIGH>; + enable-active-high; + vin-supply = <&vdd_5v0_reg>; + }; + }; + + sound { + compatible = "nvidia,tegra-audio-wm8903-seaboard", + "nvidia,tegra-audio-wm8903"; + nvidia,model = "NVIDIA Tegra Seaboard"; + + nvidia,audio-routing = + "Headphone Jack", "HPOUTR", + "Headphone Jack", "HPOUTL", + "Int Spk", "ROP", + "Int Spk", "RON", + "Int Spk", "LOP", + "Int Spk", "LON", + "Mic Jack", "MICBIAS", + "IN1R", "Mic Jack"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&wm8903>; + + nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>; + nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(X, 1) GPIO_ACTIVE_HIGH>; + + clocks = <&tegra_car TEGRA20_CLK_PLL_A>, + <&tegra_car TEGRA20_CLK_PLL_A_OUT0>, + <&tegra_car TEGRA20_CLK_CDEV1>; + clock-names = "pll_a", "pll_a_out0", "mclk"; + }; };
Signature · 1 line
2.6.0.rc2.230.g3dd15c0
PATCH 1/4 tegra: dts: Sync seaboard device tree file with Linux
Quoted 2 lines · Simon Glass
Sync everything except the display panel, which will come in a future patch. One USB port is left disabled since we don't want to support it in U-Boot.
It would be useful to mention which version of Linux this DT content came from.
BTW, this series (at least this patch) seems to have a significant number of "git am" conflicts when I try to apply it to either v2016.01 or u-boot/master as of today. Consequently I can't apply it to test it. Which commit/branch is it based on?
arch/arm/dts/tegra20-seaboard.dts line 67
Quoted 5 lines
arch/arm/dts/tegra20-seaboard.dts +3
-0+ pinmux at 70000014 { + pinctrl-names = "default"; + pinctrl-0 = <&state_default>;
I agree that the DT content that's common between U-Boot's and Linux's copies of the DT files should be identical. However, I wonder if it makes sense to include nodes (and perhaps even properties) in U-Boot's DT that U-Boot doesn't use.
I can see the argument that keeping the files identical is easier to track and remove any differences.
However, I'd also argue that keeping the U-Boot DT files lean (i.e. only containing the nodes U-Boot uses) will allow easier determination of exactly what parts of the DT U-Boot uses, and hence perhaps highlight any parts that might still need conversion.
PATCH 1/4 tegra: dts: Sync seaboard device tree file with Linux
Hi Stephen,
Quoted 7 lines · Stephen Warren
Quoted 4 lines · Simon Glass
Sync everything except the display panel, which will come in a future patch.
One USB port is left disabled since we don't want to support it in U-Boot.
Quoted 7 lines
It would be useful to mention which version of Linux this DT content came from.
BTW, this series (at least this patch) seems to have a significant number of "git am" conflicts when I try to apply it to either v2016.01 or u-boot/master as of today. Consequently I can't apply it to test it. Which commit/branch is it based on?
See u-boot-dm/rkf-working, which has all the patches.
Quoted 15 lines
arch/arm/dts/tegra20-seaboard.dts line 67
Quoted 8 lines
arch/arm/dts/tegra20-seaboard.dts +3
-0+ pinmux at 70000014 { + pinctrl-names = "default"; + pinctrl-0 = <&state_default>;I agree that the DT content that's common between U-Boot's and Linux's copies of the DT files should be identical. However, I wonder if it makes sense to include nodes (and perhaps even properties) in U-Boot's DT that U-Boot doesn't use.
Quoted 7 lines
I can see the argument that keeping the files identical is easier to track and remove any differences.
However, I'd also argue that keeping the U-Boot DT files lean (i.e. only containing the nodes U-Boot uses) will allow easier determination of exactly what parts of the DT U-Boot uses, and hence perhaps highlight any parts that might still need conversion.
Indeed. I'm leaning towards including everything since it is simple. On tegra we don't use pinctrl so that is a waste, but it's not that huge.
Regards,
Simon
PATCH 2/4 video: tegra: Move to using simple-panel and pwm-backlight
In reply to Simon GlassWe have standard drivers for panels and backlights which can do most of the work for us. Move the tegra20 LCD driver over to use those instead of custom code.
This patch includes device tree changes for the nvidia boards. I have only been able to test seaboard. If this patch is applied, these boards will also need to be synced with the kernel, and updated to use display-timings:
- colibri
- medcom-wide
- paz00
- tec
---
arch/arm/dts/tegra20-harmony.dts | 751 ++++++++++++++++++++++++++++++++++++-- arch/arm/dts/tegra20-seaboard.dts | 45 +-- arch/arm/dts/tegra20-ventana.dts | 685 ++++++++++++++++++++++++++++++++-- configs/colibri_t20_defconfig | 5 +- configs/harmony_defconfig | 5 +- configs/medcom-wide_defconfig | 5 +- configs/paz00_defconfig | 5 +- configs/seaboard_defconfig | 5 +- configs/tec_defconfig | 5 +- configs/ventana_defconfig | 5 +- drivers/video/tegra.c | 312 +++------------- 11 files changed, 1482 insertions(+), 346 deletions(-)
arch/arm/dts/tegra20-harmony.dts +724 -27
@@ -1,5 +1,6 @@ /dts-v1/; +#include <dt-bindings/input/input.h> #include "tegra20.dtsi" / {
@@ -11,6 +12,9 @@ }; aliases { + rtc0 = "/i2c at 7000d000/tps6586x at 34"; + rtc1 = "/rtc at 7000e000"; + serial0 = &uartd; usb0 = "/usb at c5008000"; usb1 = "/usb at c5004000"; sdhci0 = "/sdhci at c8000600";
@@ -27,15 +31,295 @@ status = "okay"; rgb { status = "okay"; - nvidia,panel = <&lcd_panel>; + + nvidia,panel = <&panel>; + + display-timings { + timing at 0 { + /* Seaboard has 1366x768 */ + clock-frequency = <42430000>; + hactive = <1024>; + vactive = <600>; + hback-porch = <138>; + hfront-porch = <34>; + hsync-len = <136>; + vback-porch = <21>; + vfront-porch = <4>; + vsync-len = <4>; + }; + }; + }; + }; + + hdmi at 54280000 { + status = "okay"; + + hdmi-supply = <&vdd_5v0_hdmi>; + vdd-supply = <&hdmi_vdd_reg>; + pll-supply = <&hdmi_pll_reg>; + + nvidia,ddc-i2c-bus = <&hdmi_ddc>; + nvidia,hpd-gpio = <&gpio TEGRA_GPIO(N, 7) + GPIO_ACTIVE_HIGH>; + }; + }; + + pinmux at 70000014 { + pinctrl-names = "default"; + pinctrl-0 = <&state_default>; + + state_default: pinmux { + ata { + nvidia,pins = "ata"; + nvidia,function = "ide"; + }; + atb { + nvidia,pins = "atb", "gma", "gme"; + nvidia,function = "sdio4"; + }; + atc { + nvidia,pins = "atc"; + nvidia,function = "nand"; + }; + atd { + nvidia,pins = "atd", "ate", "gmb", "gmd", "gpu", + "spia", "spib", "spic"; + nvidia,function = "gmi"; + }; + 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 = "vi_sensor_clk"; + }; + dap1 { + nvidia,pins = "dap1"; + nvidia,function = "dap1"; + }; + dap2 { + nvidia,pins = "dap2"; + nvidia,function = "dap2"; + }; + 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", "dtd"; + nvidia,function = "sdio2"; + }; + dtb { + nvidia,pins = "dtb", "dtc", "dte"; + nvidia,function = "rsvd1"; + }; + dtf { + nvidia,pins = "dtf"; + nvidia,function = "i2c3"; + }; + gmc { + nvidia,pins = "gmc"; + nvidia,function = "uartd"; + }; + 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", "kbcb", "kbcc", "kbcd", + "kbce", "kbcf"; + nvidia,function = "kbc"; + }; + 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", "spdi", "spdo", "uac"; + nvidia,function = "rsvd2"; + }; + pmc { + nvidia,pins = "pmc"; + nvidia,function = "pwr_on"; + }; + rm { + nvidia,pins = "rm"; + nvidia,function = "i2c1"; + }; + sdb { + nvidia,pins = "sdb", "sdc", "sdd"; + nvidia,function = "pwm"; + }; + sdio1 { + nvidia,pins = "sdio1"; + nvidia,function = "sdio1"; + }; + slxc { + nvidia,pins = "slxc", "slxd"; + nvidia,function = "spdif"; + }; + spid { + nvidia,pins = "spid", "spie", "spif"; + nvidia,function = "spi1"; + }; + spig { + nvidia,pins = "spig", "spih"; + nvidia,function = "spi2_alt"; + }; + uaa { + nvidia,pins = "uaa", "uab", "uda"; + nvidia,function = "ulpi"; + }; + uad { + nvidia,pins = "uad"; + nvidia,function = "irda"; + }; + uca { + nvidia,pins = "uca", "ucb"; + nvidia,function = "uartc"; + }; + conf_ata { + nvidia,pins = "ata", "atb", "atc", "atd", "ate", + "cdev1", "cdev2", "dap1", "dtb", "gma", + "gmb", "gmc", "gmd", "gme", "gpu7", + "gpv", "i2cp", "pta", "rm", "slxa", + "slxk", "spia", "spib", "uac"; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + conf_ck32 { + nvidia,pins = "ck32", "ddrc", "pmca", "pmcb", + "pmcc", "pmcd", "pmce", "xm2c", "xm2d"; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + }; + conf_csus { + nvidia,pins = "csus", "spid", "spif"; + nvidia,pull = <TEGRA_PIN_PULL_DOWN>; + nvidia,tristate = <TEGRA_PIN_ENABLE>; + }; + conf_crtp { + nvidia,pins = "crtp", "dap2", "dap3", "dap4", + "dtc", "dte", "dtf", "gpu", "sdio1", + "slxc", "slxd", "spdi", "spdo", "spig", + "uda"; + nvidia,pull = <TEGRA_PIN_PULL_NONE>; + nvidia,tristate = <TEGRA_PIN_ENABLE>; + }; + conf_ddc { + nvidia,pins = "ddc", "dta", "dtd", "kbca", + "kbcb", "kbcc", "kbcd", "kbce", "kbcf", + "sdc"; + nvidia,pull = <TEGRA_PIN_PULL_UP>; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + conf_hdint { + nvidia,pins = "hdint", "lcsn", "ldc", "lm1", + "lpw1", "lsc1", "lsck", "lsda", "lsdi", + "lvp0", "owc", "sdb"; + nvidia,tristate = <TEGRA_PIN_ENABLE>; + }; + conf_irrx { + nvidia,pins = "irrx", "irtx", "sdd", "spic", + "spie", "spih", "uaa", "uab", "uad", + "uca", "ucb"; + nvidia,pull = <TEGRA_PIN_PULL_UP>; + nvidia,tristate = <TEGRA_PIN_ENABLE>; + }; + conf_lc { + nvidia,pins = "lc", "ls"; + nvidia,pull = <TEGRA_PIN_PULL_UP>; + }; + conf_ld0 { + nvidia,pins = "ld0", "ld1", "ld2", "ld3", "ld4", + "ld5", "ld6", "ld7", "ld8", "ld9", + "ld10", "ld11", "ld12", "ld13", "ld14", + "ld15", "ld16", "ld17", "ldi", "lhp0", + "lhp1", "lhp2", "lhs", "lm0", "lpp", + "lpw0", "lpw2", "lsc0", "lspi", "lvp1", + "lvs", "pmc"; + nvidia,tristate = <TEGRA_PIN_DISABLE>; + }; + conf_ld17_0 { + nvidia,pins = "ld17_0", "ld19_18", "ld21_20", + "ld23_22"; + nvidia,pull = <TEGRA_PIN_PULL_DOWN>; }; }; }; + i2s at 70002800 { + status = "okay"; + }; + serial at 70006300 { + status = "okay"; clock-frequency = < 216000000 >; }; + pwm: pwm at 7000a000 { + status = "okay"; + }; + + i2c at 7000c000 { + status = "okay"; + clock-frequency = <400000>; + + wm8903: wm8903 at 1a { + compatible = "wlf,wm8903"; + reg = <0x1a>; + interrupt-parent = <&gpio>; + interrupts = <TEGRA_GPIO(X, 3) IRQ_TYPE_LEVEL_HIGH>; + + gpio-controller; + #gpio-cells = <2>; + + micdet-cfg = <0>; + micdet-delay = <100>; + gpio-cfg = <0xffffffff 0xffffffff 0 0xffffffff 0xffffffff>; + }; + }; + nand-controller at 70008000 { nvidia,wp-gpios = <&gpio TEGRA_GPIO(C, 7) GPIO_ACTIVE_HIGH>; nvidia,width = <8>;
@@ -46,15 +330,319 @@ }; }; + hdmi_ddc: i2c at 7000c400 { + status = "okay"; + clock-frequency = <100000>; + }; + + i2c at 7000c500 { + status = "okay"; + clock-frequency = <400000>; + }; + + i2c at 7000d000 { + status = "okay"; + clock-frequency = <400000>; + + pmic: tps6586x at 34 { + compatible = "ti,tps6586x"; + reg = <0x34>; + interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>; + + ti,system-power-controller; + + #gpio-cells = <2>; + gpio-controller; + + sys-supply = <&vdd_5v0_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 { + sys_reg: sys { + regulator-name = "vdd_sys"; + regulator-always-on; + }; + + sm0 { + regulator-name = "vdd_sm0,vdd_core"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-always-on; + }; + + sm1 { + regulator-name = "vdd_sm1,vdd_cpu"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + }; + + sm2_reg: sm2 { + regulator-name = "vdd_sm2,vin_ldo*"; + regulator-min-microvolt = <3700000>; + regulator-max-microvolt = <3700000>; + regulator-always-on; + }; + + pci_clk_reg: ldo0 { + regulator-name = "vdd_ldo0,vddio_pex_clk"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + ldo1 { + regulator-name = "vdd_ldo1,avdd_pll*"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <1100000>; + regulator-always-on; + }; + + ldo2 { + regulator-name = "vdd_ldo2,vdd_rtc"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + + ldo3 { + regulator-name = "vdd_ldo3,avdd_usb*"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + + ldo4 { + regulator-name = "vdd_ldo4,avdd_osc,vddio_sys"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + }; + + ldo5 { + regulator-name = "vdd_ldo5,vcore_mmc"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <2850000>; + regulator-always-on; + }; + + ldo6 { + regulator-name = "vdd_ldo6,avdd_vdac"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + hdmi_vdd_reg: ldo7 { + regulator-name = "vdd_ldo7,avdd_hdmi"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + }; + + hdmi_pll_reg: ldo8 { + regulator-name = "vdd_ldo8,avdd_hdmi_pll"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + }; + + ldo9 { + regulator-name = "vdd_ldo9,avdd_2v85,vdd_ddr_rx"; + regulator-min-microvolt = <2850000>; + regulator-max-microvolt = <2850000>; + regulator-always-on; + }; + + ldo_rtc { + regulator-name = "vdd_rtc_out,vdd_cell"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + }; + }; + }; + + temperature-sensor at 4c { + compatible = "adi,adt7461"; + reg = <0x4c>; + }; + }; + + kbc at 7000e200 { + status = "okay"; + nvidia,debounce-delay-ms = <2>; + nvidia,repeat-delay-ms = <160>; + nvidia,kbc-row-pins = <0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15>; + nvidia,kbc-col-pins = <16 17 18 19 20 21 22 23>; + linux,keymap = <MATRIX_KEY(0x00, 0x02, KEY_W) + MATRIX_KEY(0x00, 0x03, KEY_S) + MATRIX_KEY(0x00, 0x04, KEY_A) + MATRIX_KEY(0x00, 0x05, KEY_Z) + MATRIX_KEY(0x00, 0x07, KEY_FN) + MATRIX_KEY(0x01, 0x07, KEY_MENU) + MATRIX_KEY(0x02, 0x06, KEY_LEFTALT) + MATRIX_KEY(0x02, 0x07, KEY_RIGHTALT) + MATRIX_KEY(0x03, 0x00, KEY_5) + MATRIX_KEY(0x03, 0x01, KEY_4) + MATRIX_KEY(0x03, 0x02, KEY_R) + MATRIX_KEY(0x03, 0x03, KEY_E) + MATRIX_KEY(0x03, 0x04, KEY_F) + MATRIX_KEY(0x03, 0x05, KEY_D) + MATRIX_KEY(0x03, 0x06, KEY_X) + MATRIX_KEY(0x04, 0x00, KEY_7) + MATRIX_KEY(0x04, 0x01, KEY_6) + MATRIX_KEY(0x04, 0x02, KEY_T) + MATRIX_KEY(0x04, 0x03, KEY_H) + MATRIX_KEY(0x04, 0x04, KEY_G) + MATRIX_KEY(0x04, 0x05, KEY_V) + MATRIX_KEY(0x04, 0x06, KEY_C) + MATRIX_KEY(0x04, 0x07, KEY_SPACE) + MATRIX_KEY(0x05, 0x00, KEY_9) + MATRIX_KEY(0x05, 0x01, KEY_8) + MATRIX_KEY(0x05, 0x02, KEY_U) + MATRIX_KEY(0x05, 0x03, KEY_Y) + MATRIX_KEY(0x05, 0x04, KEY_J) + MATRIX_KEY(0x05, 0x05, KEY_N) + MATRIX_KEY(0x05, 0x06, KEY_B) + MATRIX_KEY(0x05, 0x07, KEY_BACKSLASH) + MATRIX_KEY(0x06, 0x00, KEY_MINUS) + MATRIX_KEY(0x06, 0x01, KEY_0) + MATRIX_KEY(0x06, 0x02, KEY_O) + MATRIX_KEY(0x06, 0x03, KEY_I) + MATRIX_KEY(0x06, 0x04, KEY_L) + MATRIX_KEY(0x06, 0x05, KEY_K) + MATRIX_KEY(0x06, 0x06, KEY_COMMA) + MATRIX_KEY(0x06, 0x07, KEY_M) + MATRIX_KEY(0x07, 0x01, KEY_EQUAL) + MATRIX_KEY(0x07, 0x02, KEY_RIGHTBRACE) + MATRIX_KEY(0x07, 0x03, KEY_ENTER) + MATRIX_KEY(0x07, 0x07, KEY_MENU) + MATRIX_KEY(0x08, 0x04, KEY_LEFTSHIFT) + MATRIX_KEY(0x08, 0x05, KEY_RIGHTSHIFT) + MATRIX_KEY(0x09, 0x05, KEY_LEFTCTRL) + MATRIX_KEY(0x09, 0x07, KEY_RIGHTCTRL) + MATRIX_KEY(0x0B, 0x00, KEY_LEFTBRACE) + MATRIX_KEY(0x0B, 0x01, KEY_P) + MATRIX_KEY(0x0B, 0x02, KEY_APOSTROPHE) + MATRIX_KEY(0x0B, 0x03, KEY_SEMICOLON) + MATRIX_KEY(0x0B, 0x04, KEY_SLASH) + MATRIX_KEY(0x0B, 0x05, KEY_DOT) + MATRIX_KEY(0x0C, 0x00, KEY_F10) + MATRIX_KEY(0x0C, 0x01, KEY_F9) + MATRIX_KEY(0x0C, 0x02, KEY_BACKSPACE) + MATRIX_KEY(0x0C, 0x03, KEY_3) + MATRIX_KEY(0x0C, 0x04, KEY_2) + MATRIX_KEY(0x0C, 0x05, KEY_UP) + MATRIX_KEY(0x0C, 0x06, KEY_PRINT) + MATRIX_KEY(0x0C, 0x07, KEY_PAUSE) + MATRIX_KEY(0x0D, 0x00, KEY_INSERT) + MATRIX_KEY(0x0D, 0x01, KEY_DELETE) + MATRIX_KEY(0x0D, 0x03, KEY_PAGEUP ) + MATRIX_KEY(0x0D, 0x04, KEY_PAGEDOWN) + MATRIX_KEY(0x0D, 0x05, KEY_RIGHT) + MATRIX_KEY(0x0D, 0x06, KEY_DOWN) + MATRIX_KEY(0x0D, 0x07, KEY_LEFT) + MATRIX_KEY(0x0E, 0x00, KEY_F11) + MATRIX_KEY(0x0E, 0x01, KEY_F12) + MATRIX_KEY(0x0E, 0x02, KEY_F8) + MATRIX_KEY(0x0E, 0x03, KEY_Q) + MATRIX_KEY(0x0E, 0x04, KEY_F4) + MATRIX_KEY(0x0E, 0x05, KEY_F3) + MATRIX_KEY(0x0E, 0x06, KEY_1) + MATRIX_KEY(0x0E, 0x07, KEY_F7) + MATRIX_KEY(0x0F, 0x00, KEY_ESC) + MATRIX_KEY(0x0F, 0x01, KEY_GRAVE) + MATRIX_KEY(0x0F, 0x02, KEY_F5) + MATRIX_KEY(0x0F, 0x03, KEY_TAB) + MATRIX_KEY(0x0F, 0x04, KEY_F1) + MATRIX_KEY(0x0F, 0x05, KEY_F2) + MATRIX_KEY(0x0F, 0x06, KEY_CAPSLOCK) + MATRIX_KEY(0x0F, 0x07, KEY_F6) + MATRIX_KEY(0x14, 0x00, KEY_KP7) + MATRIX_KEY(0x15, 0x00, KEY_KP9) + MATRIX_KEY(0x15, 0x01, KEY_KP8) + MATRIX_KEY(0x15, 0x02, KEY_KP4) + MATRIX_KEY(0x15, 0x04, KEY_KP1) + MATRIX_KEY(0x16, 0x01, KEY_KPSLASH) + MATRIX_KEY(0x16, 0x02, KEY_KP6) + MATRIX_KEY(0x16, 0x03, KEY_KP5) + MATRIX_KEY(0x16, 0x04, KEY_KP3) + MATRIX_KEY(0x16, 0x05, KEY_KP2) + MATRIX_KEY(0x16, 0x07, KEY_KP0) + MATRIX_KEY(0x1B, 0x01, KEY_KPASTERISK) + MATRIX_KEY(0x1B, 0x03, KEY_KPMINUS) + MATRIX_KEY(0x1B, 0x04, KEY_KPPLUS) + MATRIX_KEY(0x1B, 0x05, KEY_KPDOT) + MATRIX_KEY(0x1C, 0x05, KEY_VOLUMEUP) + MATRIX_KEY(0x1D, 0x03, KEY_HOME) + MATRIX_KEY(0x1D, 0x04, KEY_END) + MATRIX_KEY(0x1D, 0x05, KEY_BRIGHTNESSUP) + MATRIX_KEY(0x1D, 0x06, KEY_VOLUMEDOWN) + MATRIX_KEY(0x1D, 0x07, KEY_BRIGHTNESSDOWN) + MATRIX_KEY(0x1E, 0x00, KEY_NUMLOCK) + MATRIX_KEY(0x1E, 0x01, KEY_SCROLLLOCK) + MATRIX_KEY(0x1E, 0x02, KEY_MUTE) + MATRIX_KEY(0x1F, 0x04, KEY_QUESTION)>; + }; + + pmc at 7000e400 { + nvidia,invert-interrupt; + nvidia,suspend-mode = <1>; + nvidia,cpu-pwr-good-time = <5000>; + nvidia,cpu-pwr-off-time = <5000>; + nvidia,core-pwr-good-time = <3845 3845>; + nvidia,core-pwr-off-time = <3875>; + nvidia,sys-clock-req-active-high; + }; + + pcie-controller at 80003000 { + status = "okay"; + + avdd-pex-supply = <&pci_vdd_reg>; + vdd-pex-supply = <&pci_vdd_reg>; + avdd-pex-pll-supply = <&pci_vdd_reg>; + avdd-plle-supply = <&pci_vdd_reg>; + vddio-pex-clk-supply = <&pci_clk_reg>; + + pci at 1,0 { + status = "okay"; + }; + + pci at 2,0 { + status = "okay"; + }; + }; + + usb at c5000000 { + status = "okay"; + }; + + usb-phy at c5000000 { + status = "okay"; + }; + usb at c5004000 { - statuc = "okay"; + status = "okay"; nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1) 0>; }; + usb-phy at c5004000 { + status = "okay"; + nvidia,phy-reset-gpio = <&gpio TEGRA_GPIO(V, 1) + GPIO_ACTIVE_LOW>; + }; + usb at c5008000 { status = "okay"; }; + usb-phy at c5008000 { + status = "okay"; + }; + sdhci at c8000200 { status = "okay"; cd-gpios = <&gpio TEGRA_GPIO(I, 5) GPIO_ACTIVE_LOW>;
@@ -71,6 +659,17 @@ bus-width = <8>; }; + backlight: backlight { + compatible = "pwm-backlight"; + + enable-gpios = <&gpio TEGRA_GPIO(B, 5) GPIO_ACTIVE_HIGH>; + power-supply = <&vdd_bl_reg>; + pwms = <&pwm 0 5000000>; + + brightness-levels = <0 4 8 16 32 64 128 255>; + default-brightness-level = <6>; + }; + clocks { compatible = "simple-bus"; #address-cells = <1>;
@@ -84,32 +683,130 @@ }; }; - pwm: pwm at 7000a000 { - status = "okay"; + gpio-keys { + compatible = "gpio-keys"; + + power { + label = "Power"; + gpios = <&gpio TEGRA_GPIO(V, 2) GPIO_ACTIVE_LOW>; + linux,code = <KEY_POWER>; + gpio-key,wakeup; + }; + }; + + panel: panel { + compatible = "auo,b101aw03", "simple-panel"; + + power-supply = <&vdd_pnl_reg>; + enable-gpios = <&gpio TEGRA_GPIO(B, 2) GPIO_ACTIVE_HIGH>; + + backlight = <&backlight>; }; - lcd_panel: panel { - clock = <42430000>; - xres = <1024>; - yres = <600>; - left-margin = <138>; - right-margin = <34>; - hsync-len = <136>; - lower-margin = <4>; - upper-margin = <21>; - vsync-len = <4>; - hsync-active-high; - vsyncx-active-high; - nvidia,bits-per-pixel = <16>; - nvidia,pwm = <&pwm 0 0>; - nvidia,backlight-enable-gpios = <&gpio TEGRA_GPIO(B, 5) - GPIO_ACTIVE_HIGH>; - nvidia,lvds-shutdown-gpios = <&gpio TEGRA_GPIO(B, 2) - GPIO_ACTIVE_HIGH>; - nvidia,backlight-vdd-gpios = <&gpio TEGRA_GPIO(W, 0) - GPIO_ACTIVE_HIGH>; - nvidia,panel-vdd-gpios = <&gpio TEGRA_GPIO(C, 6) - GPIO_ACTIVE_HIGH>; - nvidia,panel-timings = <0 0 200 0 0>; + regulators { + compatible = "simple-bus"; + #address-cells = <1>; + #size-cells = <0>; + + vdd_5v0_reg: regulator at 0 { + compatible = "regulator-fixed"; + reg = <0>; + regulator-name = "vdd_5v0"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + regulator-always-on; + }; + + regulator at 1 { + compatible = "regulator-fixed"; + reg = <1>; + regulator-name = "vdd_1v5"; + regulator-min-microvolt = <1500000>; + regulator-max-microvolt = <1500000>; + gpio = <&pmic 0 GPIO_ACTIVE_HIGH>; + }; + + regulator at 2 { + compatible = "regulator-fixed"; + reg = <2>; + regulator-name = "vdd_1v2"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + gpio = <&pmic 1 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + pci_vdd_reg: regulator at 3 { + compatible = "regulator-fixed"; + reg = <3>; + regulator-name = "vdd_1v05"; + regulator-min-microvolt = <1050000>; + regulator-max-microvolt = <1050000>; + gpio = <&pmic 2 GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vdd_pnl_reg: regulator at 4 { + compatible = "regulator-fixed"; + reg = <4>; + regulator-name = "vdd_pnl"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + gpio = <&gpio TEGRA_GPIO(C, 6) GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vdd_bl_reg: regulator at 5 { + compatible = "regulator-fixed"; + reg = <5>; + regulator-name = "vdd_bl"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + gpio = <&gpio TEGRA_GPIO(W, 0) GPIO_ACTIVE_HIGH>; + enable-active-high; + }; + + vdd_5v0_hdmi: regulator at 6 { + compatible = "regulator-fixed"; + reg = <6>; + regulator-name = "VDDIO_HDMI"; + regulator-min-microvolt = <5000000>; + regulator-max-microvolt = <5000000>; + gpio = <&gpio TEGRA_GPIO(T, 2) GPIO_ACTIVE_HIGH>; + enable-active-high; + vin-supply = <&vdd_5v0_reg>; + }; + }; + + sound { + compatible = "nvidia,tegra-audio-wm8903-harmony", + "nvidia,tegra-audio-wm8903"; + nvidia,model = "NVIDIA Tegra Harmony"; + + nvidia,audio-routing = + "Headphone Jack", "HPOUTR", + "Headphone Jack", "HPOUTL", + "Int Spk", "ROP", + "Int Spk", "RON", + "Int Spk", "LOP", + "Int Spk", "LON", + "Mic Jack", "MICBIAS", + "IN1L", "Mic Jack"; + + nvidia,i2s-controller = <&tegra_i2s1>; + nvidia,audio-codec = <&wm8903>; + + nvidia,spkr-en-gpios = <&wm8903 2 GPIO_ACTIVE_HIGH>; + nvidia,hp-det-gpios = <&gpio TEGRA_GPIO(W, 2) + GPIO_ACTIVE_HIGH>; + nvidia,int-mic-en-gpios = <&gpio TEGRA_GPIO(X, 0) + GPIO_ACTIVE_HIGH>; + nvidia,ext-mic-en-gpios = <&gpio TEGRA_GPIO(X, 1) + GPIO_ACTIVE_HIGH>; + + clocks = <&tegra_car TEGRA20_CLK_PLL_A>, + <&tegra_car TEGRA20_CLK_PLL_A_OUT0>, + <&tegra_car TEGRA20_CLK_CDEV1>; + clock-names = "pll_a", "pll_a_out0", "mclk"; }; };
arch/arm/dts/tegra20-seaboard.dts +23 -22
57 lines not on this page · raw message
arch/arm/dts/tegra20-ventana.dts +658 -27
726 lines not on this page · raw message
configs/colibri_t20_defconfig +4 -1
@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Medcom-Wide) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y
@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=y
configs/harmony_defconfig +4 -1
@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Harmony) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y
@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=y
configs/medcom-wide_defconfig +4 -1
@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Medcom-Wide) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y
@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=y
configs/paz00_defconfig +4 -1
@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Paz00) MOD # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y
@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=y
configs/seaboard_defconfig +4 -1
@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (SeaBoard) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y
@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=y
configs/tec_defconfig +4 -1
@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (TEC) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y
@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=y
configs/ventana_defconfig +4 -1
@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Ventana) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y
@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=y
drivers/video/tegra.c +49 -263
412 lines not on this page · raw message
Signature · 1 line
2.6.0.rc2.230.g3dd15c0
PATCH 2/4 video: tegra: Move to using simple-panel and pwm-backlight
arch/arm/dts/tegra20-harmony.dts
Quoted 14 lines · Simon Glass
We have standard drivers for panels and backlights which can do most of the work for us. Move the tegra20 LCD driver over to use those instead of custom code.
This patch includes device tree changes for the nvidia boards. I have only been able to test seaboard. If this patch is applied, these boards will also need to be synced with the kernel, and updated to use display-timings:
- colibri
- medcom-wide
- paz00
- tecarch/arm/dts/tegra20-harmony.dts +0
-0
This file has huge changes unrelated to panel, video, and backlight. Perhaps patch 1/4 was meant to sync the DTs for Harmony and Ventana too rather than just Seaboard, leaving this commit to make roughly identical DT changes for all 3 boards?
Quoted 8 lines
arch/arm/dts/tegra20-seaboard.dts +6
-0+ + display-timings { + timing at 0 { + /* Seaboard has 1366x768 */ + clock-frequency = <70600000>; + hactive = <1366>;
arch/arm/dts/tegra20-seaboard.dts line 60
Quoted 10 lines
arch/arm/dts/tegra20-seaboard.dts +10
-0+ vactive = <768>; + hback-porch = <58>; + hfront-porch = <58>; + hsync-len = <58>; + vback-porch = <4>; + vfront-porch = <4>; + vsync-len = <4>; + hsync-active = <1>; + }; + };
It seems very strange to go to the effort of creating patch 1 to sync the U-Boot and Linux DT files (such that I assume they're 100% identical?) yet immediately have patch 2 diverge the two DTs again.
This lends more weight to my argument that the U-Boot DTs should contain only nodes that U-Boot actively uses. I can see the argument for copying over the entire DT from Linux into U-Boot in order to keep them 100% identical, and in turn that means importing a bunch of DT content that U-Boot doesn't use. However, that argument completely breaks down if the DTs are just going to diverge still.
At least the display-timings node is a standard binding, even if it isn't one that the Linux Tegra DTs make use of.
Quoted 18 lines
configs/harmony_defconfig +3
-1@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Harmony) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y
configs/harmony_defconfig CONFIG_DM_USB=y · line 27
Quoted 4 lines
configs/harmony_defconfig +1
-0@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=y
I assume those are all needed by the modified Tegra video/LCD driver. If so, wouldn't it make sense for that driver to select those Kconfig options rather than requiring every board defconfig to be modified to enable the features?
PATCH 2/4 video: tegra: Move to using simple-panel and pwm-backlight
Hi Stephen,
Quoted 19 lines · Stephen Warren
Quoted 16 lines · Simon Glass
We have standard drivers for panels and backlights which can do most of the
work for us. Move the tegra20 LCD driver over to use those instead of custom
code.This patch includes device tree changes for the nvidia boards. I have only been able to test seaboard. If this patch is applied, these boards will also need to be synced with the kernel, and updated to use display-timings:
- colibri
- medcom-wide
- paz00
- tec
Quoted 8 lines
arch/arm/dts/tegra20-harmony.dts
Quoted 2 lines
arch/arm/dts/tegra20-harmony.dts +0
-0This file has huge changes unrelated to panel, video, and backlight. Perhaps patch 1/4 was meant to sync the DTs for Harmony and Ventana too rather than just Seaboard, leaving this commit to make roughly identical DT changes for all 3 boards?
Yes I think that would be better. I started on seaboard since that's the only one I have. But then I thought I could do the other two since you or Tom should be able to test it.
Quoted 36 lines
Quoted 13 lines
arch/arm/dts/tegra20-seaboard.dts +4
-0+ + display-timings { + timing at 0 { + /* Seaboard has 1366x768*/
+ clock-frequency =
<70600000>;arch/arm/dts/tegra20-seaboard.dts +1
-0+ hactive = <1366>;arch/arm/dts/tegra20-seaboard.dts line 60
Quoted 10 lines
arch/arm/dts/tegra20-seaboard.dts +10
-0+ vactive = <768>; + hback-porch = <58>; + hfront-porch = <58>; + hsync-len = <58>; + vback-porch = <4>; + vfront-porch = <4>; + vsync-len = <4>; + hsync-active = <1>; + }; + };It seems very strange to go to the effort of creating patch 1 to sync the U-Boot and Linux DT files (such that I assume they're 100% identical?) yet immediately have patch 2 diverge the two DTs again.
This lends more weight to my argument that the U-Boot DTs should contain only nodes that U-Boot actively uses. I can see the argument for copying over the entire DT from Linux into U-Boot in order to keep them 100% identical, and in turn that means importing a bunch of DT content that U-Boot doesn't use. However, that argument completely breaks down if the DTs are just going to diverge still.
Quoted 2 lines
At least the display-timings node is a standard binding, even if it isn't one that the Linux Tegra DTs make use of.
How about adding this to the Linux Tegra DT? It's a hardware description so shouldn't ruffle too many feathres.
Quoted 21 lines
Quoted 21 lines
configs/harmony_defconfig +3
-1@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Harmony) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y
Quoted 8 lines
configs/harmony_defconfig CONFIG_DM_USB=y · line 27
Quoted 2 lines
configs/harmony_defconfig +1
-0CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=yI assume those are all needed by the modified Tegra video/LCD driver. If so, wouldn't it make sense for that driver to select those
Kconfigoptions rather than requiring every board defconfig to be modified to enable the features?
Do you mean 'depends on' in the Kconfig? This is a discussion that goes back and forth...I don't really mind. It would mean that you would have to play detective in menuconfig to turn the display on for a board: find all the options it depends on, turn them on one by one and then the display option appears.
Regards,
Simon
PATCH 2/4 video: tegra: Move to using simple-panel and pwm-backlight
Quoted 107 lines · Simon Glass
Hi Stephen,
Quoted 19 lines · Stephen Warren
Quoted 16 lines · Simon Glass
We have standard drivers for panels and backlights which can do most of the
work for us. Move the tegra20 LCD driver over to use those instead of custom
code.This patch includes device tree changes for the nvidia boards. I have only been able to test seaboard. If this patch is applied, these boards will also need to be synced with the kernel, and updated to use display-timings:
- colibri
- medcom-wide
- paz00
- tecQuoted 8 lines
arch/arm/dts/tegra20-harmony.dts
Quoted 2 lines
arch/arm/dts/tegra20-harmony.dts +0
-0This file has huge changes unrelated to panel, video, and backlight. Perhaps patch 1/4 was meant to sync the DTs for Harmony and Ventana too rather than just Seaboard, leaving this commit to make roughly identical DT changes for all 3 boards?
Yes I think that would be better. I started on seaboard since that's the only one I have. But then I thought I could do the other two since you or Tom should be able to test it.
Quoted 36 lines
Quoted 13 lines
arch/arm/dts/tegra20-seaboard.dts +4
-0+ + display-timings { + timing at 0 { + /* Seaboard has 1366x768*/
+ clock-frequency =
<70600000>;arch/arm/dts/tegra20-seaboard.dts +1
-0+ hactive = <1366>;arch/arm/dts/tegra20-seaboard.dts line 60
Quoted 10 lines
arch/arm/dts/tegra20-seaboard.dts +10
-0+ vactive = <768>; + hback-porch = <58>; + hfront-porch = <58>; + hsync-len = <58>; + vback-porch = <4>; + vfront-porch = <4>; + vsync-len = <4>; + hsync-active = <1>; + }; + };It seems very strange to go to the effort of creating patch 1 to sync the U-Boot and Linux DT files (such that I assume they're 100% identical?) yet immediately have patch 2 diverge the two DTs again.
This lends more weight to my argument that the U-Boot DTs should contain only nodes that U-Boot actively uses. I can see the argument for copying over the entire DT from Linux into U-Boot in order to keep them 100% identical, and in turn that means importing a bunch of DT content that U-Boot doesn't use. However, that argument completely breaks down if the DTs are just going to diverge still.
Quoted 2 lines
At least the display-timings node is a standard binding, even if it isn't one that the Linux Tegra DTs make use of.
How about adding this to the Linux Tegra DT? It's a hardware description so shouldn't ruffle too many feathres.
Quoted 21 lines
Quoted 21 lines
configs/harmony_defconfig +3
-1@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Harmony) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=yQuoted 8 lines
configs/harmony_defconfig CONFIG_DM_USB=y · line 27
Quoted 2 lines
configs/harmony_defconfig +1
-0CONFIG_USE_PRIVATE_LIBGCC=y +CONFIG_ERRNO_STR=yI assume those are all needed by the modified Tegra video/LCD driver. If so, wouldn't it make sense for that driver to select those
Kconfigoptions rather than requiring every board defconfig to be modified to enable the features?
Quoted 5 lines
Do you mean 'depends on' in the
Kconfig? This is a discussion that goes back and forth...I don't really mind. It would mean that you would have to play detective in menuconfig to turn the display on for a board: find all the options it depends on, turn them on one by one and then the display option appears.
I was thinking of "select" in Kconfig, so that if someone enables Tegra LCD/display support then regulators etc. get automatically enabled too.
But "depends" would work too.
PATCH 2/4 video: tegra: Move to using simple-panel and pwm-backlight
Hi Stephen,
Quoted 127 lines · Stephen Warren
Quoted 118 lines · Simon Glass
Hi Stephen,
Quoted 22 lines · Stephen Warren
Quoted 17 lines · Simon Glass
We have standard drivers for panels and backlights which can do most of the
work for us. Move the tegra20 LCD driver over to use those instead of custom
code.This patch includes device tree changes for the nvidia boards. I have only been able to test seaboard. If this patch is applied, these boards will also need to be synced with the kernel, and updated to use display-timings:
- colibri
- medcom-wide
- paz00
- tecQuoted 9 lines
arch/arm/dts/tegra20-harmony.dts
Quoted 2 lines
arch/arm/dts/tegra20-harmony.dts +0
-0This file has huge changes unrelated to panel, video, and backlight. Perhaps patch 1/4 was meant to sync the DTs for Harmony and Ventana too rather than just Seaboard, leaving this commit to make roughly identical DT changes for all 3 boards?
Yes I think that would be better. I started on seaboard since that's the only one I have. But then I thought I could do the other two since you or Tom should be able to test it.
Quoted 38 lines
Quoted 14 lines
arch/arm/dts/tegra20-seaboard.dts +4
-0+ + display-timings { + timing at 0 { + /* Seaboard has 1366x768*/
+ clock-frequency =
<70600000>;arch/arm/dts/tegra20-seaboard.dts +1
-0+ hactive = <1366>;arch/arm/dts/tegra20-seaboard.dts line 60
Quoted 10 lines
arch/arm/dts/tegra20-seaboard.dts +10
-0+ vactive = <768>; + hback-porch = <58>; + hfront-porch = <58>; + hsync-len = <58>; + vback-porch = <4>; + vfront-porch = <4>; + vsync-len = <4>; + hsync-active = <1>; + }; + };It seems very strange to go to the effort of creating patch 1 to sync the U-Boot and Linux DT files (such that I assume they're 100% identical?) yet immediately have patch 2 diverge the two DTs again.
This lends more weight to my argument that the U-Boot DTs should contain only nodes that U-Boot actively uses. I can see the argument for copying over the entire DT from Linux into U-Boot in order to keep them 100% identical, and in turn that means importing a bunch of DT content that U-Boot doesn't use. However, that argument completely breaks down if the DTs are just going to diverge still.
Quoted 2 lines
At least the display-timings node is a standard binding, even if it isn't one that the Linux Tegra DTs make use of.
How about adding this to the Linux Tegra DT? It's a hardware description so shouldn't ruffle too many feathres.
Quoted 22 lines
Quoted 22 lines
configs/harmony_defconfig +3
-1@@ -12,9 +12,11 @@ CONFIG_SYS_PROMPT="Tegra20 (Harmony) # " CONFIG_CMD_GPIO=y # CONFIG_CMD_SETEXPR is not set # CONFIG_CMD_NFS is not set +CONFIG_CMD_PMIC=y +CONFIG_CMD_REGULATOR=y CONFIG_DM_PMIC=y CONFIG_DM_REGULATOR=y -CONFIG_DM_PWM=y +CONFIG_DM_REGULATOR_FIXED=y CONFIG_PWM_TEGRA=y CONFIG_SYS_NS16550=y CONFIG_USB=y@@ -22,3 +24,4 @@ CONFIG_DM_USB=y CONFIG_DM_VIDEO=y CONFIG_VIDEO_TEGRA20=y CONFIG_USE_PRIVATE_LIBGCC=yQuoted 8 lines
configs/harmony_defconfig CONFIG_DM_USB=y · line 27
Quoted 1 line
configs/harmony_defconfig +1
-0+CONFIG_ERRNO_STR=yI assume those are all needed by the modified Tegra video/LCD driver. If so, wouldn't it make sense for that driver to select those
Kconfigoptions rather than requiring every board defconfig to be modified to enable the features?Quoted 5 lines
Do you mean 'depends on' in the
Kconfig? This is a discussion that goes back and forth...I don't really mind. It would mean that you would have to play detective in menuconfig to turn the display on for a board: find all the options it depends on, turn them on one by one and then the display option appears.
Quoted 3 lines
I was thinking of "select" in
Kconfig, so that if someone enables Tegra LCD/display support then regulators etc. get automatically enabled too.But "depends" would work too.
'select' sounds better. I'll take a look.
Regards,
Simon
PATCH 3/4 tegra: video: Always use write-through cache on LCD
In reply to Simon GlassThis seems to give the best performance, so let's use it always.
---
drivers/video/tegra.c | 21 +++------------------ 1 file changed, 3 insertions(+), 18 deletions(-)
drivers/video/tegra.c +3 -18
@@ -22,15 +22,6 @@DECLARE_GLOBAL_DATA_PTR ; -enum lcd_cache_t { -FDT_LCD_CACHE_OFF =0 , -FDT_LCD_CACHE_WRITE_THROUGH =1 <<0 , -FDT_LCD_CACHE_WRITE_BACK =1 <<1 , -FDT_LCD_CACHE_FLUSH =1 <<2 , -FDT_LCD_CACHE_WRITE_BACK_FLUSH =FDT_LCD_CACHE_WRITE_BACK | -FDT_LCD_CACHE_FLUSH , -}; -/* Information about the display controller */ struct tegra_lcd_priv {int width;/* width in pixels */
@@ -41,7 +32,6 @@ struct tegra_lcd_priv {struct disp_ctlr *disp;/* Display controller to use */ fdt_addr_t frame_buffer;/* Address of frame buffer */ unsigned pixel_clock;/* Pixel clock in Hz */ -enum lcd_cache_t cache_type; };enum {
@@ -310,7 +300,6 @@ static int tegra_lcd_probe(struct udevice *dev)struct video_priv *uc_priv =dev_get_uclass_priv (dev);struct tegra_lcd_priv *priv =dev_get_priv (dev);const void *blob = gd->fdt_blob; -int type =DCACHE_OFF ;int ret;/* Initialize the Tegra display controller */
@@ -330,15 +319,11 @@ static int tegra_lcd_probe(struct udevice *dev)return ret; } -/* Set up the LCD caching as requested */ -if (priv->cache_type &FDT_LCD_CACHE_WRITE_THROUGH ) - type =DCACHE_WRITETHROUGH ; -else if (priv->cache_type &FDT_LCD_CACHE_WRITE_BACK ) - type =DCACHE_WRITEBACK ; -mmu_set_region_dcache_behaviour (priv->frame_buffer, plat->size, type); +mmu_set_region_dcache_behaviour (priv->frame_buffer, plat->size, +DCACHE_WRITETHROUGH );/* Enable flushing after LCD writes if requested */ -video_set_flush_dcache (dev, priv->cache_type &FDT_LCD_CACHE_FLUSH ); +video_set_flush_dcache (dev, true); uc_priv->xsize = priv->width; uc_priv->ysize = priv->height;
Signature · 1 line
2.6.0.rc2.230.g3dd15c0
PATCH 3/4 tegra: video: Always use write-through cache on LCD
Quoted 1 line · Simon Glass
This seems to give the best performance, so let's use it always.
I thought we chose the current cache mode due to display corruption issues with other modes, but I tested a change that I believe does the same as this change on Seaboard without any apparent issue so,
PATCH 3/4 tegra: video: Always use write-through cache on LCD
Quoted 8 lines · Stephen Warren
Quoted 1 line · Simon Glass
This seems to give the best performance, so let's use it always.
I thought we chose the current cache mode due to display corruption issues with other modes, but I tested a change that I believe does the same as this change on Seaboard without any apparent issue so,
Acked-by Stephen Warren <[email protected]>
I think for framebuffers the best option is still write-combine, which would be something like:
DCACHE_WRITECOMBINE = DCACHE_OFF | TTB_SECT_B_MASK
on ARM v7. Did you ever benchmark that against DCACHE_WRITETHROUGH? It should be faster provided that you never read from the region.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160120/d383d45b/attachment.sig>
PATCH 3/4 tegra: video: Always use write-through cache on LCD
Hi Thierry,
Quoted 10 lines · Thierry Reding
Quoted 8 lines · Stephen Warren
Quoted 1 line · Simon Glass
This seems to give the best performance, so let's use it always.
I thought we chose the current cache mode due to display corruption issues with other modes, but I tested a change that I believe does the same as this change on Seaboard without any apparent issue so,
Acked-by Stephen Warren <[email protected]>
Quoted 7 lines
I think for framebuffers the best option is still write-combine, which would be something like:
DCACHE_WRITECOMBINE=DCACHE_OFF|TTB_SECT_B_MASKon ARM v7. Did you ever benchmark that against
DCACHE_WRITETHROUGH? It should be faster provided that you never read from the region.
This is noticeably slower in my experience. Reading from the region is pretty common - e.g. scrolling.
Regards,
Simon
PATCH 4/4 fdt: Drop some unused compatible strings
In reply to Simon GlassWe have driver-model drivers for some of these now, so drop them.
---
include/fdtdec.h | 4 ---- lib/fdtdec.c | 4 ---- 2 files changed, 8 deletions(-)
include/fdtdec.h +0 -4
@@ -119,10 +119,7 @@ enum fdt_compat_id {COMPAT_NVIDIA_TEGRA20_EMC ,/* Tegra20 memory controller */ COMPAT_NVIDIA_TEGRA20_EMC_TABLE ,/* Tegra20 memory timing table */ COMPAT_NVIDIA_TEGRA20_NAND ,/* Tegra2 NAND controller */ -COMPAT_NVIDIA_TEGRA20_PWM ,/* Tegra 2 PWM controller */ -COMPAT_NVIDIA_TEGRA124_SOR ,/* Tegra 124 Serial Output Resource */ COMPAT_NVIDIA_TEGRA124_PMC ,/* Tegra 124 power mgmt controller */ -COMPAT_NVIDIA_TEGRA20_DC ,/* Tegra 2 Display controller */ COMPAT_NVIDIA_TEGRA210_SDMMC ,/* Tegra210 SDMMC controller */ COMPAT_NVIDIA_TEGRA124_SDMMC ,/* Tegra124 SDMMC controller */ COMPAT_NVIDIA_TEGRA30_SDMMC, /* Tegra30 SDMMC controller */
@@ -145,7 +142,6 @@ enum fdt_compat_id {COMPAT_SAMSUNG_EXYNOS5_DP ,/* Exynos Display port controller */ COMPAT_SAMSUNG_EXYNOS_DWMMC ,/* Exynos DWMMC controller */ COMPAT_SAMSUNG_EXYNOS_MMC ,/* Exynos MMC controller */ -COMPAT_SAMSUNG_EXYNOS_SERIAL ,/* Exynos UART */ COMPAT_MAXIM_MAX77686_PMIC ,/* MAX77686 PMIC */ COMPAT_GENERIC_SPI_FLASH ,/* Generic SPI Flash chip */ COMPAT_MAXIM_98095_CODEC, /* MAX98095 Codec */
lib/fdtdec.c +0 -4
@@ -26,10 +26,7 @@ static const char * const compat_names[COMPAT_COUNT] = {COMPAT (NVIDIA_TEGRA20_EMC ,"nvidia,tegra20-emc" ),COMPAT (NVIDIA_TEGRA20_EMC_TABLE ,"nvidia,tegra20-emc-table" ),COMPAT (NVIDIA_TEGRA20_NAND ,"nvidia,tegra20-nand" ), -COMPAT (NVIDIA_TEGRA20_PWM ,"nvidia,tegra20-pwm" ), -COMPAT (NVIDIA_TEGRA124_SOR ,"nvidia,tegra124-sor" ),COMPAT (NVIDIA_TEGRA124_PMC ,"nvidia,tegra124-pmc" ), -COMPAT (NVIDIA_TEGRA20_DC ,"nvidia,tegra20-dc" ),COMPAT (NVIDIA_TEGRA210_SDMMC ,"nvidia,tegra210-sdhci" ),COMPAT (NVIDIA_TEGRA124_SDMMC ,"nvidia,tegra124-sdhci" ), COMPAT(NVIDIA_TEGRA30_SDMMC, "nvidia,tegra30-sdhci"),
@@ -50,7 +47,6 @@ static const char * const compat_names[COMPAT_COUNT] = {COMPAT (SAMSUNG_EXYNOS5_DP ,"samsung,exynos5-dp" ),COMPAT (SAMSUNG_EXYNOS_DWMMC ,"samsung,exynos-dwmmc" ),COMPAT (SAMSUNG_EXYNOS_MMC ,"samsung,exynos-mmc" ), -COMPAT (SAMSUNG_EXYNOS_SERIAL ,"samsung,exynos4210-uart" ),COMPAT (MAXIM_MAX77686_PMIC ,"maxim,max77686" ),COMPAT (GENERIC_SPI_FLASH ,"spi-flash" ), COMPAT(MAXIM_98095_CODEC, "maxim,max98095-codec"),
Signature · 1 line
2.6.0.rc2.230.g3dd15c0
cover tegra: Move tegra20 towards the 'new' display bindings
In reply to Simon GlassAm Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass:
Quoted 12 lines
The original tegra20 display driver was written before Linux had device tree
bindings for display. Since then Linux has developed a robust set of bindings
covering various aspects of enabling a display.This series moves closer to those bindings by using the panel and backlight
as separate drivers. The device tree files for seaboard, ventana and harmony
thereby become almost the same as Linux.
Quoted 8 lines
Unfortunately this breaks the other boards, which will need a similar sync.
So I'm not sure how easy it will be to accept this series. Still, it seems
worth sending it out in the hope that board maintainers can help. I have
kept this series separate so that it can progress separately.
By pushing display timings into the DT you are actually diverging from mainline, as mainline doesn't require this, but instead infers the timings from the panel compatible. Is this a desired goal?
Regards,
Lucas
Quoted 24 lines
Simon Glass (4):
? tegra: dts: Sync seaboard device tree file with Linux ? video: tegra: Move to using simple-panel and pwm-backlight ? tegra: video: Always use write-through cache on LCD ? fdt: Drop some unused compatible strings?arch/arm/dts/tegra20-harmony.dts??| 751
++++++++++++++++++++++++++++--
?arch/arm/dts/tegra20-seaboard.dts | 934
++++++++++++++++++++++++++++++++++----?arch/arm/dts/tegra20-ventana.dts??| 685 ++++++++++++++++++++++++++-- ?configs/colibri_t20_defconfig?????|???5 +- ?configs/harmony_defconfig?????????|???5 +- ?configs/medcom-wide_defconfig?????|???5 +- ?configs/paz00_defconfig???????????|???5 +- ?configs/seaboard_defconfig????????|???5 +- ?configs/tec_defconfig?????????????|???5 +- ?configs/ventana_defconfig?????????|???5 +- ?drivers/video/tegra.c?????????????| 333 +++----------- ?include/fdtdec.h??????????????????|???4 - ?lib/fdtdec.c??????????????????????|???4 -?13 files changed, 2307 insertions(+), 439 deletions(-)
cover tegra: Move tegra20 towards the 'new' display bindings
Hi Lucas,
Quoted 21 lines · Lucas Stach
Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass:
Quoted 12 lines
The original tegra20 display driver was written before Linux had device tree
bindings for display. Since then Linux has developed a robust set of bindings
covering various aspects of enabling a display.This series moves closer to those bindings by using the panel and backlight
as separate drivers. The device tree files for seaboard, ventana and harmony
thereby become almost the same as Linux.Quoted 8 lines
Unfortunately this breaks the other boards, which will need a similar sync.
So I'm not sure how easy it will be to accept this series. Still, it seems
worth sending it out in the hope that board maintainers can help. I have
kept this series separate so that it can progress separately.
Quoted 3 lines
By pushing display timings into the DT you are actually diverging from mainline, as mainline doesn't require this, but instead infers the timings from the panel compatible. Is this a desired goal?
This is not divergence. Please take a look at the patch series. The device tree files are very close to the same now. The existing U-Boot support has display timings in the device tree too, so this is not being added.
The display timings are a small part of the work, but in the back of my mind is that we don't want to have a big table of display panel timings as exists in Linux. This is a waste of space when a board will only use one panel.
Quoted 28 lines
Regards,
LucasQuoted 24 lines
Simon Glass (4):
tegra: dts: Sync seaboard device tree file with Linux
video: tegra: Move to using simple-panel and pwm-backlight
tegra: video: Always use write-through cache on LCD
fdt: Drop some unused compatible stringsarch/arm/dts/tegra20-harmony.dts | 751 ++++++++++++++++++++++++++++-- arch/arm/dts/tegra20-seaboard.dts | 934 ++++++++++++++++++++++++++++++++++---- arch/arm/dts/tegra20-ventana.dts | 685 ++++++++++++++++++++++++++-- configs/colibri_t20_defconfig | 5 +- configs/harmony_defconfig | 5 +- configs/medcom-wide_defconfig | 5 +- configs/paz00_defconfig | 5 +- configs/seaboard_defconfig | 5 +- configs/tec_defconfig | 5 +- configs/ventana_defconfig | 5 +- drivers/video/tegra.c | 333 +++----------- include/fdtdec.h | 4 - lib/fdtdec.c | 4 - 13 files changed, 2307 insertions(+), 439 deletions(-)
Regards,
Simon
cover tegra: Move tegra20 towards the 'new' display bindings
Quoted 24 lines · Simon Glass
Hi Lucas,
Quoted 21 lines · Lucas Stach
Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass:
Quoted 20 lines
The original tegra20 display driver was written before Linux had device tree
bindings for display. Since then Linux has developed a robust set of bindings
covering various aspects of enabling a display.This series moves closer to those bindings by using the panel and backlight
as separate drivers. The device tree files for seaboard, ventana and harmony
thereby become almost the same as Linux.Unfortunately this breaks the other boards, which will need a similar sync.
So I'm not sure how easy it will be to accept this series. Still, it seems
worth sending it out in the hope that board maintainers can help. I have
kept this series separate so that it can progress separately.
Quoted 5 lines
Quoted 3 lines
By pushing display timings into the DT you are actually diverging from mainline, as mainline doesn't require this, but instead infers the timings from the panel compatible. Is this a desired goal?
This is not divergence.
Really? The DT content is different. Isn't that the definition of divergence?
Quoted 9 lines
Please take a look at the patch series. The
device tree files are very close to the same now. The existing U-Boot support has display timings in the device tree too, so this is not being added.The display timings are a small part of the work, but in the back of my mind is that we don't want to have a big table of display panel timings as exists in Linux. This is a waste of space when a board will only use one panel.
That was rather the point of the panel-specific compatible values: To force the DT to contain a semantic definition of the type of panel, rather than a "generic" definition of timings. A benefit of the semantic representation is that if we later find bugs that need to be fixed on certain panels, if we know the panel type, then bug fixes can be applied. Equally, if we enhance the SW to require more data about the panel, that can be added to a driver without the need to change the DT, thus allowing old DTs to continue to work. More semantic rather than purely "syntactic" knowledge is available. However, if we only have a generic timing definition (or other data suitable for current SW features or code-paths), then panel-specific bug fixes will never be possible since SW can't know the identify of the panel. The disadvantage of requiring a mapping table between panel type and display timings was considered reasonable for SW stacks at which DT was targeted (i.e. main OSs rather than HW-specific bootloaders). Even so, to avoid the bloat issue, you can always just #ifdef the mapping table and end up with the same code size; even less perhaps since no timing DT parsing code is required.
At least, that was the reasoning when the DT bindings for Tegra panels were first created; IIRC there was discussion of bindings for generic panels, timings, panel power sequences, etc., and they were rejected for the reason I explained above and perhaps others. However, it does seem someone has changed their mind again given that the generic panel-timings binding does exist now. This is one of the many things that sucks about DT; no decision is ever kept, so consistency in design and implementation isn't possible:-(
cover tegra: Move tegra20 towards the 'new' display bindings
Hi Stephen,
Quoted 33 lines · Stephen Warren
Quoted 32 lines · Simon Glass
Hi Lucas,
Quoted 26 lines · Lucas Stach
Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass:
Quoted 13 lines
The original tegra20 display driver was written before Linux had device tree
bindings for display. Since then Linux has developed a robust set of bindings
covering various aspects of enabling a display.This series moves closer to those bindings by using the panel and backlight
as separate drivers. The device tree files for seaboard, ventana and harmony
thereby become almost the same as Linux.Quoted 8 lines
Unfortunately this breaks the other boards, which will need a similar sync.
So I'm not sure how easy it will be to accept this series. Still, it seems
worth sending it out in the hope that board maintainers can help. I have
kept this series separate so that it can progress separately.By pushing display timings into the DT you are actually diverging from mainline, as mainline doesn't require this, but instead infers the timings from the panel compatible. Is this a desired goal?
Quoted 5 lines
Quoted 1 line
This is not divergence.
Really? The DT content is different. Isn't that the definition of divergence?
You might infer that from the movie, but divergence really means that things are getting further apart. So I think here we have convergence.
Quoted 30 lines
Quoted 10 lines
Please take a look at the patch series. The
device tree files are very close to the same now. The existing U-Boot support has display timings in the device tree too, so this is not being added.The display timings are a small part of the work, but in the back of my mind is that we don't want to have a big table of display panel timings as exists in Linux. This is a waste of space when a board will only use one panel.
That was rather the point of the panel-specific compatible values: To force the DT to contain a semantic definition of the type of panel, rather than a "generic" definition of timings. A benefit of the semantic representation is that if we later find bugs that need to be fixed on certain panels, if we know the panel type, then bug fixes can be applied. Equally, if we enhance the SW to require more data about the panel, that can be added to a driver without the need to change the DT, thus allowing old DTs to continue to work. More semantic rather than purely "syntactic" knowledge is available. However, if we only have a generic timing definition (or other data suitable for current SW features or code-paths), then panel-specific bug fixes will never be possible since SW can't know the identify of the panel. The disadvantage of requiring a mapping table between panel type and display timings was considered reasonable for SW stacks at which DT was targeted (i.e. main OSs rather than HW-specific bootloaders). Even so, to avoid the bloat issue, you can always just #ifdef the mapping table and end up with the same code size; even less perhaps since no timing DT parsing code is required.
Quoted 7 lines
At least, that was the reasoning when the DT bindings for Tegra panels were first created; IIRC there was discussion of bindings for generic panels, timings, panel power sequences, etc., and they were rejected for the reason I explained above and perhaps others. However, it does seem someone has changed their mind again given that the generic panel-timings binding does exist now. This is one of the many things that sucks about DT; no decision is ever kept, so consistency in design and implementation isn't possible:-(
Sounds a bit contrived to me. The hardware includes the panel, so IMO it makes perfect sense to describe it in the DT. Plus it is more efficient as I mentioned.
Regards,
Simon
cover tegra: Move tegra20 towards the 'new' display bindings
Quoted 83 lines · Simon Glass
Hi Stephen,
Quoted 33 lines · Stephen Warren
Quoted 32 lines · Simon Glass
Hi Lucas,
Quoted 26 lines · Lucas Stach
Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass:
Quoted 13 lines
The original tegra20 display driver was written before Linux had device tree
bindings for display. Since then Linux has developed a robust set of bindings
covering various aspects of enabling a display.This series moves closer to those bindings by using the panel and backlight
as separate drivers. The device tree files for seaboard, ventana and harmony
thereby become almost the same as Linux.Quoted 8 lines
Unfortunately this breaks the other boards, which will need a similar sync.
So I'm not sure how easy it will be to accept this series. Still, it seems
worth sending it out in the hope that board maintainers can help. I have
kept this series separate so that it can progress separately.By pushing display timings into the DT you are actually diverging from mainline, as mainline doesn't require this, but instead infers the timings from the panel compatible. Is this a desired goal?
Quoted 5 lines
Quoted 1 line
This is not divergence.
Really? The DT content is different. Isn't that the definition of divergence?
You might infer that from the movie, but divergence really means that things are getting further apart. So I think here we have convergence.
Quoted 30 lines
Quoted 10 lines
Please take a look at the patch series. The
device tree files are very close to the same now. The existing U-Boot support has display timings in the device tree too, so this is not being added.The display timings are a small part of the work, but in the back of my mind is that we don't want to have a big table of display panel timings as exists in Linux. This is a waste of space when a board will only use one panel.
That was rather the point of the panel-specific compatible values: To force the DT to contain a semantic definition of the type of panel, rather than a "generic" definition of timings. A benefit of the semantic representation is that if we later find bugs that need to be fixed on certain panels, if we know the panel type, then bug fixes can be applied. Equally, if we enhance the SW to require more data about the panel, that can be added to a driver without the need to change the DT, thus allowing old DTs to continue to work. More semantic rather than purely "syntactic" knowledge is available. However, if we only have a generic timing definition (or other data suitable for current SW features or code-paths), then panel-specific bug fixes will never be possible since SW can't know the identify of the panel. The disadvantage of requiring a mapping table between panel type and display timings was considered reasonable for SW stacks at which DT was targeted (i.e. main OSs rather than HW-specific bootloaders). Even so, to avoid the bloat issue, you can always just #ifdef the mapping table and end up with the same code size; even less perhaps since no timing DT parsing code is required.
Quoted 7 lines
At least, that was the reasoning when the DT bindings for Tegra panels were first created; IIRC there was discussion of bindings for generic panels, timings, panel power sequences, etc., and they were rejected for the reason I explained above and perhaps others. However, it does seem someone has changed their mind again given that the generic panel-timings binding does exist now. This is one of the many things that sucks about DT; no decision is ever kept, so consistency in design and implementation isn't possible:-(
Quoted 1 line
Sounds a bit contrived to me.
I believe this approach has been taken after years of experience with DT and having to retro-fit bug-fixes and new features into existing DTs.
Still, you'd get the best background from the Linux kernel DT maintainers on this topic, since they have experience with DT over more years than me. I'm simply reporting the arguments they've presented.
cover tegra: Move tegra20 towards the 'new' display bindings
Quoted 84 lines · Stephen Warren
Quoted 83 lines · Simon Glass
Hi Stephen,
Quoted 33 lines · Stephen Warren
Quoted 32 lines · Simon Glass
Hi Lucas,
Quoted 26 lines · Lucas Stach
Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass:
Quoted 13 lines
The original tegra20 display driver was written before Linux had device tree
bindings for display. Since then Linux has developed a robust set of bindings
covering various aspects of enabling a display.This series moves closer to those bindings by using the panel and backlight
as separate drivers. The device tree files for seaboard, ventana and harmony
thereby become almost the same as Linux.Quoted 8 lines
Unfortunately this breaks the other boards, which will need a similar sync.
So I'm not sure how easy it will be to accept this series. Still, it seems
worth sending it out in the hope that board maintainers can help. I have
kept this series separate so that it can progress separately.By pushing display timings into the DT you are actually diverging from mainline, as mainline doesn't require this, but instead infers the timings from the panel compatible. Is this a desired goal?
Quoted 5 lines
Quoted 1 line
This is not divergence.
Really? The DT content is different. Isn't that the definition of divergence?
You might infer that from the movie, but divergence really means that things are getting further apart. So I think here we have convergence.
Quoted 37 lines
Quoted 10 lines
Please take a look at the patch series. The
device tree files are very close to the same now. The existing U-Boot support has display timings in the device tree too, so this is not being added.The display timings are a small part of the work, but in the back of my mind is that we don't want to have a big table of display panel timings as exists in Linux. This is a waste of space when a board will only use one panel.
That was rather the point of the panel-specific compatible values: To force the DT to contain a semantic definition of the type of panel, rather than a "generic" definition of timings. A benefit of the semantic representation is that if we later find bugs that need to be fixed on certain panels, if we know the panel type, then bug fixes can be applied. Equally, if we enhance the SW to require more data about the panel, that can be added to a driver without the need to change the DT, thus allowing old DTs to continue to work. More semantic rather than purely "syntactic" knowledge is available. However, if we only have a generic timing definition (or other data suitable for current SW features or code-paths), then panel-specific bug fixes will never be possible since SW can't know the identify of the panel. The disadvantage of requiring a mapping table between panel type and display timings was considered reasonable for SW stacks at which DT was targeted (i.e. main OSs rather than HW-specific bootloaders). Even so, to avoid the bloat issue, you can always just #ifdef the mapping table and end up with the same code size; even less perhaps since no timing DT parsing code is required.
At least, that was the reasoning when the DT bindings for Tegra panels were first created; IIRC there was discussion of bindings for generic panels, timings, panel power sequences, etc., and they were rejected for the reason I explained above and perhaps others. However, it does seem someone has changed their mind again given that the generic panel-timings binding does exist now. This is one of the many things that sucks about DT; no decision is ever kept, so consistency in design and implementation isn't possible:-(
Quoted 8 lines
Quoted 1 line
Sounds a bit contrived to me.
I believe this approach has been taken after years of experience with DT and having to retro-fit bug-fixes and new features into existing DTs.
Still, you'd get the best background from the Linux kernel DT maintainers on this topic, since they have experience with DT over more years than me. I'm simply reporting the arguments they've presented.
To be fair, the panel bindings came about after the display-timings binding. Perhaps the main reason why the panel bindings are what they are today is because I consider them devices no different at all from peripherals and the like. Back at the time, most of the pushback was because people believed that panels were somehow special in that they would simply require the video timings to make them work, and hence having some generic helpers to parse them from DT would be enough and is what many drivers ended up implementing.
But it turned out that there's more to panels than just the video timings. Many panels do have a varying number of inputs that need to be controlled before you can use them. There are voltage supplies and reset or powerdown GPIOs, PWM inputs for backlight etc. Like Stephen said it was at some point attempted to describe this completely generically in DT using power sequences, but that effort turned out to be much too complicated even considering only a subset of relatively simple panels.
Taking into account the various types of smart panels out there things get even more complicated. All of a sudden you need a sort of register programming sequence to enable or disable the panel. Of course with a generic panel binding you need to find a way to put that into the DT along with everything else. And then you need a way to specify where to write these registers in the enable/disable sequence, in some cases you might even need to split it up into several chunks, etc.
So the end result was that while you had a generic way for describing the video timings, every driver had to implement its own support infrastructure for the various resources that you need to turn on. In fact this became quite the opposite of generic.
Now when you consider panels to be devices and give them a proper compatible string things actually get almost trivial. Now each panel can have a binding that fully describes the supplies and GPIOs and the driver that binds to the device can contain the enable and disable sequences in code. This is completely normal for any other kind of device, why would panels need to be special? Now that a panel is simply a device like any other you can make things truly generic, create the abstractions you need and simply hook up outputs to panels and make them work together.
There is still some commonality in many panels, so in Linux we ended up implementing a "simple" panel driver, which can drive panels that have a backlight, a power supply and an enable GPIO, with an optional DDC bus that can be used to read EDID. That driver supports 34 different panels at the time of this writing and it's still fairly small. But there is a slew of options to reduce that size even further if you really need to. You could for example have Kconfig options for panel vendors, or even per-panel Kconfig options to minimize the data used for the panel. I suspect that you might end up with even less data than the equivalent DT content.
Thierry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20160120/8d736b99/attachment.sig>
cover tegra: Move tegra20 towards the 'new' display bindings
Hi,
Quoted 135 lines · Thierry Reding
Quoted 84 lines · Stephen Warren
Quoted 83 lines · Simon Glass
Hi Stephen,
Quoted 33 lines · Stephen Warren
Quoted 32 lines · Simon Glass
Hi Lucas,
Quoted 26 lines · Lucas Stach
Am Donnerstag, den 14.01.2016, 13:26 -0700 schrieb Simon Glass:
Quoted 13 lines
The original tegra20 display driver was written before Linux had device tree
bindings for display. Since then Linux has developed a robust set of bindings
covering various aspects of enabling a display.This series moves closer to those bindings by using the panel and backlight
as separate drivers. The device tree files for seaboard, ventana and harmony
thereby become almost the same as Linux.Quoted 8 lines
Unfortunately this breaks the other boards, which will need a similar sync.
So I'm not sure how easy it will be to accept this series. Still, it seems
worth sending it out in the hope that board maintainers can help. I have
kept this series separate so that it can progress separately.By pushing display timings into the DT you are actually diverging from mainline, as mainline doesn't require this, but instead infers the timings from the panel compatible. Is this a desired goal?
Quoted 5 lines
Quoted 1 line
This is not divergence.
Really? The DT content is different. Isn't that the definition of divergence?
You might infer that from the movie, but divergence really means that things are getting further apart. So I think here we have convergence.
Quoted 37 lines
Quoted 10 lines
Please take a look at the patch series. The
device tree files are very close to the same now. The existing U-Boot support has display timings in the device tree too, so this is not being added.The display timings are a small part of the work, but in the back of my mind is that we don't want to have a big table of display panel timings as exists in Linux. This is a waste of space when a board will only use one panel.
That was rather the point of the panel-specific compatible values: To force the DT to contain a semantic definition of the type of panel, rather than a "generic" definition of timings. A benefit of the semantic representation is that if we later find bugs that need to be fixed on certain panels, if we know the panel type, then bug fixes can be applied. Equally, if we enhance the SW to require more data about the panel, that can be added to a driver without the need to change the DT, thus allowing old DTs to continue to work. More semantic rather than purely "syntactic" knowledge is available. However, if we only have a generic timing definition (or other data suitable for current SW features or code-paths), then panel-specific bug fixes will never be possible since SW can't know the identify of the panel. The disadvantage of requiring a mapping table between panel type and display timings was considered reasonable for SW stacks at which DT was targeted (i.e. main OSs rather than HW-specific bootloaders). Even so, to avoid the bloat issue, you can always just #ifdef the mapping table and end up with the same code size; even less perhaps since no timing DT parsing code is required.
At least, that was the reasoning when the DT bindings for Tegra panels were first created; IIRC there was discussion of bindings for generic panels, timings, panel power sequences, etc., and they were rejected for the reason I explained above and perhaps others. However, it does seem someone has changed their mind again given that the generic panel-timings binding does exist now. This is one of the many things that sucks about DT; no decision is ever kept, so consistency in design and implementation isn't possible:-(
Quoted 8 lines
Quoted 1 line
Sounds a bit contrived to me.
I believe this approach has been taken after years of experience with DT and having to retro-fit bug-fixes and new features into existing DTs.
Still, you'd get the best background from the Linux kernel DT maintainers on this topic, since they have experience with DT over more years than me. I'm simply reporting the arguments they've presented.
To be fair, the panel bindings came about after the display-timings binding. Perhaps the main reason why the panel bindings are what they are today is because I consider them devices no different at all from peripherals and the like. Back at the time, most of the pushback was because people believed that panels were somehow special in that they would simply require the video timings to make them work, and hence having some generic helpers to parse them from DT would be enough and is what many drivers ended up implementing.
But it turned out that there's more to panels than just the video timings. Many panels do have a varying number of inputs that need to be controlled before you can use them. There are voltage supplies and reset or powerdown GPIOs, PWM inputs for backlight etc. Like Stephen said it was at some point attempted to describe this completely generically in DT using power sequences, but that effort turned out to be much too complicated even considering only a subset of relatively simple panels.
Taking into account the various types of smart panels out there things get even more complicated. All of a sudden you need a sort of register programming sequence to enable or disable the panel. Of course with a generic panel binding you need to find a way to put that into the DT along with everything else. And then you need a way to specify where to write these registers in the enable/disable sequence, in some cases you might even need to split it up into several chunks, etc.
So the end result was that while you had a generic way for describing the video timings, every driver had to implement its own support infrastructure for the various resources that you need to turn on. In fact this became quite the opposite of generic.
Now when you consider panels to be devices and give them a proper compatible string things actually get almost trivial. Now each panel can have a binding that fully describes the supplies and GPIOs and the driver that binds to the device can contain the enable and disable sequences in code. This is completely normal for any other kind of device, why would panels need to be special? Now that a panel is simply a device like any other you can make things truly generic, create the abstractions you need and simply hook up outputs to panels and make them work together.
Quoted 10 lines
There is still some commonality in many panels, so in Linux we ended up implementing a "simple" panel driver, which can drive panels that have a backlight, a power supply and an enable GPIO, with an optional DDC bus that can be used to read EDID. That driver supports 34 different panels at the time of this writing and it's still fairly small. But there is a slew of options to reduce that size even further if you really need to. You could for example have
Kconfigoptions for panel vendors, or even per-panelKconfigoptions to minimize the data used for the panel. I suspect that you might end up with even less data than the equivalent DT content.
So far I've just implemented simple-panel, but the option is there to create your own driver in UCLASS_PANEL if needed. I have not needed any special panel features yet, but we'll see how it goes. I suppose a lot of panels are pretty simple/similar.
I didn't see any delay stuff in Linux - or at least it is there but was zero for seaboard. So probably I was worrying about that unnecessarily.
Regards,
Simon
cover tegra: Move tegra20 towards the 'new' display bindings
In reply to Simon GlassQuoted 4 lines · Simon Glass
The original tegra20 display driver was written before Linux had device tree bindings for display. Since then Linux has developed a robust set of bindings covering various aspects of enabling a display.
Quoted 8 lines
This series moves closer to those bindings by using the panel and backlight as separate drivers. The device tree files for seaboard, ventana and harmony thereby become almost the same as Linux.
Unfortunately this breaks the other boards, which will need a similar sync. So I'm not sure how easy it will be to accept this series. Still, it seems worth sending it out in the hope that board maintainers can help. I have kept this series separate so that it can progress separately.
Can't that be handled by placing the new code under an ifdef, so the source code can support either the old or the new scheme, then each board can be converted over and the ifdef flipped in its per-board config file, then the ifdef removed once all boards are converted?
cover tegra: Move tegra20 towards the 'new' display bindings
Hi Stephen,
Quoted 21 lines · Stephen Warren
Quoted 13 lines · Simon Glass
The original tegra20 display driver was written before Linux had device tree
bindings for display. Since then Linux has developed a robust set of bindings
covering various aspects of enabling a display.This series moves closer to those bindings by using the panel and backlight
as separate drivers. The device tree files for seaboard, ventana and harmony
thereby become almost the same as Linux.Quoted 5 lines
Unfortunately this breaks the other boards, which will need a similar sync.
So I'm not sure how easy it will be to accept this series. Still, it seems worth sending it out in the hope that board maintainers can help. I have kept this series separate so that it can progress separately.
Quoted 4 lines
Can't that be handled by placing the new code under an ifdef, so the source code can support either the old or the new scheme, then each board can be converted over and the ifdef flipped in its per-board config file, then the ifdef removed once all boards are converted?
To some extent, although there is the common tegra20.dtsi and lots of common code. It was more pain than I was willing to bear.
Another option is to eventually disable LCD for boards where the maintainers don't respond.
Regards,
Simon