[PATCH 0/2] ARM: dts: OMAP4: Add support for DuoVero/Parlor

[PATCH 0/2] ARM: dts: OMAP4: Add support for DuoVero/Parlor

[Florian Vaussard]

Hi Benoit, Tony,

Here is a device tree to support the OMAP4430-based Gumstix DuoVero
with the Parlor expansion boards. All peripherals should be working
with current 3.14-rc4, except:

- GPMC ethernet (needs patches [1])
- TWL6040 init may fail (will send a bug report to ML)
- The HDMI output depends on Tomi's DSS series [2] (not yet merged)

I split the HDMI part into a second patch, so it can be merged with the DSS
series, even if the nodes could be merged independently.

Regards,
Florian

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/110662
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/295881


Florian Vaussard (2):
  ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor
  ARM: dts: duovero-parlor: Add HDMI output

 .../devicetree/bindings/arm/omap/omap.txt          |   3 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/omap4-duovero-parlor.dts         | 182 +++++++++++++++
 arch/arm/boot/dts/omap4-duovero.dtsi               | 252 +++++++++++++++++++++
 4 files changed, 438 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-duovero-parlor.dts
 create mode 100644 arch/arm/boot/dts/omap4-duovero.dtsi

-- 
1.8.1.2

[PATCH 0/2] ARM: dts: OMAP4: Add support for DuoVero/Parlor

[Florian Vaussard]

Hi Benoit, Tony,

Here is a device tree to support the OMAP4430-based Gumstix DuoVero
with the Parlor expansion boards. All peripherals should be working
with current 3.14-rc4, except:

- GPMC ethernet (needs patches [1])
- TWL6040 init may fail (will send a bug report to ML)
- The HDMI output depends on Tomi's DSS series [2] (not yet merged)

I split the HDMI part into a second patch, so it can be merged with the DSS
series, even if the nodes could be merged independently.

Regards,
Florian

[1] http://thread.gmane.org/gmane.linux.ports.arm.omap/110662
[2] http://thread.gmane.org/gmane.linux.ports.arm.kernel/295881


Florian Vaussard (2):
  ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor
  ARM: dts: duovero-parlor: Add HDMI output

 .../devicetree/bindings/arm/omap/omap.txt          |   3 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/omap4-duovero-parlor.dts         | 182 +++++++++++++++
 arch/arm/boot/dts/omap4-duovero.dtsi               | 252 +++++++++++++++++++++
 4 files changed, 438 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-duovero-parlor.dts
 create mode 100644 arch/arm/boot/dts/omap4-duovero.dtsi

-- 
1.8.1.2

[PATCH 1/2] ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor

[Florian Vaussard]

Gumstix DuoVero is an OMAP4430-based Computer On Module.
Parlor is one of the available expansion board.

Tested features:
- GPMC ethernet
- HSUSB2 and OTG
- Audio out
- WiFi and Bluetooth (w2cbw0015 SDIO module)
- LED and button

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 .../devicetree/bindings/arm/omap/omap.txt          |   3 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/omap4-duovero-parlor.dts         | 146 ++++++++++++
 arch/arm/boot/dts/omap4-duovero.dtsi               | 252 +++++++++++++++++++++
 4 files changed, 402 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-duovero-parlor.dts
 create mode 100644 arch/arm/boot/dts/omap4-duovero.dtsi

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index af9b4a0..95b1372 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -99,6 +99,9 @@ Boards:
 - OMAP4 PandaBoard : Low cost community board
   compatible = "ti,omap4-panda", "ti,omap4430"
 
+- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
+  compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
+
 - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
   compatible = "ti,omap3-evm", "ti,omap3"
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..8b23abb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -215,6 +215,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	omap3-igep0020.dtb \
 	omap3-igep0030.dtb \
 	omap3-zoom3.dtb \
+	omap4-duovero-parlor.dtb \
 	omap4-panda.dtb \
 	omap4-panda-a4.dtb \
 	omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts b/arch/arm/boot/dts/omap4-duovero-parlor.dts
new file mode 100644
index 0000000..96f51d8
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "omap4-duovero.dtsi"
+
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "OMAP4430 Gumstix Duovero on Parlor";
+	compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
+
+	leds {
+		compatible = "gpio-leds";
+		led0 {
+			label = "duovero:blue:led0";
+			gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;	/* gpio_122 */
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		button0@121 {
+			label = "button0";
+			linux,code = <BTN_0>;
+			gpios = <&gpio4 25 GPIO_ACTIVE_LOW>;	/* gpio_121 */
+			gpio-key,wakeup;
+		};
+	};
+};
+
+&omap4_pmx_core {
+	pinctrl-0 = <
+			&led_pins
+			&button_pins
+			&smsc_pins
+	>;
+
+	led_pins: pinmux_led_pins {
+		pinctrl-single,pins = <
+			0xd6 (PIN_OUTPUT | MUX_MODE3)		/* abe_dmic_din3.gpio_122 */
+		>;
+	};
+
+	button_pins: pinmux_button_pins {
+		pinctrl-single,pins = <
+			0xd4 (PIN_INPUT_PULLUP | MUX_MODE3)	/* abe_dmic_din2.gpio_121 */
+		>;
+	};
+
+	i2c2_pins: pinmux_i2c2_pins {
+		pinctrl-single,pins = <
+			0xe6 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_scl */
+			0xe8 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_sda */
+		>;
+	};
+
+	i2c3_pins: pinmux_i2c3_pins {
+		pinctrl-single,pins = <
+			0xea (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_scl */
+			0xec (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_sda */
+		>;
+	};
+
+	smsc_pins: pinmux_smsc_pins {
+		pinctrl-single,pins = <
+			0x28 (PIN_INPUT | MUX_MODE3)		/* gpmc_a20.gpio_44: IRQ */
+			0x2a (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a21.gpio_45: nReset */
+			0x30 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a24.gpio_48: amdix enabled */
+		>;
+	};
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c3_pins>;
+
+	clock-frequency = <100000>;
+
+	/* optional 1K EEPROM with revision information */
+	eeprom@51 {
+		compatible = "atmel,24c01";
+		reg = <0x51>;
+		pagesize = <8>;
+	};
+};
+
+&mmc3 {
+	status = "disabled";
+};
+
+#include "omap-gpmc-smsc911x.dtsi"
+
+&gpmc {
+	ranges = <5 0 0x2c000000 0x1000000>;			/* CS5 */
+
+	ethernet@gpmc {
+		reg = <5 0 0xff>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <12 IRQ_TYPE_LEVEL_LOW>;		/* gpio_44 */
+
+		phy-mode = "mii";
+
+		gpmc,cs-on-ns = <10>;
+		gpmc,cs-rd-off-ns = <50>;
+		gpmc,cs-wr-off-ns = <50>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <10>;
+		gpmc,adv-wr-off-ns = <10>;
+		gpmc,oe-on-ns = <15>;
+		gpmc,oe-off-ns = <50>;
+		gpmc,we-on-ns = <15>;
+		gpmc,we-off-ns = <50>;
+		gpmc,rd-cycle-ns = <50>;
+		gpmc,wr-cycle-ns = <50>;
+		gpmc,access-ns = <50>;
+		gpmc,page-burst-access-ns = <0>;
+		gpmc,bus-turnaround-ns = <35>;
+		gpmc,cycle2cycle-delay-ns = <35>;
+		gpmc,wr-data-mux-bus-ns = <35>;
+		gpmc,wr-access-ns = <50>;
+
+		gpmc,mux-add-data = <2>;
+		gpmc,sync-read;
+		gpmc,sync-write;
+		gpmc,clk-activation-ns = <5>;
+		gpmc,sync-clk-ps = <20000>;
+	};
+};
+
+
diff --git a/arch/arm/boot/dts/omap4-duovero.dtsi b/arch/arm/boot/dts/omap4-duovero.dtsi
new file mode 100644
index 0000000..a514791
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-duovero.dtsi
@@ -0,0 +1,252 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "omap443x.dtsi"
+
+/ {
+	model = "Gumstix Duovero";
+	compatible = "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>; /* 1 GB */
+	};
+
+	sound {
+		compatible = "ti,abe-twl6040";
+		ti,model = "DuoVero";
+
+		ti,mclk-freq = <38400000>;
+
+		ti,mcpdm = <&mcpdm>;
+
+		ti,twl6040 = <&twl6040>;
+
+		/* Audio routing */
+		ti,audio-routing =
+			"Headset Stereophone", "HSOL",
+			"Headset Stereophone", "HSOR",
+			"HSMIC", "Headset Mic",
+			"Headset Mic", "Headset Mic Bias";
+	};
+
+	/* HS USB Host PHY on PORT 1 */
+	hsusb1_phy: hsusb1_phy {
+		compatible = "usb-nop-xceiv";
+		reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>;	/* gpio_62 */
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&hsusb1phy_pins>;
+
+		clocks = <&auxclk3_ck>;
+		clock-names = "main_clk";
+		clock-frequency = <19200000>;
+	};
+
+	/* regulator for w2cbw0015 on sdio5 */
+	w2cbw0015_vmmc: w2cbw0015_vmmc {
+		pinctrl-names = "default";
+		pinctrl-0 = <&w2cbw0015_pins>;
+		compatible = "regulator-fixed";
+		regulator-name = "w2cbw0015";
+		regulator-min-microvolt = <3000000>;
+		regulator-max-microvolt = <3000000>;
+		gpio = <&gpio2 11 GPIO_ACTIVE_LOW>;		/* gpio_43 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+		regulator-boot-on;
+	};
+};
+
+&omap4_pmx_core {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+			&twl6040_pins
+			&mcpdm_pins
+			&mcbsp1_pins
+			&hsusbb1_pins
+	>;
+
+	twl6040_pins: pinmux_twl6040_pins {
+		pinctrl-single,pins = <
+			0x126 (PIN_OUTPUT | MUX_MODE3)		/* usbb2_ulpitll_nxt.gpio_160 */
+			0x160 (PIN_INPUT | MUX_MODE0)		/* sys_nirq2.sys_nirq2 */
+		>;
+	};
+
+	mcpdm_pins: pinmux_mcpdm_pins {
+		pinctrl-single,pins = <
+			0xc6 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_ul_data.abe_pdm_ul_data */
+			0xc8 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_dl_data.abe_pdm_dl_data */
+			0xca (PIN_INPUT_PULLUP   | MUX_MODE0)	/* abe_pdm_frame.abe_pdm_frame */
+			0xcc (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_lb_clk.abe_pdm_lb_clk */
+			0xce (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_clks.abe_clks */
+		>;
+	};
+
+	mcbsp1_pins: pinmux_mcbsp1_pins {
+		pinctrl-single,pins = <
+			0xbe (PIN_INPUT | MUX_MODE0)		/* abe_mcbsp1_clkx.abe_mcbsp1_clkx */
+			0xc0 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_mcbsp1_dr.abe_mcbsp1_dr */
+			0xc2 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)	/* abe_mcbsp1_dx.abe_mcbsp1_dx */
+			0xc4 (PIN_INPUT | MUX_MODE0)		/* abe_mcbsp1_fsx.abe_mcbsp1_fsx */
+		>;
+	};
+
+	hsusbb1_pins: pinmux_hsusbb1_pins {
+		pinctrl-single,pins = <
+			0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_clk.usbb1_ulpiphy_clk */
+			0x84 (PIN_OUTPUT | MUX_MODE4)		/* usbb1_ulpitll_stp.usbb1_ulpiphy_stp */
+			0x86 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dir.usbb1_ulpiphy_dir */
+			0x88 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt */
+			0x8a (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 */
+			0x8c (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 */
+			0x8e (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 */
+			0x90 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 */
+			0x92 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 */
+			0x94 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 */
+			0x96 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 */
+			0x98 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 */
+		>;
+	};
+
+	hsusb1phy_pins: pinmux_hsusb1phy_pins {
+		pinctrl-single,pins = <
+			0x4c (PIN_OUTPUT | MUX_MODE3)		/* gpmc_wait1.gpio_62 */
+		>;
+	};
+
+	w2cbw0015_pins: pinmux_w2cbw0015_pins {
+		pinctrl-single,pins = <
+			0x26 (PIN_OUTPUT | MUX_MODE3)		/* gpmc_a19.gpio_43 */
+			0x3a (PIN_INPUT | MUX_MODE3)		/* gpmc_ncs3.gpio_53 */
+		>;
+	};
+
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			0xe2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_scl */
+			0xe4 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_sda */
+		>;
+	};
+
+	i2c4_pins: pinmux_i2c4_pins {
+		pinctrl-single,pins = <
+			0xee (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_scl */
+			0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_sda */
+		>;
+	};
+
+	mmc1_pins: pinmux_mmc1_pins {
+		pinctrl-single,pins = <
+			0xa2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk */
+			0xa4 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc1_cmd */
+			0xa6 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc1_dat0 */
+			0xa8 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat1 */
+			0xaa (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat2 */
+			0xac (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat3 */
+		>;
+	};
+
+	mmc5_pins: pinmux_mmc5_pins {
+		pinctrl-single,pins = <
+			0x108 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_clk */
+			0x10a (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc5_cmd */
+			0x10c (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc5_dat0 */
+			0x10e (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat1 */
+			0x110 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat2 */
+			0x112 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat3 */
+		>;
+	};
+};
+
+/* PMIC */
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+
+	clock-frequency = <400000>;
+
+	twl: twl@48 {
+		reg = <0x48>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;		/* IRQ_SYS_1N cascaded to gic */
+		interrupt-parent = <&gic>;
+	};
+
+	twl6040: twl@4b {
+		compatible = "ti,twl6040";
+		reg = <0x4b>;
+		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;		/* IRQ_SYS_2N cascaded to gic */
+		interrupt-parent = <&gic>;
+		ti,audpwron-gpio = <&gpio6 0 GPIO_ACTIVE_HIGH>;		/* gpio_160 */
+
+		vio-supply = <&v1v8>;
+		v2v1-supply = <&v2v1>;
+		enable-active-high;
+	};
+};
+
+#include "twl6030.dtsi"
+#include "twl6030_omap4.dtsi"
+
+/* on-board bluetooth / WiFi module */
+&i2c4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c4_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+
+	vmmc-supply = <&vmmc>;
+	ti,bus-width = <4>;
+	ti,non-removable;		/* FIXME: use PMIC_MMC detect */
+};
+
+&mmc2 {
+	status = "disabled";
+};
+
+/* mmc3 is available to the expansion board */
+
+&mmc4 {
+	status = "disabled";
+};
+
+/* on-board WiFi module */
+&mmc5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc5_pins>;
+
+	vmmc-supply = <&w2cbw0015_vmmc>;
+	ti,bus-width = <4>;
+	ti,non-removable;
+	cap-power-off-card;
+};
+
+&twl_usb_comparator {
+	usb-supply = <&vusb>;
+};
+
+&usb_otg_hs {
+	interface-type = <1>;
+	mode = <3>;
+	power = <50>;
+};
+
+&usbhshost {
+	port1-mode = "ehci-phy";
+};
+
+&usbhsehci {
+	phys = <&hsusb1_phy>;
+};
+
-- 
1.8.1.2

[PATCH 1/2] ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor

[Florian Vaussard]

Gumstix DuoVero is an OMAP4430-based Computer On Module.
Parlor is one of the available expansion board.

Tested features:
- GPMC ethernet
- HSUSB2 and OTG
- Audio out
- WiFi and Bluetooth (w2cbw0015 SDIO module)
- LED and button

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 .../devicetree/bindings/arm/omap/omap.txt          |   3 +
 arch/arm/boot/dts/Makefile                         |   1 +
 arch/arm/boot/dts/omap4-duovero-parlor.dts         | 146 ++++++++++++
 arch/arm/boot/dts/omap4-duovero.dtsi               | 252 +++++++++++++++++++++
 4 files changed, 402 insertions(+)
 create mode 100644 arch/arm/boot/dts/omap4-duovero-parlor.dts
 create mode 100644 arch/arm/boot/dts/omap4-duovero.dtsi

diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
index af9b4a0..95b1372 100644
--- a/Documentation/devicetree/bindings/arm/omap/omap.txt
+++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
@@ -99,6 +99,9 @@ Boards:
 - OMAP4 PandaBoard : Low cost community board
   compatible = "ti,omap4-panda", "ti,omap4430"
 
+- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
+  compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
+
 - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
   compatible = "ti,omap3-evm", "ti,omap3"
 
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 0320303..8b23abb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -215,6 +215,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
 	omap3-igep0020.dtb \
 	omap3-igep0030.dtb \
 	omap3-zoom3.dtb \
+	omap4-duovero-parlor.dtb \
 	omap4-panda.dtb \
 	omap4-panda-a4.dtb \
 	omap4-panda-es.dtb \
diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts b/arch/arm/boot/dts/omap4-duovero-parlor.dts
new file mode 100644
index 0000000..96f51d8
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+/dts-v1/;
+
+#include "omap4-duovero.dtsi"
+
+#include <dt-bindings/input/input.h>
+
+/ {
+	model = "OMAP4430 Gumstix Duovero on Parlor";
+	compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
+
+	leds {
+		compatible = "gpio-leds";
+		led0 {
+			label = "duovero:blue:led0";
+			gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;	/* gpio_122 */
+			linux,default-trigger = "heartbeat";
+		};
+	};
+
+	gpio_keys {
+		compatible = "gpio-keys";
+		#address-cells = <1>;
+		#size-cells = <0>;
+		button0 at 121 {
+			label = "button0";
+			linux,code = <BTN_0>;
+			gpios = <&gpio4 25 GPIO_ACTIVE_LOW>;	/* gpio_121 */
+			gpio-key,wakeup;
+		};
+	};
+};
+
+&omap4_pmx_core {
+	pinctrl-0 = <
+			&led_pins
+			&button_pins
+			&smsc_pins
+	>;
+
+	led_pins: pinmux_led_pins {
+		pinctrl-single,pins = <
+			0xd6 (PIN_OUTPUT | MUX_MODE3)		/* abe_dmic_din3.gpio_122 */
+		>;
+	};
+
+	button_pins: pinmux_button_pins {
+		pinctrl-single,pins = <
+			0xd4 (PIN_INPUT_PULLUP | MUX_MODE3)	/* abe_dmic_din2.gpio_121 */
+		>;
+	};
+
+	i2c2_pins: pinmux_i2c2_pins {
+		pinctrl-single,pins = <
+			0xe6 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_scl */
+			0xe8 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_sda */
+		>;
+	};
+
+	i2c3_pins: pinmux_i2c3_pins {
+		pinctrl-single,pins = <
+			0xea (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_scl */
+			0xec (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_sda */
+		>;
+	};
+
+	smsc_pins: pinmux_smsc_pins {
+		pinctrl-single,pins = <
+			0x28 (PIN_INPUT | MUX_MODE3)		/* gpmc_a20.gpio_44: IRQ */
+			0x2a (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a21.gpio_45: nReset */
+			0x30 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a24.gpio_48: amdix enabled */
+		>;
+	};
+};
+
+&i2c2 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c2_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&i2c3 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c3_pins>;
+
+	clock-frequency = <100000>;
+
+	/* optional 1K EEPROM with revision information */
+	eeprom at 51 {
+		compatible = "atmel,24c01";
+		reg = <0x51>;
+		pagesize = <8>;
+	};
+};
+
+&mmc3 {
+	status = "disabled";
+};
+
+#include "omap-gpmc-smsc911x.dtsi"
+
+&gpmc {
+	ranges = <5 0 0x2c000000 0x1000000>;			/* CS5 */
+
+	ethernet at gpmc {
+		reg = <5 0 0xff>;
+		interrupt-parent = <&gpio2>;
+		interrupts = <12 IRQ_TYPE_LEVEL_LOW>;		/* gpio_44 */
+
+		phy-mode = "mii";
+
+		gpmc,cs-on-ns = <10>;
+		gpmc,cs-rd-off-ns = <50>;
+		gpmc,cs-wr-off-ns = <50>;
+		gpmc,adv-on-ns = <0>;
+		gpmc,adv-rd-off-ns = <10>;
+		gpmc,adv-wr-off-ns = <10>;
+		gpmc,oe-on-ns = <15>;
+		gpmc,oe-off-ns = <50>;
+		gpmc,we-on-ns = <15>;
+		gpmc,we-off-ns = <50>;
+		gpmc,rd-cycle-ns = <50>;
+		gpmc,wr-cycle-ns = <50>;
+		gpmc,access-ns = <50>;
+		gpmc,page-burst-access-ns = <0>;
+		gpmc,bus-turnaround-ns = <35>;
+		gpmc,cycle2cycle-delay-ns = <35>;
+		gpmc,wr-data-mux-bus-ns = <35>;
+		gpmc,wr-access-ns = <50>;
+
+		gpmc,mux-add-data = <2>;
+		gpmc,sync-read;
+		gpmc,sync-write;
+		gpmc,clk-activation-ns = <5>;
+		gpmc,sync-clk-ps = <20000>;
+	};
+};
+
+
diff --git a/arch/arm/boot/dts/omap4-duovero.dtsi b/arch/arm/boot/dts/omap4-duovero.dtsi
new file mode 100644
index 0000000..a514791
--- /dev/null
+++ b/arch/arm/boot/dts/omap4-duovero.dtsi
@@ -0,0 +1,252 @@
+/*
+ * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include "omap443x.dtsi"
+
+/ {
+	model = "Gumstix Duovero";
+	compatible = "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
+
+	memory {
+		device_type = "memory";
+		reg = <0x80000000 0x40000000>; /* 1 GB */
+	};
+
+	sound {
+		compatible = "ti,abe-twl6040";
+		ti,model = "DuoVero";
+
+		ti,mclk-freq = <38400000>;
+
+		ti,mcpdm = <&mcpdm>;
+
+		ti,twl6040 = <&twl6040>;
+
+		/* Audio routing */
+		ti,audio-routing =
+			"Headset Stereophone", "HSOL",
+			"Headset Stereophone", "HSOR",
+			"HSMIC", "Headset Mic",
+			"Headset Mic", "Headset Mic Bias";
+	};
+
+	/* HS USB Host PHY on PORT 1 */
+	hsusb1_phy: hsusb1_phy {
+		compatible = "usb-nop-xceiv";
+		reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>;	/* gpio_62 */
+
+		pinctrl-names = "default";
+		pinctrl-0 = <&hsusb1phy_pins>;
+
+		clocks = <&auxclk3_ck>;
+		clock-names = "main_clk";
+		clock-frequency = <19200000>;
+	};
+
+	/* regulator for w2cbw0015 on sdio5 */
+	w2cbw0015_vmmc: w2cbw0015_vmmc {
+		pinctrl-names = "default";
+		pinctrl-0 = <&w2cbw0015_pins>;
+		compatible = "regulator-fixed";
+		regulator-name = "w2cbw0015";
+		regulator-min-microvolt = <3000000>;
+		regulator-max-microvolt = <3000000>;
+		gpio = <&gpio2 11 GPIO_ACTIVE_LOW>;		/* gpio_43 */
+		startup-delay-us = <70000>;
+		enable-active-high;
+		regulator-boot-on;
+	};
+};
+
+&omap4_pmx_core {
+	pinctrl-names = "default";
+	pinctrl-0 = <
+			&twl6040_pins
+			&mcpdm_pins
+			&mcbsp1_pins
+			&hsusbb1_pins
+	>;
+
+	twl6040_pins: pinmux_twl6040_pins {
+		pinctrl-single,pins = <
+			0x126 (PIN_OUTPUT | MUX_MODE3)		/* usbb2_ulpitll_nxt.gpio_160 */
+			0x160 (PIN_INPUT | MUX_MODE0)		/* sys_nirq2.sys_nirq2 */
+		>;
+	};
+
+	mcpdm_pins: pinmux_mcpdm_pins {
+		pinctrl-single,pins = <
+			0xc6 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_ul_data.abe_pdm_ul_data */
+			0xc8 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_dl_data.abe_pdm_dl_data */
+			0xca (PIN_INPUT_PULLUP   | MUX_MODE0)	/* abe_pdm_frame.abe_pdm_frame */
+			0xcc (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_lb_clk.abe_pdm_lb_clk */
+			0xce (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_clks.abe_clks */
+		>;
+	};
+
+	mcbsp1_pins: pinmux_mcbsp1_pins {
+		pinctrl-single,pins = <
+			0xbe (PIN_INPUT | MUX_MODE0)		/* abe_mcbsp1_clkx.abe_mcbsp1_clkx */
+			0xc0 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_mcbsp1_dr.abe_mcbsp1_dr */
+			0xc2 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)	/* abe_mcbsp1_dx.abe_mcbsp1_dx */
+			0xc4 (PIN_INPUT | MUX_MODE0)		/* abe_mcbsp1_fsx.abe_mcbsp1_fsx */
+		>;
+	};
+
+	hsusbb1_pins: pinmux_hsusbb1_pins {
+		pinctrl-single,pins = <
+			0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_clk.usbb1_ulpiphy_clk */
+			0x84 (PIN_OUTPUT | MUX_MODE4)		/* usbb1_ulpitll_stp.usbb1_ulpiphy_stp */
+			0x86 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dir.usbb1_ulpiphy_dir */
+			0x88 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt */
+			0x8a (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 */
+			0x8c (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 */
+			0x8e (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 */
+			0x90 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 */
+			0x92 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 */
+			0x94 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 */
+			0x96 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 */
+			0x98 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 */
+		>;
+	};
+
+	hsusb1phy_pins: pinmux_hsusb1phy_pins {
+		pinctrl-single,pins = <
+			0x4c (PIN_OUTPUT | MUX_MODE3)		/* gpmc_wait1.gpio_62 */
+		>;
+	};
+
+	w2cbw0015_pins: pinmux_w2cbw0015_pins {
+		pinctrl-single,pins = <
+			0x26 (PIN_OUTPUT | MUX_MODE3)		/* gpmc_a19.gpio_43 */
+			0x3a (PIN_INPUT | MUX_MODE3)		/* gpmc_ncs3.gpio_53 */
+		>;
+	};
+
+	i2c1_pins: pinmux_i2c1_pins {
+		pinctrl-single,pins = <
+			0xe2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_scl */
+			0xe4 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_sda */
+		>;
+	};
+
+	i2c4_pins: pinmux_i2c4_pins {
+		pinctrl-single,pins = <
+			0xee (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_scl */
+			0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_sda */
+		>;
+	};
+
+	mmc1_pins: pinmux_mmc1_pins {
+		pinctrl-single,pins = <
+			0xa2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk */
+			0xa4 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc1_cmd */
+			0xa6 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc1_dat0 */
+			0xa8 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat1 */
+			0xaa (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat2 */
+			0xac (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat3 */
+		>;
+	};
+
+	mmc5_pins: pinmux_mmc5_pins {
+		pinctrl-single,pins = <
+			0x108 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_clk */
+			0x10a (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc5_cmd */
+			0x10c (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc5_dat0 */
+			0x10e (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat1 */
+			0x110 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat2 */
+			0x112 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat3 */
+		>;
+	};
+};
+
+/* PMIC */
+&i2c1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c1_pins>;
+
+	clock-frequency = <400000>;
+
+	twl: twl at 48 {
+		reg = <0x48>;
+		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;		/* IRQ_SYS_1N cascaded to gic */
+		interrupt-parent = <&gic>;
+	};
+
+	twl6040: twl at 4b {
+		compatible = "ti,twl6040";
+		reg = <0x4b>;
+		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;		/* IRQ_SYS_2N cascaded to gic */
+		interrupt-parent = <&gic>;
+		ti,audpwron-gpio = <&gpio6 0 GPIO_ACTIVE_HIGH>;		/* gpio_160 */
+
+		vio-supply = <&v1v8>;
+		v2v1-supply = <&v2v1>;
+		enable-active-high;
+	};
+};
+
+#include "twl6030.dtsi"
+#include "twl6030_omap4.dtsi"
+
+/* on-board bluetooth / WiFi module */
+&i2c4 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&i2c4_pins>;
+
+	clock-frequency = <400000>;
+};
+
+&mmc1 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc1_pins>;
+
+	vmmc-supply = <&vmmc>;
+	ti,bus-width = <4>;
+	ti,non-removable;		/* FIXME: use PMIC_MMC detect */
+};
+
+&mmc2 {
+	status = "disabled";
+};
+
+/* mmc3 is available to the expansion board */
+
+&mmc4 {
+	status = "disabled";
+};
+
+/* on-board WiFi module */
+&mmc5 {
+	pinctrl-names = "default";
+	pinctrl-0 = <&mmc5_pins>;
+
+	vmmc-supply = <&w2cbw0015_vmmc>;
+	ti,bus-width = <4>;
+	ti,non-removable;
+	cap-power-off-card;
+};
+
+&twl_usb_comparator {
+	usb-supply = <&vusb>;
+};
+
+&usb_otg_hs {
+	interface-type = <1>;
+	mode = <3>;
+	power = <50>;
+};
+
+&usbhshost {
+	port1-mode = "ehci-phy";
+};
+
+&usbhsehci {
+	phys = <&hsusb1_phy>;
+};
+
-- 
1.8.1.2

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Florian Vaussard]

Add the necessary DTS nodes to enable the micro-HDMI output on Parlor
board.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap4-duovero-parlor.dts | 36 ++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts b/arch/arm/boot/dts/omap4-duovero-parlor.dts
index 96f51d8..d038242 100644
--- a/arch/arm/boot/dts/omap4-duovero-parlor.dts
+++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
@@ -15,6 +15,10 @@
 	model = "OMAP4430 Gumstix Duovero on Parlor";
 	compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
 
+	aliases {
+		display0 = &hdmi0;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 		led0 {
@@ -35,6 +39,15 @@
 			gpio-key,wakeup;
 		};
 	};
+
+	hdmi0: connector@0 {
+		compatible = "hdmi-connector";
+		label = "hdmi";
+
+		hdmi_connector_in: endpoint {
+			remote-endpoint = <&hdmi_out>;
+		};
+	};
 };
 
 &omap4_pmx_core {
@@ -77,6 +90,15 @@
 			0x30 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a24.gpio_48: amdix enabled */
 		>;
 	};
+
+	dss_hdmi_pins: pinmux_dss_hdmi_pins {
+		pinctrl-single,pins = <
+			0x58 (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_hpd.hdmi_hpd */
+			0x5a (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_cec.hdmi_cec */
+			0x5c (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_ddc_scl.hdmi_ddc_scl */
+			0x5e (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_ddc_sda.hdmi_ddc_sda */
+		>;
+	};
 };
 
 &i2c2 {
@@ -143,4 +165,18 @@
 	};
 };
 
+&dss {
+	status = "ok";
+};
+
+&hdmi {
+	status = "ok";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&dss_hdmi_pins>;
+
+	hdmi_out: endpoint {
+		remote-endpoint = <&hdmi_connector_in>;
+	};
+};
 
-- 
1.8.1.2

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Florian Vaussard]

Add the necessary DTS nodes to enable the micro-HDMI output on Parlor
board.

Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
---
 arch/arm/boot/dts/omap4-duovero-parlor.dts | 36 ++++++++++++++++++++++++++++++
 1 file changed, 36 insertions(+)

diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts b/arch/arm/boot/dts/omap4-duovero-parlor.dts
index 96f51d8..d038242 100644
--- a/arch/arm/boot/dts/omap4-duovero-parlor.dts
+++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
@@ -15,6 +15,10 @@
 	model = "OMAP4430 Gumstix Duovero on Parlor";
 	compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
 
+	aliases {
+		display0 = &hdmi0;
+	};
+
 	leds {
 		compatible = "gpio-leds";
 		led0 {
@@ -35,6 +39,15 @@
 			gpio-key,wakeup;
 		};
 	};
+
+	hdmi0: connector at 0 {
+		compatible = "hdmi-connector";
+		label = "hdmi";
+
+		hdmi_connector_in: endpoint {
+			remote-endpoint = <&hdmi_out>;
+		};
+	};
 };
 
 &omap4_pmx_core {
@@ -77,6 +90,15 @@
 			0x30 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a24.gpio_48: amdix enabled */
 		>;
 	};
+
+	dss_hdmi_pins: pinmux_dss_hdmi_pins {
+		pinctrl-single,pins = <
+			0x58 (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_hpd.hdmi_hpd */
+			0x5a (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_cec.hdmi_cec */
+			0x5c (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_ddc_scl.hdmi_ddc_scl */
+			0x5e (PIN_INPUT_PULLUP | MUX_MODE0)	/* hdmi_ddc_sda.hdmi_ddc_sda */
+		>;
+	};
 };
 
 &i2c2 {
@@ -143,4 +165,18 @@
 	};
 };
 
+&dss {
+	status = "ok";
+};
+
+&hdmi {
+	status = "ok";
+
+	pinctrl-names = "default";
+	pinctrl-0 = <&dss_hdmi_pins>;
+
+	hdmi_out: endpoint {
+		remote-endpoint = <&hdmi_connector_in>;
+	};
+};
 
-- 
1.8.1.2

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
> +	hdmi0: connector@0 {
> +		compatible = "hdmi-connector";

This looks way to generic a compatible string.  Are you sure it's
correct?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
> +	hdmi0: connector at 0 {
> +		compatible = "hdmi-connector";

This looks way to generic a compatible string.  Are you sure it's
correct?

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Javier Martinez Canillas]

Hi Russell,

On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
>> +     hdmi0: connector@0 {
>> +             compatible = "hdmi-connector";
>
> This looks way to generic a compatible string.  Are you sure it's
> correct?
>

That compatible string is correct according to the latest series
posted by Tomi Valkeinen to add DT bindings for the OMAP Display
SubSystem (DSS) [0].

The property is added on this patch [1] and as far as I understood the
idea is that it could be a generic DT binding that can be used by
platform specific HDMI connectors like the omap dss HDMI connector
[2].

I'm adding Tomi to the cc list so he can a correct me if I'm wrong.

Thanks a lot and best regards,
Javier

[0]: http://www.spinics.net/lists/linux-omap/msg102522.html
[1]: http://www.spinics.net/lists/linux-omap/msg102559.html
[2]: http://www.spinics.net/lists/arm-kernel/msg302197.html

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Javier Martinez Canillas]

Hi Russell,

On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
>> +     hdmi0: connector at 0 {
>> +             compatible = "hdmi-connector";
>
> This looks way to generic a compatible string.  Are you sure it's
> correct?
>

That compatible string is correct according to the latest series
posted by Tomi Valkeinen to add DT bindings for the OMAP Display
SubSystem (DSS) [0].

The property is added on this patch [1] and as far as I understood the
idea is that it could be a generic DT binding that can be used by
platform specific HDMI connectors like the omap dss HDMI connector
[2].

I'm adding Tomi to the cc list so he can a correct me if I'm wrong.

Thanks a lot and best regards,
Javier

[0]: http://www.spinics.net/lists/linux-omap/msg102522.html
[1]: http://www.spinics.net/lists/linux-omap/msg102559.html
[2]: http://www.spinics.net/lists/arm-kernel/msg302197.html

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Florian Vaussard]

Hi Russell, Javier,

On 02/24/2014 09:22 PM, Javier Martinez Canillas wrote:
> Hi Russell,
> 
> On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
>>> +     hdmi0: connector@0 {
>>> +             compatible = "hdmi-connector";
>>
>> This looks way to generic a compatible string.  Are you sure it's
>> correct?
>>
> 
> That compatible string is correct according to the latest series
> posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> SubSystem (DSS) [0].
> 

Indeed, this compatible string comes from the DSS series.

> The property is added on this patch [1] and as far as I understood the
> idea is that it could be a generic DT binding that can be used by
> platform specific HDMI connectors like the omap dss HDMI connector
> [2].
> 

On the other side, looking at
drivers/video/omap2/displays-new/connector-hdmi.c from the DSS series
[1], the compatible string is "omapdss,hdmi-connector", which makes me
wonder which one should be used :) BTW, "omapdss" seems a strange
prefix, isn't it?

Tomi, any inputs?

Regards,
Florian

[1]
https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/video/omap2/displays-new/connector-hdmi.c?h=work/dss-dt-review-3

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Florian Vaussard]

Hi Russell, Javier,

On 02/24/2014 09:22 PM, Javier Martinez Canillas wrote:
> Hi Russell,
> 
> On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
>> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
>>> +     hdmi0: connector at 0 {
>>> +             compatible = "hdmi-connector";
>>
>> This looks way to generic a compatible string.  Are you sure it's
>> correct?
>>
> 
> That compatible string is correct according to the latest series
> posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> SubSystem (DSS) [0].
> 

Indeed, this compatible string comes from the DSS series.

> The property is added on this patch [1] and as far as I understood the
> idea is that it could be a generic DT binding that can be used by
> platform specific HDMI connectors like the omap dss HDMI connector
> [2].
> 

On the other side, looking at
drivers/video/omap2/displays-new/connector-hdmi.c from the DSS series
[1], the compatible string is "omapdss,hdmi-connector", which makes me
wonder which one should be used :) BTW, "omapdss" seems a strange
prefix, isn't it?

Tomi, any inputs?

Regards,
Florian

[1]
https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/video/omap2/displays-new/connector-hdmi.c?h=work/dss-dt-review-3

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Mon, Feb 24, 2014 at 05:22:27PM -0300, Javier Martinez Canillas wrote:
> Hi Russell,
> 
> On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
> >> +     hdmi0: connector@0 {
> >> +             compatible = "hdmi-connector";
> >
> > This looks way to generic a compatible string.  Are you sure it's
> > correct?
> >
> 
> That compatible string is correct according to the latest series
> posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> SubSystem (DSS) [0].

in which case:

N    N   AA     CCCC  K  K
NN   N  A  A   C    C K K
N N  N A    A C       KK
N  N N AAAAAA C       KK
N   NN A    A  C    C K K
N    N A    A   CCCC  K  K

Yes, that's a very big nack.  Two things:

1. OMAP really doesn't have the right to define a compatible string which
   is as generic as "hdmi-connector".

2. Even with "omapdss," before it, the convention that DT people have adopted
   is for the prefix to be "companyname," and not a subsystem.

I'm not the only one with this concern - I discussed it with Arnd last
night and his comments were about it being "obviously bogus".

> The property is added on this patch [1] and as far as I understood the
> idea is that it could be a generic DT binding that can be used by
> platform specific HDMI connectors like the omap dss HDMI connector [2].

Why do the physical connectors need a DT binding?  Surely what needs the
DT binding is the HDMI encoder - and that certainly should no way be a
generic name, because there's no such thing as a generic HDMI encoder
chip.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Mon, Feb 24, 2014 at 05:22:27PM -0300, Javier Martinez Canillas wrote:
> Hi Russell,
> 
> On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
> <linux@arm.linux.org.uk> wrote:
> > On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
> >> +     hdmi0: connector at 0 {
> >> +             compatible = "hdmi-connector";
> >
> > This looks way to generic a compatible string.  Are you sure it's
> > correct?
> >
> 
> That compatible string is correct according to the latest series
> posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> SubSystem (DSS) [0].

in which case:

N    N   AA     CCCC  K  K
NN   N  A  A   C    C K K
N N  N A    A C       KK
N  N N AAAAAA C       KK
N   NN A    A  C    C K K
N    N A    A   CCCC  K  K

Yes, that's a very big nack.  Two things:

1. OMAP really doesn't have the right to define a compatible string which
   is as generic as "hdmi-connector".

2. Even with "omapdss," before it, the convention that DT people have adopted
   is for the prefix to be "companyname," and not a subsystem.

I'm not the only one with this concern - I discussed it with Arnd last
night and his comments were about it being "obviously bogus".

> The property is added on this patch [1] and as far as I understood the
> idea is that it could be a generic DT binding that can be used by
> platform specific HDMI connectors like the omap dss HDMI connector [2].

Why do the physical connectors need a DT binding?  Surely what needs the
DT binding is the HDMI encoder - and that certainly should no way be a
generic name, because there's no such thing as a generic HDMI encoder
chip.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Florian Vaussard]

Hi,

On 02/25/2014 01:39 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 24, 2014 at 05:22:27PM -0300, Javier Martinez Canillas wrote:
>> Hi Russell,
>>
>> On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
>>>> +     hdmi0: connector@0 {
>>>> +             compatible = "hdmi-connector";
>>>
>>> This looks way to generic a compatible string.  Are you sure it's
>>> correct?
>>>
>>
>> That compatible string is correct according to the latest series
>> posted by Tomi Valkeinen to add DT bindings for the OMAP Display
>> SubSystem (DSS) [0].
> 
> in which case:
> 
> N    N   AA     CCCC  K  K
> NN   N  A  A   C    C K K
> N N  N A    A C       KK
> N  N N AAAAAA C       KK
> N   NN A    A  C    C K K
> N    N A    A   CCCC  K  K
> 

What a nice nack.

> Yes, that's a very big nack.  Two things:
> 
> 1. OMAP really doesn't have the right to define a compatible string which
>    is as generic as "hdmi-connector".
> 
> 2. Even with "omapdss," before it, the convention that DT people have adopted
>    is for the prefix to be "companyname," and not a subsystem.
> 
> I'm not the only one with this concern - I discussed it with Arnd last
> night and his comments were about it being "obviously bogus".
>

I agree. It should probably be "ti,omapdss-hdmi-connector", or simply
"ti,hdmi-connector", if any.

>> The property is added on this patch [1] and as far as I understood the
>> idea is that it could be a generic DT binding that can be used by
>> platform specific HDMI connectors like the omap dss HDMI connector [2].
> 
> Why do the physical connectors need a DT binding?  Surely what needs the
> DT binding is the HDMI encoder - and that certainly should no way be a
> generic name, because there's no such thing as a generic HDMI encoder
> chip.
> 

The HDMI IP is declared in omap4.dtsi, with the compatible
"ti,omap4-hdmi". The code of the HDMI connector [1] seems to mainly call
ops of the connected endpoint, so it seems to act as a logical
termination in the DSS chain, but I may be wrong.

Regards,
Florian

[1]
https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/video/omap2/displays-new/connector-hdmi.c?h=work%2Fdss-dt-review-3

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Florian Vaussard]

Hi,

On 02/25/2014 01:39 PM, Russell King - ARM Linux wrote:
> On Mon, Feb 24, 2014 at 05:22:27PM -0300, Javier Martinez Canillas wrote:
>> Hi Russell,
>>
>> On Mon, Feb 24, 2014 at 3:03 PM, Russell King - ARM Linux
>> <linux@arm.linux.org.uk> wrote:
>>> On Mon, Feb 24, 2014 at 06:07:49PM +0100, Florian Vaussard wrote:
>>>> +     hdmi0: connector at 0 {
>>>> +             compatible = "hdmi-connector";
>>>
>>> This looks way to generic a compatible string.  Are you sure it's
>>> correct?
>>>
>>
>> That compatible string is correct according to the latest series
>> posted by Tomi Valkeinen to add DT bindings for the OMAP Display
>> SubSystem (DSS) [0].
> 
> in which case:
> 
> N    N   AA     CCCC  K  K
> NN   N  A  A   C    C K K
> N N  N A    A C       KK
> N  N N AAAAAA C       KK
> N   NN A    A  C    C K K
> N    N A    A   CCCC  K  K
> 

What a nice nack.

> Yes, that's a very big nack.  Two things:
> 
> 1. OMAP really doesn't have the right to define a compatible string which
>    is as generic as "hdmi-connector".
> 
> 2. Even with "omapdss," before it, the convention that DT people have adopted
>    is for the prefix to be "companyname," and not a subsystem.
> 
> I'm not the only one with this concern - I discussed it with Arnd last
> night and his comments were about it being "obviously bogus".
>

I agree. It should probably be "ti,omapdss-hdmi-connector", or simply
"ti,hdmi-connector", if any.

>> The property is added on this patch [1] and as far as I understood the
>> idea is that it could be a generic DT binding that can be used by
>> platform specific HDMI connectors like the omap dss HDMI connector [2].
> 
> Why do the physical connectors need a DT binding?  Surely what needs the
> DT binding is the HDMI encoder - and that certainly should no way be a
> generic name, because there's no such thing as a generic HDMI encoder
> chip.
> 

The HDMI IP is declared in omap4.dtsi, with the compatible
"ti,omap4-hdmi". The code of the HDMI connector [1] seems to mainly call
ops of the connected endpoint, so it seems to act as a logical
termination in the DSS chain, but I may be wrong.

Regards,
Florian

[1]
https://git.kernel.org/cgit/linux/kernel/git/tomba/linux.git/tree/drivers/video/omap2/displays-new/connector-hdmi.c?h=work%2Fdss-dt-review-3

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Sebastian Reichel]

[-- Attachment #1: Type: text/plain, Size: 1993 bytes --]

Hi,

On Tue, Feb 25, 2014 at 12:39:21PM +0000, Russell King - ARM Linux wrote:
> > That compatible string is correct according to the latest series
> > posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> > SubSystem (DSS) [0].
> 
> in which case:
> 
> N    N   AA     CCCC  K  K
> NN   N  A  A   C    C K K
> N N  N A    A C       KK
> N  N N AAAAAA C       KK
> N   NN A    A  C    C K K
> N    N A    A   CCCC  K  K
> 
> Yes, that's a very big nack.  Two things:
> 
> 1. OMAP really doesn't have the right to define a compatible string which
>    is as generic as "hdmi-connector".

AFAIK the idea was to have "hdmi-connector" as part of the common
display framework [1]. It's not really platform specific, since it's
just a connector.

Since omapdss does not yet implement the common display framework,
but wants to keep a stable DT API it rewrites "hdmi-connector" to
"omapdss,hdmi-connector" for now.

> 2. Even with "omapdss," before it, the convention that DT people have adopted
>    is for the prefix to be "companyname," and not a subsystem.
>
> I'm not the only one with this concern - I discussed it with Arnd last
> night and his comments were about it being "obviously bogus".
> 
> > The property is added on this patch [1] and as far as I understood the
> > idea is that it could be a generic DT binding that can be used by
> > platform specific HDMI connectors like the omap dss HDMI connector [2].
> 
> Why do the physical connectors need a DT binding?

This is the termination of the video bus and useful information for
xrandr.

> Surely what needs the DT binding is the HDMI encoder - and that
> certainly should no way be a generic name, because there's no such
> thing as a generic HDMI encoder chip.

The HDMI encoder and companion chips are described separatly and
properly prefixed [0].

[0] http://www.spinics.net/lists/linux-omap/msg102522.html
[1] https://lwn.net/Articles/563157/

-- Sebastian

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Sebastian Reichel]

Hi,

On Tue, Feb 25, 2014 at 12:39:21PM +0000, Russell King - ARM Linux wrote:
> > That compatible string is correct according to the latest series
> > posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> > SubSystem (DSS) [0].
> 
> in which case:
> 
> N    N   AA     CCCC  K  K
> NN   N  A  A   C    C K K
> N N  N A    A C       KK
> N  N N AAAAAA C       KK
> N   NN A    A  C    C K K
> N    N A    A   CCCC  K  K
> 
> Yes, that's a very big nack.  Two things:
> 
> 1. OMAP really doesn't have the right to define a compatible string which
>    is as generic as "hdmi-connector".

AFAIK the idea was to have "hdmi-connector" as part of the common
display framework [1]. It's not really platform specific, since it's
just a connector.

Since omapdss does not yet implement the common display framework,
but wants to keep a stable DT API it rewrites "hdmi-connector" to
"omapdss,hdmi-connector" for now.

> 2. Even with "omapdss," before it, the convention that DT people have adopted
>    is for the prefix to be "companyname," and not a subsystem.
>
> I'm not the only one with this concern - I discussed it with Arnd last
> night and his comments were about it being "obviously bogus".
> 
> > The property is added on this patch [1] and as far as I understood the
> > idea is that it could be a generic DT binding that can be used by
> > platform specific HDMI connectors like the omap dss HDMI connector [2].
> 
> Why do the physical connectors need a DT binding?

This is the termination of the video bus and useful information for
xrandr.

> Surely what needs the DT binding is the HDMI encoder - and that
> certainly should no way be a generic name, because there's no such
> thing as a generic HDMI encoder chip.

The HDMI encoder and companion chips are described separatly and
properly prefixed [0].

[0] http://www.spinics.net/lists/linux-omap/msg102522.html
[1] https://lwn.net/Articles/563157/

-- Sebastian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140225/958a98e6/attachment.sig>

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Laurent Pinchart]

[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]

On Tuesday 25 February 2014 14:41:48 Sebastian Reichel wrote:
> On Tue, Feb 25, 2014 at 12:39:21PM +0000, Russell King - ARM Linux wrote:
> > > That compatible string is correct according to the latest series
> > > posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> > > SubSystem (DSS) [0].
> > 
> > in which case:
> > 
> > N    N   AA     CCCC  K  K
> > NN   N  A  A   C    C K K
> > N N  N A    A C       KK
> > N  N N AAAAAA C       KK
> > N   NN A    A  C    C K K
> > N    N A    A   CCCC  K  K
> > 
> > Yes, that's a very big nack.  Two things:
> > 
> > 1. OMAP really doesn't have the right to define a compatible string which
> >    is as generic as "hdmi-connector".
> 
> AFAIK the idea was to have "hdmi-connector" as part of the common
> display framework [1]. It's not really platform specific, since it's
> just a connector.
> 
> Since omapdss does not yet implement the common display framework,
> but wants to keep a stable DT API it rewrites "hdmi-connector" to
> "omapdss,hdmi-connector" for now.

And since the common display framework has been pretty much nacked, we have no 
framework on which drivers can rely ;-)

> > 2. Even with "omapdss," before it, the convention that DT people have
> >    adopted is for the prefix to be "companyname," and not a subsystem.
> > 
> > I'm not the only one with this concern - I discussed it with Arnd last
> > night and his comments were about it being "obviously bogus".
> > 
> > > The property is added on this patch [1] and as far as I understood the
> > > idea is that it could be a generic DT binding that can be used by
> > > platform specific HDMI connectors like the omap dss HDMI connector [2].
> > 
> > Why do the physical connectors need a DT binding?
> 
> This is the termination of the video bus and useful information for
> xrandr.

I don't think all physical connectors require a DT binding per-se, but they 
need to be represented in DT as they're part of the hardware. We could push 
connector-related information to the nodes of all chips that have interfaces 
wired directly to connectors, but that would result in more complex DT 
bindings and core. I believe modeling connectors using separate DT nodes is be 
best, and would allow easier support for more complex connectors that carry 
multiple streams/signals in parallel (video, audio, DDC, ...).

> > Surely what needs the DT binding is the HDMI encoder - and that certainly
> > should no way be a generic name, because there's no such thing as a
> > generic HDMI encoder chip.
> 
> The HDMI encoder and companion chips are described separatly and properly
> prefixed [0].
> 
> [0] http://www.spinics.net/lists/linux-omap/msg102522.html
> [1] https://lwn.net/Articles/563157/

-- 
Regards,

Laurent Pinchart

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Laurent Pinchart]

On Tuesday 25 February 2014 14:41:48 Sebastian Reichel wrote:
> On Tue, Feb 25, 2014 at 12:39:21PM +0000, Russell King - ARM Linux wrote:
> > > That compatible string is correct according to the latest series
> > > posted by Tomi Valkeinen to add DT bindings for the OMAP Display
> > > SubSystem (DSS) [0].
> > 
> > in which case:
> > 
> > N    N   AA     CCCC  K  K
> > NN   N  A  A   C    C K K
> > N N  N A    A C       KK
> > N  N N AAAAAA C       KK
> > N   NN A    A  C    C K K
> > N    N A    A   CCCC  K  K
> > 
> > Yes, that's a very big nack.  Two things:
> > 
> > 1. OMAP really doesn't have the right to define a compatible string which
> >    is as generic as "hdmi-connector".
> 
> AFAIK the idea was to have "hdmi-connector" as part of the common
> display framework [1]. It's not really platform specific, since it's
> just a connector.
> 
> Since omapdss does not yet implement the common display framework,
> but wants to keep a stable DT API it rewrites "hdmi-connector" to
> "omapdss,hdmi-connector" for now.

And since the common display framework has been pretty much nacked, we have no 
framework on which drivers can rely ;-)

> > 2. Even with "omapdss," before it, the convention that DT people have
> >    adopted is for the prefix to be "companyname," and not a subsystem.
> > 
> > I'm not the only one with this concern - I discussed it with Arnd last
> > night and his comments were about it being "obviously bogus".
> > 
> > > The property is added on this patch [1] and as far as I understood the
> > > idea is that it could be a generic DT binding that can be used by
> > > platform specific HDMI connectors like the omap dss HDMI connector [2].
> > 
> > Why do the physical connectors need a DT binding?
> 
> This is the termination of the video bus and useful information for
> xrandr.

I don't think all physical connectors require a DT binding per-se, but they 
need to be represented in DT as they're part of the hardware. We could push 
connector-related information to the nodes of all chips that have interfaces 
wired directly to connectors, but that would result in more complex DT 
bindings and core. I believe modeling connectors using separate DT nodes is be 
best, and would allow easier support for more complex connectors that carry 
multiple streams/signals in parallel (video, audio, DDC, ...).

> > Surely what needs the DT binding is the HDMI encoder - and that certainly
> > should no way be a generic name, because there's no such thing as a
> > generic HDMI encoder chip.
> 
> The HDMI encoder and companion chips are described separatly and properly
> prefixed [0].
> 
> [0] http://www.spinics.net/lists/linux-omap/msg102522.html
> [1] https://lwn.net/Articles/563157/

-- 
Regards,

Laurent Pinchart
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140225/b6e28a40/attachment.sig>

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote:
> I don't think all physical connectors require a DT binding per-se, but they 
> need to be represented in DT as they're part of the hardware. We could push 
> connector-related information to the nodes of all chips that have interfaces 
> wired directly to connectors, but that would result in more complex DT 
> bindings and core. I believe modeling connectors using separate DT nodes is be 
> best, and would allow easier support for more complex connectors that carry 
> multiple streams/signals in parallel (video, audio, DDC, ...).

There is some sanity to representing physical connectors in DT, but it's
not for the reason you mention above.  If you consider that it's possible
on PCs to find out what connectors are on the motherboard and where they
are located, this is very useful information to be stored and presented.

However, the idea that you combine streams at connectors is not a
universal truth, and is certainly false for HDMI.  HDMI combines video
and audio at the encoder stage, not at the connector stage, and many
HDMI encoders will provide everything required for driving the connector.

However, my major objection here is not really that: my major objection
is using something as generic as "hdmi-connector" as a compatible string.
The reason is that we have to remember that DT is not just "a Linux thing".
It's /supposed/ to be an OS independent representation of the hardware.

If we invent something generic called a "hdmi-connector" then we had
better first do a thorough search to make sure we're not trampling on
anything which is standardized or becoming a standard - if there is,
we should work with them - and if that's not possible, then we need to
distingush ourselves from them.

What we can't do is go around inventing generic stuff without having our
eyes wide open.

So, here's a good question to probe how far this has been thought through
already: what has been done to discuss the creation of this generic
"hdmi-connector" thing with the various parties who are interested in
HDMI outputs under DRM using device tree?

If that hasn't happened, that's quite a failing - it means that we're
on the road to having two _implementation specific_ DT representations
for the same hardware - one for fbdev and one for DRM.  That really
isn't on.

Yes, it then opens a pandora's box of problems about how we determine
whether DRM or fbdev should bind to the DT nodes, but that should be
an entirely separate issue (and, ideally of course, both should use
the same sub-drivers for the components.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote:
> I don't think all physical connectors require a DT binding per-se, but they 
> need to be represented in DT as they're part of the hardware. We could push 
> connector-related information to the nodes of all chips that have interfaces 
> wired directly to connectors, but that would result in more complex DT 
> bindings and core. I believe modeling connectors using separate DT nodes is be 
> best, and would allow easier support for more complex connectors that carry 
> multiple streams/signals in parallel (video, audio, DDC, ...).

There is some sanity to representing physical connectors in DT, but it's
not for the reason you mention above.  If you consider that it's possible
on PCs to find out what connectors are on the motherboard and where they
are located, this is very useful information to be stored and presented.

However, the idea that you combine streams at connectors is not a
universal truth, and is certainly false for HDMI.  HDMI combines video
and audio at the encoder stage, not at the connector stage, and many
HDMI encoders will provide everything required for driving the connector.

However, my major objection here is not really that: my major objection
is using something as generic as "hdmi-connector" as a compatible string.
The reason is that we have to remember that DT is not just "a Linux thing".
It's /supposed/ to be an OS independent representation of the hardware.

If we invent something generic called a "hdmi-connector" then we had
better first do a thorough search to make sure we're not trampling on
anything which is standardized or becoming a standard - if there is,
we should work with them - and if that's not possible, then we need to
distingush ourselves from them.

What we can't do is go around inventing generic stuff without having our
eyes wide open.

So, here's a good question to probe how far this has been thought through
already: what has been done to discuss the creation of this generic
"hdmi-connector" thing with the various parties who are interested in
HDMI outputs under DRM using device tree?

If that hasn't happened, that's quite a failing - it means that we're
on the road to having two _implementation specific_ DT representations
for the same hardware - one for fbdev and one for DRM.  That really
isn't on.

Yes, it then opens a pandora's box of problems about how we determine
whether DRM or fbdev should bind to the DT nodes, but that should be
an entirely separate issue (and, ideally of course, both should use
the same sub-drivers for the components.)

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 8151 bytes --]

Hi,

On 25/02/14 22:56, Russell King - ARM Linux wrote:
> On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote:

First I want to summarize the omapdss DT bindings, even if it was
already more or less covered earlier:

We have a bunch of panels and encoders used on OMAP boards, and we have
separate, omapdss specific, drivers for those. My plan is to continue
improving those drivers until they can be platform independent. This
would be the Common Display Framework that's been discussed (or a
precursor to it).

We need DT bindings for OMAP display, and one option would've been
adding a compatible string of "ti,xxx" for every panel and encoder. That
would obviously be wrong DT representation. So I wanted to do proper DT
bindings, with proper compatible string.

This creates the problem that we don't have generic drivers for those
components yet. For this, I created a hack that, on OMAP, appends
"omapdss," to the display components at boot time. This way we can have
OMAP specific drivers for the time being, but others could still use the
same bindings for their platform and platform specific drivers with
similar trick.

Note that the above is not merged yet, but I'd really want to get it in
for the next merge window, so if that general concept is bad, please
nack it asap. And preferably give ideas for an alternative =).

>> I don't think all physical connectors require a DT binding per-se, but they 
>> need to be represented in DT as they're part of the hardware. We could push 
>> connector-related information to the nodes of all chips that have interfaces 
>> wired directly to connectors, but that would result in more complex DT 
>> bindings and core. I believe modeling connectors using separate DT nodes is be 
>> best, and would allow easier support for more complex connectors that carry 
>> multiple streams/signals in parallel (video, audio, DDC, ...).

There are things we need to represent for the connectors. For example, a
+5V going to the connector is not managed by any IP. In some cases
neither is a hotplug detect GPIO. The i2c lines for the DDC need to be
managed by someone (with DVI. HDMI DDC on OMAP is managed by by the HDMI
IP).

I guess one could argue that those are standard properties of HDMI or
DVI, and thus could well be managed by the HDMI or DVI encoder, even if
the encoder IP itself doesn't have anything to do with those. Maybe they
could, but I think modeling the connector separately is more correct,
and allows more freedom.

Say, the HDMI could as well be directly wired to a panel, without any
connector, although this is perhaps more common with eDP. In that case
the connector related things can be just left out.

Additionally, but perhaps not strictly needed, the connector represents
a "termination" for the display pipeline, so there's a distinct display
element at the end of the chain, sometimes a panel, sometimes a
connector, which marks the end. This makes the pipeline consistent in
the case where you've got an encoder, output of which goes on some
boards to a connector and on some boards to a panel (compared to some
boards having a panel after the encoder, and some having nothing).

> There is some sanity to representing physical connectors in DT, but it's
> not for the reason you mention above.  If you consider that it's possible
> on PCs to find out what connectors are on the motherboard and where they
> are located, this is very useful information to be stored and presented.
> 
> However, the idea that you combine streams at connectors is not a
> universal truth, and is certainly false for HDMI.  HDMI combines video
> and audio at the encoder stage, not at the connector stage, and many
> HDMI encoders will provide everything required for driving the connector.
> 
> However, my major objection here is not really that: my major objection
> is using something as generic as "hdmi-connector" as a compatible string.
> The reason is that we have to remember that DT is not just "a Linux thing".
> It's /supposed/ to be an OS independent representation of the hardware.
> 
> If we invent something generic called a "hdmi-connector" then we had
> better first do a thorough search to make sure we're not trampling on
> anything which is standardized or becoming a standard - if there is,
> we should work with them - and if that's not possible, then we need to
> distingush ourselves from them.

Yes, I agree that the connectors (DVI, analog-tv, and HDMI) are in a
sense much more generic than bindings for a single IP, and thus more
important to get right.

> What we can't do is go around inventing generic stuff without having our
> eyes wide open.
> 
> So, here's a good question to probe how far this has been thought through
> already: what has been done to discuss the creation of this generic
> "hdmi-connector" thing with the various parties who are interested in
> HDMI outputs under DRM using device tree?

They have been discussed, in the context of Common Display Framework
proposals, and in the context of OMAP DSS DT bindings. They've seen
multiple review rounds, but I agree that finding about the connectors
there may be rather difficult if one is not interested in OMAP DSS, or
one see CDF as nonsense.

Those OMAP bindings are used on both OMAP fbdev and DRM drivers, so at
least in that case they've been proven to work on both frameworks.

> If that hasn't happened, that's quite a failing - it means that we're
> on the road to having two _implementation specific_ DT representations
> for the same hardware - one for fbdev and one for DRM.  That really
> isn't on.

I hope not. Afais, the bindings are really about the HW. Not fbdev or DRM.

At the moment I do see that usually the existing fbdev and drm bindings
are, in my opinion, quite bad. They don't give proper and detailed
description of the hardware, in a way that should work on other
platforms with very different display pipelines.

The proposed bindings in my patches are the designed to be as generic as
we've (mostly me and Laurent) been able to make them, and very similar
ones have been used by Laurent on shmobile for his CDF patch series.

The HDMI connector in particular doesn't even define much anything at
all. At the moment, it only defines the connection to the previous item
in the display pipeline, usually the HDMI encoder. The +5V I plan to add
at some point, and it should be a clear addition, it's there by the
spec. The same for HPD and i2c, although those should be optional so
that an IP can handle those if the system is so designed.

So while I fully confess that I haven't looked at other platform's HDMI,
I don't see how the above could go badly wrong. The connector would
obviously be extended later to add any missing features.

> Yes, it then opens a pandora's box of problems about how we determine
> whether DRM or fbdev should bind to the DT nodes, but that should be
> an entirely separate issue (and, ideally of course, both should use
> the same sub-drivers for the components.)

Yes, this is what the common display framework tries to accomplish. But
as you say, it's a separate issue. The DT bindings should just model the
hardware so well that we're as confident as we can be that the current
boards can be described with those.

So how to go forward? It's very difficult to get feedback on complex DT
bindings. I recently posted only the DT documentation part for OMAP DSS
[1], in hopes to get some feedback for a smaller series, but nothing so
far. It might be easier to look at the whole series [2] to see how the
board dts files are changed, though.

Maybe the subject "OMAP DSS DT bindings documentation" is not quite
correct, as there's really nothing OMAP specific there except the SoC
bindings itself. Perhaps re-sending with subject of "Generic display
bindings" would catch more eyes.

 Tomi

[1]
http://mid.gmane.org/1392294752-18762-1-git-send-email-tomi.valkeinen@ti.com

[2]
http://mid.gmane.org/1390301833-24944-1-git-send-email-tomi.valkeinen@ti.com



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Tomi Valkeinen]

Hi,

On 25/02/14 22:56, Russell King - ARM Linux wrote:
> On Tue, Feb 25, 2014 at 05:51:21PM +0100, Laurent Pinchart wrote:

First I want to summarize the omapdss DT bindings, even if it was
already more or less covered earlier:

We have a bunch of panels and encoders used on OMAP boards, and we have
separate, omapdss specific, drivers for those. My plan is to continue
improving those drivers until they can be platform independent. This
would be the Common Display Framework that's been discussed (or a
precursor to it).

We need DT bindings for OMAP display, and one option would've been
adding a compatible string of "ti,xxx" for every panel and encoder. That
would obviously be wrong DT representation. So I wanted to do proper DT
bindings, with proper compatible string.

This creates the problem that we don't have generic drivers for those
components yet. For this, I created a hack that, on OMAP, appends
"omapdss," to the display components at boot time. This way we can have
OMAP specific drivers for the time being, but others could still use the
same bindings for their platform and platform specific drivers with
similar trick.

Note that the above is not merged yet, but I'd really want to get it in
for the next merge window, so if that general concept is bad, please
nack it asap. And preferably give ideas for an alternative =).

>> I don't think all physical connectors require a DT binding per-se, but they 
>> need to be represented in DT as they're part of the hardware. We could push 
>> connector-related information to the nodes of all chips that have interfaces 
>> wired directly to connectors, but that would result in more complex DT 
>> bindings and core. I believe modeling connectors using separate DT nodes is be 
>> best, and would allow easier support for more complex connectors that carry 
>> multiple streams/signals in parallel (video, audio, DDC, ...).

There are things we need to represent for the connectors. For example, a
+5V going to the connector is not managed by any IP. In some cases
neither is a hotplug detect GPIO. The i2c lines for the DDC need to be
managed by someone (with DVI. HDMI DDC on OMAP is managed by by the HDMI
IP).

I guess one could argue that those are standard properties of HDMI or
DVI, and thus could well be managed by the HDMI or DVI encoder, even if
the encoder IP itself doesn't have anything to do with those. Maybe they
could, but I think modeling the connector separately is more correct,
and allows more freedom.

Say, the HDMI could as well be directly wired to a panel, without any
connector, although this is perhaps more common with eDP. In that case
the connector related things can be just left out.

Additionally, but perhaps not strictly needed, the connector represents
a "termination" for the display pipeline, so there's a distinct display
element at the end of the chain, sometimes a panel, sometimes a
connector, which marks the end. This makes the pipeline consistent in
the case where you've got an encoder, output of which goes on some
boards to a connector and on some boards to a panel (compared to some
boards having a panel after the encoder, and some having nothing).

> There is some sanity to representing physical connectors in DT, but it's
> not for the reason you mention above.  If you consider that it's possible
> on PCs to find out what connectors are on the motherboard and where they
> are located, this is very useful information to be stored and presented.
> 
> However, the idea that you combine streams at connectors is not a
> universal truth, and is certainly false for HDMI.  HDMI combines video
> and audio at the encoder stage, not at the connector stage, and many
> HDMI encoders will provide everything required for driving the connector.
> 
> However, my major objection here is not really that: my major objection
> is using something as generic as "hdmi-connector" as a compatible string.
> The reason is that we have to remember that DT is not just "a Linux thing".
> It's /supposed/ to be an OS independent representation of the hardware.
> 
> If we invent something generic called a "hdmi-connector" then we had
> better first do a thorough search to make sure we're not trampling on
> anything which is standardized or becoming a standard - if there is,
> we should work with them - and if that's not possible, then we need to
> distingush ourselves from them.

Yes, I agree that the connectors (DVI, analog-tv, and HDMI) are in a
sense much more generic than bindings for a single IP, and thus more
important to get right.

> What we can't do is go around inventing generic stuff without having our
> eyes wide open.
> 
> So, here's a good question to probe how far this has been thought through
> already: what has been done to discuss the creation of this generic
> "hdmi-connector" thing with the various parties who are interested in
> HDMI outputs under DRM using device tree?

They have been discussed, in the context of Common Display Framework
proposals, and in the context of OMAP DSS DT bindings. They've seen
multiple review rounds, but I agree that finding about the connectors
there may be rather difficult if one is not interested in OMAP DSS, or
one see CDF as nonsense.

Those OMAP bindings are used on both OMAP fbdev and DRM drivers, so at
least in that case they've been proven to work on both frameworks.

> If that hasn't happened, that's quite a failing - it means that we're
> on the road to having two _implementation specific_ DT representations
> for the same hardware - one for fbdev and one for DRM.  That really
> isn't on.

I hope not. Afais, the bindings are really about the HW. Not fbdev or DRM.

At the moment I do see that usually the existing fbdev and drm bindings
are, in my opinion, quite bad. They don't give proper and detailed
description of the hardware, in a way that should work on other
platforms with very different display pipelines.

The proposed bindings in my patches are the designed to be as generic as
we've (mostly me and Laurent) been able to make them, and very similar
ones have been used by Laurent on shmobile for his CDF patch series.

The HDMI connector in particular doesn't even define much anything at
all. At the moment, it only defines the connection to the previous item
in the display pipeline, usually the HDMI encoder. The +5V I plan to add
at some point, and it should be a clear addition, it's there by the
spec. The same for HPD and i2c, although those should be optional so
that an IP can handle those if the system is so designed.

So while I fully confess that I haven't looked at other platform's HDMI,
I don't see how the above could go badly wrong. The connector would
obviously be extended later to add any missing features.

> Yes, it then opens a pandora's box of problems about how we determine
> whether DRM or fbdev should bind to the DT nodes, but that should be
> an entirely separate issue (and, ideally of course, both should use
> the same sub-drivers for the components.)

Yes, this is what the common display framework tries to accomplish. But
as you say, it's a separate issue. The DT bindings should just model the
hardware so well that we're as confident as we can be that the current
boards can be described with those.

So how to go forward? It's very difficult to get feedback on complex DT
bindings. I recently posted only the DT documentation part for OMAP DSS
[1], in hopes to get some feedback for a smaller series, but nothing so
far. It might be easier to look at the whole series [2] to see how the
board dts files are changed, though.

Maybe the subject "OMAP DSS DT bindings documentation" is not quite
correct, as there's really nothing OMAP specific there except the SoC
bindings itself. Perhaps re-sending with subject of "Generic display
bindings" would catch more eyes.

 Tomi

[1]
http://mid.gmane.org/1392294752-18762-1-git-send-email-tomi.valkeinen at ti.com

[2]
http://mid.gmane.org/1390301833-24944-1-git-send-email-tomi.valkeinen at ti.com


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140226/fcba7e78/attachment.sig>

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote:
> We have a bunch of panels and encoders used on OMAP boards, and we have
> separate, omapdss specific, drivers for those. My plan is to continue
> improving those drivers until they can be platform independent. This
> would be the Common Display Framework that's been discussed (or a
> precursor to it).

I believe CDF has been knocked on the head.

Also - DRM is not going to ever support hotplugging components - this
was discussed at kernel summit last year and David Airlie was quite
adamant about that.  So, any "framework" which forces hotplugging of
components on subsystems isn't going to fly.

This is why we now have the component helpers in the driver model -
to allow devices to be collected together into one logical subsystem
group, and bound/unbound as a group.

Remember that "hotplugging" in this context does not mean that the
user can physically do something with the hardware.  It means that
they're separate devices which can be probed/removed at will.  Every
device in Linux can be bound and unbound from its driver at any time
by userspace, and that is something which is expected to be handled
gracefully.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote:
> We have a bunch of panels and encoders used on OMAP boards, and we have
> separate, omapdss specific, drivers for those. My plan is to continue
> improving those drivers until they can be platform independent. This
> would be the Common Display Framework that's been discussed (or a
> precursor to it).

I believe CDF has been knocked on the head.

Also - DRM is not going to ever support hotplugging components - this
was discussed at kernel summit last year and David Airlie was quite
adamant about that.  So, any "framework" which forces hotplugging of
components on subsystems isn't going to fly.

This is why we now have the component helpers in the driver model -
to allow devices to be collected together into one logical subsystem
group, and bound/unbound as a group.

Remember that "hotplugging" in this context does not mean that the
user can physically do something with the hardware.  It means that
they're separate devices which can be probed/removed at will.  Every
device in Linux can be bound and unbound from its driver at any time
by userspace, and that is something which is expected to be handled
gracefully.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 4490 bytes --]

On 26/02/14 14:03, Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote:
>> We have a bunch of panels and encoders used on OMAP boards, and we have
>> separate, omapdss specific, drivers for those. My plan is to continue
>> improving those drivers until they can be platform independent. This
>> would be the Common Display Framework that's been discussed (or a
>> precursor to it).
> 
> I believe CDF has been knocked on the head.

I refuse to believe that we can't have common drivers for display
components. Maybe CDF as it's been proposed in its current form is not
good (although I haven't seen any explanation why), we need something
like it. So the "CDF" I speak of is not any particular set of patches
already sent, but a framework that would allow us to have generic
display drivers.

I'd be very glad if someone can point me to the discussions where CDF
has been knocked on the head.

> Also - DRM is not going to ever support hotplugging components - this
> was discussed at kernel summit last year and David Airlie was quite

Ok. Very odd stance. Maybe there's a reason for it that I just don't see.

> adamant about that.  So, any "framework" which forces hotplugging of
> components on subsystems isn't going to fly.

CDF doesn't force hotplugging.

Although without hotplugging (hot-unplug not needed), or at least some
minimal form of it, the system is a bit crippled. Leave one kernel
module out, or have one driver probe fail, the whole display subsystem
fails, even if some display pipelines would work fine.

On OMAP4 SDP board, for example, this would mean that if the user
doesn't compile PicoDLP driver, or the driver fails to probe, the two
LCDs and the analog TV out would also fail. Many of the boards don't
even have a PicoDLP module installed, so a fail there somewhere is
guaranteed.

> This is why we now have the component helpers in the driver model -
> to allow devices to be collected together into one logical subsystem
> group, and bound/unbound as a group.

Yep, it's a good start. The component helpers could well be used with CDF.

But if I'm not mistaken, it suffers from the problems above, when there
are multiple independent pipelines (simultaneous or non-simultaneous)
handled by the same IPs.

And, while I may be mistaken, it sounds that the component helpers leave
mostly everything up to the display drivers. Everyone devising their own
way to describe the hardware in DT, and the connections between the
components. Of course, the core component system shouldn't define
anything DT related, as it doesn't. But that part is still needed, which
is where CDF comes in.

In my opinion, the component helpers or similar would be used with CDF
in the beginning, because DRM doesn't support hotplug. Eventually we
should get some kind of basic hotplug support, so that we could add
display pipelines when they are ready.

I need to ask Dave why he is so strongly opposed to hotplugging components.

> Remember that "hotplugging" in this context does not mean that the
> user can physically do something with the hardware.  It means that
> they're separate devices which can be probed/removed at will.  Every
> device in Linux can be bound and unbound from its driver at any time
> by userspace, and that is something which is expected to be handled
> gracefully.

Hmm, sorry, can you rephrase?

My use of hotplug in this context means roughly "add a new display, and
whatever is related to that, when the drivers required have been probed".

So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
etc, could appear even after the initial probe of the display controller.

But all this is, I think, a bit aside the original point. The original
point was about DT bindings. What kind of framework we have in the
kernel side to handle the bindings is an interesting and very important
topic, but they are not strictly tied together.

Even if CDF is the worst thing ever, and needs to die quickly, I think
the proposed DT bindings are still valid. They describe the hardware as
precisely and as future-proofly as we've been able to come up with.
People can use component helpers with them if they see that's a good
approach. Or if on some beautiful day we get an agreement on CDF or
something similar, and we can support hotplugging components, we already
have proper DT bindings for it.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Tomi Valkeinen]

On 26/02/14 14:03, Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 01:14:18PM +0200, Tomi Valkeinen wrote:
>> We have a bunch of panels and encoders used on OMAP boards, and we have
>> separate, omapdss specific, drivers for those. My plan is to continue
>> improving those drivers until they can be platform independent. This
>> would be the Common Display Framework that's been discussed (or a
>> precursor to it).
> 
> I believe CDF has been knocked on the head.

I refuse to believe that we can't have common drivers for display
components. Maybe CDF as it's been proposed in its current form is not
good (although I haven't seen any explanation why), we need something
like it. So the "CDF" I speak of is not any particular set of patches
already sent, but a framework that would allow us to have generic
display drivers.

I'd be very glad if someone can point me to the discussions where CDF
has been knocked on the head.

> Also - DRM is not going to ever support hotplugging components - this
> was discussed at kernel summit last year and David Airlie was quite

Ok. Very odd stance. Maybe there's a reason for it that I just don't see.

> adamant about that.  So, any "framework" which forces hotplugging of
> components on subsystems isn't going to fly.

CDF doesn't force hotplugging.

Although without hotplugging (hot-unplug not needed), or at least some
minimal form of it, the system is a bit crippled. Leave one kernel
module out, or have one driver probe fail, the whole display subsystem
fails, even if some display pipelines would work fine.

On OMAP4 SDP board, for example, this would mean that if the user
doesn't compile PicoDLP driver, or the driver fails to probe, the two
LCDs and the analog TV out would also fail. Many of the boards don't
even have a PicoDLP module installed, so a fail there somewhere is
guaranteed.

> This is why we now have the component helpers in the driver model -
> to allow devices to be collected together into one logical subsystem
> group, and bound/unbound as a group.

Yep, it's a good start. The component helpers could well be used with CDF.

But if I'm not mistaken, it suffers from the problems above, when there
are multiple independent pipelines (simultaneous or non-simultaneous)
handled by the same IPs.

And, while I may be mistaken, it sounds that the component helpers leave
mostly everything up to the display drivers. Everyone devising their own
way to describe the hardware in DT, and the connections between the
components. Of course, the core component system shouldn't define
anything DT related, as it doesn't. But that part is still needed, which
is where CDF comes in.

In my opinion, the component helpers or similar would be used with CDF
in the beginning, because DRM doesn't support hotplug. Eventually we
should get some kind of basic hotplug support, so that we could add
display pipelines when they are ready.

I need to ask Dave why he is so strongly opposed to hotplugging components.

> Remember that "hotplugging" in this context does not mean that the
> user can physically do something with the hardware.  It means that
> they're separate devices which can be probed/removed at will.  Every
> device in Linux can be bound and unbound from its driver at any time
> by userspace, and that is something which is expected to be handled
> gracefully.

Hmm, sorry, can you rephrase?

My use of hotplug in this context means roughly "add a new display, and
whatever is related to that, when the drivers required have been probed".

So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
etc, could appear even after the initial probe of the display controller.

But all this is, I think, a bit aside the original point. The original
point was about DT bindings. What kind of framework we have in the
kernel side to handle the bindings is an interesting and very important
topic, but they are not strictly tied together.

Even if CDF is the worst thing ever, and needs to die quickly, I think
the proposed DT bindings are still valid. They describe the hardware as
precisely and as future-proofly as we've been able to come up with.
People can use component helpers with them if they see that's a good
approach. Or if on some beautiful day we get an agreement on CDF or
something similar, and we can support hotplugging components, we already
have proper DT bindings for it.

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140226/2df1d694/attachment.sig>

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote:
> > Also - DRM is not going to ever support hotplugging components - this
> > was discussed at kernel summit last year and David Airlie was quite
> 
> Ok. Very odd stance. Maybe there's a reason for it that I just don't see.

DRM is like ALSA - it's a card level subsystem.  All components have
to be present before the card level is brought up for the subsystem to
function correctly.

> > adamant about that.  So, any "framework" which forces hotplugging of
> > components on subsystems isn't going to fly.
> 
> CDF doesn't force hotplugging.
> 
> Although without hotplugging (hot-unplug not needed), or at least some
> minimal form of it, the system is a bit crippled. Leave one kernel
> module out, or have one driver probe fail, the whole display subsystem
> fails, even if some display pipelines would work fine.

That is, unfortunately, one of the side effects of the policy - but that's
not a policy that's going to change any time soon.  As I said, that was
made very clear at the last kernel summit - we had a /specific/ session
on the issues around multi-device DRM chaired by David.

There are some DRM drivers which have tried to do this, but they're all
buggy in some regard, whether that be to the point of oopsing the kernel
if things don't quite go to plan, or whether it's races between different
parts.

> > This is why we now have the component helpers in the driver model -
> > to allow devices to be collected together into one logical subsystem
> > group, and bound/unbound as a group.
> 
> Yep, it's a good start. The component helpers could well be used with CDF.
> 
> But if I'm not mistaken, it suffers from the problems above, when there
> are multiple independent pipelines (simultaneous or non-simultaneous)
> handled by the same IPs.

It may "suffer from the problems above" that you've raised, but that's
by explicit design of it - because that's what subsystems like DRM and
ALSA require, and this is _precisely_ the problem it's solving.

It's solving the "subsystem requires a stable view of hardware components,
but we have multiple devices and drivers which need probing" problem.

> And, while I may be mistaken, it sounds that the component helpers leave
> mostly everything up to the display drivers. Everyone devising their own
> way to describe the hardware in DT, and the connections between the
> components. Of course, the core component system shouldn't define
> anything DT related, as it doesn't. But that part is still needed, which
> is where CDF comes in.

Sigh.  It's very easy for people to get the wrong end of the stick.

What the component helpers do is provide a _subsystem_ _independent_
method of collecting a set of devices together and binding them to the
drivers at an appropriate time, in a way that is _completely_ independent
of whether you're using platform data, DT, ACPI, or whatever other
hardware description language comes along.

It's up to the users of this to define how components are grouped
together, whether that be at the subsystem level or at the driver
level - whatever is appropriate.

If a subsystem (eg, a display subsystem) wants to define "this is how
you define in DT the bindings between all components" and provide its
own hook for the "add_components" callback which does this, then it's
at liberty to do that.

If we can come up with a generic way to describe how all the components
in a display subsystem should be connected together, then great - but
that needs to happen very quickly.  Philipp Zabel is working on replacing
the imx-drm binding method right now for 3.15, and is probably completely
unaware of anything that's been talked about here.  I need to sort out
Armada DRM at some point to use the component stuff, which includes
sorting out TDA998x for DT - which again needs to be done in such a way
that it follows a common theme.

> I need to ask Dave why he is so strongly opposed to hotplugging components.

I suspect one reason for it is because it means rewriting the XF86
backend to Xorg to cope with it...

> > Remember that "hotplugging" in this context does not mean that the
> > user can physically do something with the hardware.  It means that
> > they're separate devices which can be probed/removed at will.  Every
> > device in Linux can be bound and unbound from its driver at any time
> > by userspace, and that is something which is expected to be handled
> > gracefully.
> 
> Hmm, sorry, can you rephrase?

I'll do better than that.  Try running this script with the
/sys/bus/.../drivers/whatever for the drivers you wish to test:

#!/bin/sh
for driver in "$@"; do
   if [ -f "${driver}/unbind" ]; then
      for device in "${driver}"/*; do
         if [ -d "${device}" ]; then
            devname="$(basename "${device}")"
            echo "$devname" > "${driver}/unbind"
            echo "$devname" > "${driver}/bind"
         fi
      done
   fi
done

The system should survive that.

> So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
> etc, could appear even after the initial probe of the display controller.

This is the exact situation that David is opposed to.  DRM, like ALSA,
whats to have a stable view of hardware - once the drm_device has been
created and probed, no further changes to it are allowed.

Certainly no changes to the CRTCs will _ever_ be permitted, because it
completely destroys the user API for referecing which encoders can be
associated with which CRTCs - not only at the kernel level, but also the
Xorg and Xrandr level too.  That's done via a bitmask of allowable CRTCs,
where bit 0 refers to the first CRTC, bit 1 to the second and so on.
That's propagated all the way through to userspace, right through the Xorg
interfaces to applications.

Connectors and encoders are fixed at the moment after initial probe time
in DRM due to the way the fbdev emulation layer works.  There's also issues
there concerning bitmasks for which connectors can be cloned onto other
connectors which follows the same pattern as above - and again, that
propagates all the way through userspace.

So, if this is going to get fixed, there has to be a desire to break
userspace quite badly, and there is no such desire to do that.

For instance, let's say that Xorg is up and running, and you have the
gnome applet for configuring your display open, and you have two CRTCs.
Then the first CRTC is removed from the system, resulting in CRTC 1
becoming CRTC 0 in the kernel.  What happens...

Think the same thing through for a system with three connectors, A, B, C
numbered 0, 1, and 2 respectively.  A and be cloned onto B.  Now connector
A is removed, meaning B and C appear to become numbers 0 and 1 in the
kernel...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Russell King - ARM Linux]

On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote:
> > Also - DRM is not going to ever support hotplugging components - this
> > was discussed at kernel summit last year and David Airlie was quite
> 
> Ok. Very odd stance. Maybe there's a reason for it that I just don't see.

DRM is like ALSA - it's a card level subsystem.  All components have
to be present before the card level is brought up for the subsystem to
function correctly.

> > adamant about that.  So, any "framework" which forces hotplugging of
> > components on subsystems isn't going to fly.
> 
> CDF doesn't force hotplugging.
> 
> Although without hotplugging (hot-unplug not needed), or at least some
> minimal form of it, the system is a bit crippled. Leave one kernel
> module out, or have one driver probe fail, the whole display subsystem
> fails, even if some display pipelines would work fine.

That is, unfortunately, one of the side effects of the policy - but that's
not a policy that's going to change any time soon.  As I said, that was
made very clear at the last kernel summit - we had a /specific/ session
on the issues around multi-device DRM chaired by David.

There are some DRM drivers which have tried to do this, but they're all
buggy in some regard, whether that be to the point of oopsing the kernel
if things don't quite go to plan, or whether it's races between different
parts.

> > This is why we now have the component helpers in the driver model -
> > to allow devices to be collected together into one logical subsystem
> > group, and bound/unbound as a group.
> 
> Yep, it's a good start. The component helpers could well be used with CDF.
> 
> But if I'm not mistaken, it suffers from the problems above, when there
> are multiple independent pipelines (simultaneous or non-simultaneous)
> handled by the same IPs.

It may "suffer from the problems above" that you've raised, but that's
by explicit design of it - because that's what subsystems like DRM and
ALSA require, and this is _precisely_ the problem it's solving.

It's solving the "subsystem requires a stable view of hardware components,
but we have multiple devices and drivers which need probing" problem.

> And, while I may be mistaken, it sounds that the component helpers leave
> mostly everything up to the display drivers. Everyone devising their own
> way to describe the hardware in DT, and the connections between the
> components. Of course, the core component system shouldn't define
> anything DT related, as it doesn't. But that part is still needed, which
> is where CDF comes in.

Sigh.  It's very easy for people to get the wrong end of the stick.

What the component helpers do is provide a _subsystem_ _independent_
method of collecting a set of devices together and binding them to the
drivers at an appropriate time, in a way that is _completely_ independent
of whether you're using platform data, DT, ACPI, or whatever other
hardware description language comes along.

It's up to the users of this to define how components are grouped
together, whether that be at the subsystem level or at the driver
level - whatever is appropriate.

If a subsystem (eg, a display subsystem) wants to define "this is how
you define in DT the bindings between all components" and provide its
own hook for the "add_components" callback which does this, then it's
at liberty to do that.

If we can come up with a generic way to describe how all the components
in a display subsystem should be connected together, then great - but
that needs to happen very quickly.  Philipp Zabel is working on replacing
the imx-drm binding method right now for 3.15, and is probably completely
unaware of anything that's been talked about here.  I need to sort out
Armada DRM at some point to use the component stuff, which includes
sorting out TDA998x for DT - which again needs to be done in such a way
that it follows a common theme.

> I need to ask Dave why he is so strongly opposed to hotplugging components.

I suspect one reason for it is because it means rewriting the XF86
backend to Xorg to cope with it...

> > Remember that "hotplugging" in this context does not mean that the
> > user can physically do something with the hardware.  It means that
> > they're separate devices which can be probed/removed at will.  Every
> > device in Linux can be bound and unbound from its driver at any time
> > by userspace, and that is something which is expected to be handled
> > gracefully.
> 
> Hmm, sorry, can you rephrase?

I'll do better than that.  Try running this script with the
/sys/bus/.../drivers/whatever for the drivers you wish to test:

#!/bin/sh
for driver in "$@"; do
   if [ -f "${driver}/unbind" ]; then
      for device in "${driver}"/*; do
         if [ -d "${device}" ]; then
            devname="$(basename "${device}")"
            echo "$devname" > "${driver}/unbind"
            echo "$devname" > "${driver}/bind"
         fi
      done
   fi
done

The system should survive that.

> So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
> etc, could appear even after the initial probe of the display controller.

This is the exact situation that David is opposed to.  DRM, like ALSA,
whats to have a stable view of hardware - once the drm_device has been
created and probed, no further changes to it are allowed.

Certainly no changes to the CRTCs will _ever_ be permitted, because it
completely destroys the user API for referecing which encoders can be
associated with which CRTCs - not only at the kernel level, but also the
Xorg and Xrandr level too.  That's done via a bitmask of allowable CRTCs,
where bit 0 refers to the first CRTC, bit 1 to the second and so on.
That's propagated all the way through to userspace, right through the Xorg
interfaces to applications.

Connectors and encoders are fixed at the moment after initial probe time
in DRM due to the way the fbdev emulation layer works.  There's also issues
there concerning bitmasks for which connectors can be cloned onto other
connectors which follows the same pattern as above - and again, that
propagates all the way through userspace.

So, if this is going to get fixed, there has to be a desire to break
userspace quite badly, and there is no such desire to do that.

For instance, let's say that Xorg is up and running, and you have the
gnome applet for configuring your display open, and you have two CRTCs.
Then the first CRTC is removed from the system, resulting in CRTC 1
becoming CRTC 0 in the kernel.  What happens...

Think the same thing through for a system with three connectors, A, B, C
numbered 0, 1, and 2 respectively.  A and be cloned onto B.  Now connector
A is removed, meaning B and C appear to become numbers 0 and 1 in the
kernel...

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Tomi Valkeinen]

[-- Attachment #1.1: Type: text/plain, Size: 7137 bytes --]

On 26/02/14 15:28, Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote:
>>> Also - DRM is not going to ever support hotplugging components - this
>>> was discussed at kernel summit last year and David Airlie was quite
>>
>> Ok. Very odd stance. Maybe there's a reason for it that I just don't see.
> 
> DRM is like ALSA - it's a card level subsystem.  All components have
> to be present before the card level is brought up for the subsystem to
> function correctly.

Well, yes, at the moment. I don't know what his message was, but if it
was "DRM won't get hotplug, even if someone would do it properly", that
sounds just silly.

>> But if I'm not mistaken, it suffers from the problems above, when there
>> are multiple independent pipelines (simultaneous or non-simultaneous)
>> handled by the same IPs.
> 
> It may "suffer from the problems above" that you've raised, but that's
> by explicit design of it - because that's what subsystems like DRM and
> ALSA require, and this is _precisely_ the problem it's solving.
> 
> It's solving the "subsystem requires a stable view of hardware components,
> but we have multiple devices and drivers which need probing" problem.

And that's good. What I'd like to avoid is developers using the
component helpers, and designing the DT just for that use case,
preventing the use of a possible future framework.

The example in your component helper commit:

        imx-drm {
                compatible = "fsl,drm";
                crtcs = <&ipu1>;
                connectors = <&hdmi>;
        };

How would that be extended if one imx board has an external HDMI
encoder? Or maybe the board has an external HDMI encoder, and also a
separate level-shifter/ESD chip like some OMAP boards have. Or maybe a
board has two displays connected to one imx LCD output, and a GPIO is
used to switch between the used display.

Rephrasing: How would those DT bindings be extended to allow arbitrarily
long or complex display pipelines?

The proposed OMAP DSS and CDF DT bindings try to allow all the above cases.

So in my opinion, using component helpers is good, but it'd be important
to make sure the DT bindings for all platforms are future proof, and
also compatible so that we can share encoder/panel drivers.

>> And, while I may be mistaken, it sounds that the component helpers leave
>> mostly everything up to the display drivers. Everyone devising their own
>> way to describe the hardware in DT, and the connections between the
>> components. Of course, the core component system shouldn't define
>> anything DT related, as it doesn't. But that part is still needed, which
>> is where CDF comes in.
> 
> Sigh.  It's very easy for people to get the wrong end of the stick.
> 
> What the component helpers do is provide a _subsystem_ _independent_
> method of collecting a set of devices together and binding them to the
> drivers at an appropriate time, in a way that is _completely_ independent
> of whether you're using platform data, DT, ACPI, or whatever other
> hardware description language comes along.

Yep, that's what I meant with "Of course, the core component system
shouldn't define anything DT related, as it doesn't.". Maybe that's not
even English, so my bad =).

> It's up to the users of this to define how components are grouped
> together, whether that be at the subsystem level or at the driver
> level - whatever is appropriate.
> 
> If a subsystem (eg, a display subsystem) wants to define "this is how
> you define in DT the bindings between all components" and provide its
> own hook for the "add_components" callback which does this, then it's
> at liberty to do that.
> 
> If we can come up with a generic way to describe how all the components
> in a display subsystem should be connected together, then great - but
> that needs to happen very quickly.  Philipp Zabel is working on replacing
> the imx-drm binding method right now for 3.15, and is probably completely
> unaware of anything that's been talked about here.  I need to sort out

Yes, I just pinged him a few hours ago about this. I've been ill for a
few weeks, so I'm catching up on emails, but I want to sync with him
asap to see if the OMAP DSS side and his imx series have things in common.

> Armada DRM at some point to use the component stuff, which includes
> sorting out TDA998x for DT - which again needs to be done in such a way
> that it follows a common theme.

BeagleBoneBlack has TDA998x, so I'm also very interested in that.

>> So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
>> etc, could appear even after the initial probe of the display controller.
> 
> This is the exact situation that David is opposed to.  DRM, like ALSA,
> whats to have a stable view of hardware - once the drm_device has been
> created and probed, no further changes to it are allowed.
> 
> Certainly no changes to the CRTCs will _ever_ be permitted, because it
> completely destroys the user API for referecing which encoders can be
> associated with which CRTCs - not only at the kernel level, but also the
> Xorg and Xrandr level too.  That's done via a bitmask of allowable CRTCs,
> where bit 0 refers to the first CRTC, bit 1 to the second and so on.
> That's propagated all the way through to userspace, right through the Xorg
> interfaces to applications.
> 
> Connectors and encoders are fixed at the moment after initial probe time
> in DRM due to the way the fbdev emulation layer works.  There's also issues
> there concerning bitmasks for which connectors can be cloned onto other
> connectors which follows the same pattern as above - and again, that
> propagates all the way through userspace.
> 
> So, if this is going to get fixed, there has to be a desire to break
> userspace quite badly, and there is no such desire to do that.
> 
> For instance, let's say that Xorg is up and running, and you have the
> gnome applet for configuring your display open, and you have two CRTCs.
> Then the first CRTC is removed from the system, resulting in CRTC 1
> becoming CRTC 0 in the kernel.  What happens...
> 
> Think the same thing through for a system with three connectors, A, B, C
> numbered 0, 1, and 2 respectively.  A and be cloned onto B.  Now connector
> A is removed, meaning B and C appear to become numbers 0 and 1 in the
> kernel...

I specifically said "hot-unplug not needed". Fbs, crtcs, etc. could only
appear, never to be removed individually. I don't see much benefit in
supporting hot-unplug, but I see much benefit with hot-plug. And I'm
sure there could be problems with only hot-plug, but I'd bet they are
much simpler if we never remove the components individually.

Usually, all the hot-plugging would happen before the rootfs is mounted.
However, it'd still be possible to load a display driver as a module
later, as long as any user (say, X) would be loaded after that.

Do you see that model as overly problematic, possibly breaking the
userspace API?

 Tomi



[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

[-- Attachment #2: Type: text/plain, Size: 176 bytes --]

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Tomi Valkeinen]

On 26/02/14 15:28, Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote:
>>> Also - DRM is not going to ever support hotplugging components - this
>>> was discussed at kernel summit last year and David Airlie was quite
>>
>> Ok. Very odd stance. Maybe there's a reason for it that I just don't see.
> 
> DRM is like ALSA - it's a card level subsystem.  All components have
> to be present before the card level is brought up for the subsystem to
> function correctly.

Well, yes, at the moment. I don't know what his message was, but if it
was "DRM won't get hotplug, even if someone would do it properly", that
sounds just silly.

>> But if I'm not mistaken, it suffers from the problems above, when there
>> are multiple independent pipelines (simultaneous or non-simultaneous)
>> handled by the same IPs.
> 
> It may "suffer from the problems above" that you've raised, but that's
> by explicit design of it - because that's what subsystems like DRM and
> ALSA require, and this is _precisely_ the problem it's solving.
> 
> It's solving the "subsystem requires a stable view of hardware components,
> but we have multiple devices and drivers which need probing" problem.

And that's good. What I'd like to avoid is developers using the
component helpers, and designing the DT just for that use case,
preventing the use of a possible future framework.

The example in your component helper commit:

        imx-drm {
                compatible = "fsl,drm";
                crtcs = <&ipu1>;
                connectors = <&hdmi>;
        };

How would that be extended if one imx board has an external HDMI
encoder? Or maybe the board has an external HDMI encoder, and also a
separate level-shifter/ESD chip like some OMAP boards have. Or maybe a
board has two displays connected to one imx LCD output, and a GPIO is
used to switch between the used display.

Rephrasing: How would those DT bindings be extended to allow arbitrarily
long or complex display pipelines?

The proposed OMAP DSS and CDF DT bindings try to allow all the above cases.

So in my opinion, using component helpers is good, but it'd be important
to make sure the DT bindings for all platforms are future proof, and
also compatible so that we can share encoder/panel drivers.

>> And, while I may be mistaken, it sounds that the component helpers leave
>> mostly everything up to the display drivers. Everyone devising their own
>> way to describe the hardware in DT, and the connections between the
>> components. Of course, the core component system shouldn't define
>> anything DT related, as it doesn't. But that part is still needed, which
>> is where CDF comes in.
> 
> Sigh.  It's very easy for people to get the wrong end of the stick.
> 
> What the component helpers do is provide a _subsystem_ _independent_
> method of collecting a set of devices together and binding them to the
> drivers at an appropriate time, in a way that is _completely_ independent
> of whether you're using platform data, DT, ACPI, or whatever other
> hardware description language comes along.

Yep, that's what I meant with "Of course, the core component system
shouldn't define anything DT related, as it doesn't.". Maybe that's not
even English, so my bad =).

> It's up to the users of this to define how components are grouped
> together, whether that be at the subsystem level or at the driver
> level - whatever is appropriate.
> 
> If a subsystem (eg, a display subsystem) wants to define "this is how
> you define in DT the bindings between all components" and provide its
> own hook for the "add_components" callback which does this, then it's
> at liberty to do that.
> 
> If we can come up with a generic way to describe how all the components
> in a display subsystem should be connected together, then great - but
> that needs to happen very quickly.  Philipp Zabel is working on replacing
> the imx-drm binding method right now for 3.15, and is probably completely
> unaware of anything that's been talked about here.  I need to sort out

Yes, I just pinged him a few hours ago about this. I've been ill for a
few weeks, so I'm catching up on emails, but I want to sync with him
asap to see if the OMAP DSS side and his imx series have things in common.

> Armada DRM at some point to use the component stuff, which includes
> sorting out TDA998x for DT - which again needs to be done in such a way
> that it follows a common theme.

BeagleBoneBlack has TDA998x, so I'm also very interested in that.

>> So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
>> etc, could appear even after the initial probe of the display controller.
> 
> This is the exact situation that David is opposed to.  DRM, like ALSA,
> whats to have a stable view of hardware - once the drm_device has been
> created and probed, no further changes to it are allowed.
> 
> Certainly no changes to the CRTCs will _ever_ be permitted, because it
> completely destroys the user API for referecing which encoders can be
> associated with which CRTCs - not only at the kernel level, but also the
> Xorg and Xrandr level too.  That's done via a bitmask of allowable CRTCs,
> where bit 0 refers to the first CRTC, bit 1 to the second and so on.
> That's propagated all the way through to userspace, right through the Xorg
> interfaces to applications.
> 
> Connectors and encoders are fixed at the moment after initial probe time
> in DRM due to the way the fbdev emulation layer works.  There's also issues
> there concerning bitmasks for which connectors can be cloned onto other
> connectors which follows the same pattern as above - and again, that
> propagates all the way through userspace.
> 
> So, if this is going to get fixed, there has to be a desire to break
> userspace quite badly, and there is no such desire to do that.
> 
> For instance, let's say that Xorg is up and running, and you have the
> gnome applet for configuring your display open, and you have two CRTCs.
> Then the first CRTC is removed from the system, resulting in CRTC 1
> becoming CRTC 0 in the kernel.  What happens...
> 
> Think the same thing through for a system with three connectors, A, B, C
> numbered 0, 1, and 2 respectively.  A and be cloned onto B.  Now connector
> A is removed, meaning B and C appear to become numbers 0 and 1 in the
> kernel...

I specifically said "hot-unplug not needed". Fbs, crtcs, etc. could only
appear, never to be removed individually. I don't see much benefit in
supporting hot-unplug, but I see much benefit with hot-plug. And I'm
sure there could be problems with only hot-plug, but I'd bet they are
much simpler if we never remove the components individually.

Usually, all the hot-plugging would happen before the rootfs is mounted.
However, it'd still be possible to load a display driver as a module
later, as long as any user (say, X) would be loaded after that.

Do you see that model as overly problematic, possibly breaking the
userspace API?

 Tomi


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140226/f06a18a2/attachment-0001.sig>

Re: [PATCH 1/2] ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor

[Florian Vaussard]

Hi Tony, Benoit,

On 02/24/2014 06:07 PM, Florian Vaussard wrote:
> Gumstix DuoVero is an OMAP4430-based Computer On Module.
> Parlor is one of the available expansion board.
> 
> Tested features:
> - GPMC ethernet
> - HSUSB2 and OTG
> - Audio out
> - WiFi and Bluetooth (w2cbw0015 SDIO module)
> - LED and button
> 

Can this patch go into 3.15? The other one (HDMI support) can wait for
the DSS support to be merged, but I would like to give to this DTS a
wider exposure to testing opportunities.

Regards,
Florian

> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
>  .../devicetree/bindings/arm/omap/omap.txt          |   3 +
>  arch/arm/boot/dts/Makefile                         |   1 +
>  arch/arm/boot/dts/omap4-duovero-parlor.dts         | 146 ++++++++++++
>  arch/arm/boot/dts/omap4-duovero.dtsi               | 252 +++++++++++++++++++++
>  4 files changed, 402 insertions(+)
>  create mode 100644 arch/arm/boot/dts/omap4-duovero-parlor.dts
>  create mode 100644 arch/arm/boot/dts/omap4-duovero.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index af9b4a0..95b1372 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -99,6 +99,9 @@ Boards:
>  - OMAP4 PandaBoard : Low cost community board
>    compatible = "ti,omap4-panda", "ti,omap4430"
>  
> +- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
> +  compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
> +
>  - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
>    compatible = "ti,omap3-evm", "ti,omap3"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 0320303..8b23abb 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -215,6 +215,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>  	omap3-igep0020.dtb \
>  	omap3-igep0030.dtb \
>  	omap3-zoom3.dtb \
> +	omap4-duovero-parlor.dtb \
>  	omap4-panda.dtb \
>  	omap4-panda-a4.dtb \
>  	omap4-panda-es.dtb \
> diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts b/arch/arm/boot/dts/omap4-duovero-parlor.dts
> new file mode 100644
> index 0000000..96f51d8
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +#include "omap4-duovero.dtsi"
> +
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +	model = "OMAP4430 Gumstix Duovero on Parlor";
> +	compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		led0 {
> +			label = "duovero:blue:led0";
> +			gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;	/* gpio_122 */
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};
> +
> +	gpio_keys {
> +		compatible = "gpio-keys";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		button0@121 {
> +			label = "button0";
> +			linux,code = <BTN_0>;
> +			gpios = <&gpio4 25 GPIO_ACTIVE_LOW>;	/* gpio_121 */
> +			gpio-key,wakeup;
> +		};
> +	};
> +};
> +
> +&omap4_pmx_core {
> +	pinctrl-0 = <
> +			&led_pins
> +			&button_pins
> +			&smsc_pins
> +	>;
> +
> +	led_pins: pinmux_led_pins {
> +		pinctrl-single,pins = <
> +			0xd6 (PIN_OUTPUT | MUX_MODE3)		/* abe_dmic_din3.gpio_122 */
> +		>;
> +	};
> +
> +	button_pins: pinmux_button_pins {
> +		pinctrl-single,pins = <
> +			0xd4 (PIN_INPUT_PULLUP | MUX_MODE3)	/* abe_dmic_din2.gpio_121 */
> +		>;
> +	};
> +
> +	i2c2_pins: pinmux_i2c2_pins {
> +		pinctrl-single,pins = <
> +			0xe6 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_scl */
> +			0xe8 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_sda */
> +		>;
> +	};
> +
> +	i2c3_pins: pinmux_i2c3_pins {
> +		pinctrl-single,pins = <
> +			0xea (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_scl */
> +			0xec (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_sda */
> +		>;
> +	};
> +
> +	smsc_pins: pinmux_smsc_pins {
> +		pinctrl-single,pins = <
> +			0x28 (PIN_INPUT | MUX_MODE3)		/* gpmc_a20.gpio_44: IRQ */
> +			0x2a (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a21.gpio_45: nReset */
> +			0x30 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a24.gpio_48: amdix enabled */
> +		>;
> +	};
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c2_pins>;
> +
> +	clock-frequency = <400000>;
> +};
> +
> +&i2c3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c3_pins>;
> +
> +	clock-frequency = <100000>;
> +
> +	/* optional 1K EEPROM with revision information */
> +	eeprom@51 {
> +		compatible = "atmel,24c01";
> +		reg = <0x51>;
> +		pagesize = <8>;
> +	};
> +};
> +
> +&mmc3 {
> +	status = "disabled";
> +};
> +
> +#include "omap-gpmc-smsc911x.dtsi"
> +
> +&gpmc {
> +	ranges = <5 0 0x2c000000 0x1000000>;			/* CS5 */
> +
> +	ethernet@gpmc {
> +		reg = <5 0 0xff>;
> +		interrupt-parent = <&gpio2>;
> +		interrupts = <12 IRQ_TYPE_LEVEL_LOW>;		/* gpio_44 */
> +
> +		phy-mode = "mii";
> +
> +		gpmc,cs-on-ns = <10>;
> +		gpmc,cs-rd-off-ns = <50>;
> +		gpmc,cs-wr-off-ns = <50>;
> +		gpmc,adv-on-ns = <0>;
> +		gpmc,adv-rd-off-ns = <10>;
> +		gpmc,adv-wr-off-ns = <10>;
> +		gpmc,oe-on-ns = <15>;
> +		gpmc,oe-off-ns = <50>;
> +		gpmc,we-on-ns = <15>;
> +		gpmc,we-off-ns = <50>;
> +		gpmc,rd-cycle-ns = <50>;
> +		gpmc,wr-cycle-ns = <50>;
> +		gpmc,access-ns = <50>;
> +		gpmc,page-burst-access-ns = <0>;
> +		gpmc,bus-turnaround-ns = <35>;
> +		gpmc,cycle2cycle-delay-ns = <35>;
> +		gpmc,wr-data-mux-bus-ns = <35>;
> +		gpmc,wr-access-ns = <50>;
> +
> +		gpmc,mux-add-data = <2>;
> +		gpmc,sync-read;
> +		gpmc,sync-write;
> +		gpmc,clk-activation-ns = <5>;
> +		gpmc,sync-clk-ps = <20000>;
> +	};
> +};
> +
> +
> diff --git a/arch/arm/boot/dts/omap4-duovero.dtsi b/arch/arm/boot/dts/omap4-duovero.dtsi
> new file mode 100644
> index 0000000..a514791
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4-duovero.dtsi
> @@ -0,0 +1,252 @@
> +/*
> + * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "omap443x.dtsi"
> +
> +/ {
> +	model = "Gumstix Duovero";
> +	compatible = "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x80000000 0x40000000>; /* 1 GB */
> +	};
> +
> +	sound {
> +		compatible = "ti,abe-twl6040";
> +		ti,model = "DuoVero";
> +
> +		ti,mclk-freq = <38400000>;
> +
> +		ti,mcpdm = <&mcpdm>;
> +
> +		ti,twl6040 = <&twl6040>;
> +
> +		/* Audio routing */
> +		ti,audio-routing =
> +			"Headset Stereophone", "HSOL",
> +			"Headset Stereophone", "HSOR",
> +			"HSMIC", "Headset Mic",
> +			"Headset Mic", "Headset Mic Bias";
> +	};
> +
> +	/* HS USB Host PHY on PORT 1 */
> +	hsusb1_phy: hsusb1_phy {
> +		compatible = "usb-nop-xceiv";
> +		reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>;	/* gpio_62 */
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&hsusb1phy_pins>;
> +
> +		clocks = <&auxclk3_ck>;
> +		clock-names = "main_clk";
> +		clock-frequency = <19200000>;
> +	};
> +
> +	/* regulator for w2cbw0015 on sdio5 */
> +	w2cbw0015_vmmc: w2cbw0015_vmmc {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&w2cbw0015_pins>;
> +		compatible = "regulator-fixed";
> +		regulator-name = "w2cbw0015";
> +		regulator-min-microvolt = <3000000>;
> +		regulator-max-microvolt = <3000000>;
> +		gpio = <&gpio2 11 GPIO_ACTIVE_LOW>;		/* gpio_43 */
> +		startup-delay-us = <70000>;
> +		enable-active-high;
> +		regulator-boot-on;
> +	};
> +};
> +
> +&omap4_pmx_core {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <
> +			&twl6040_pins
> +			&mcpdm_pins
> +			&mcbsp1_pins
> +			&hsusbb1_pins
> +	>;
> +
> +	twl6040_pins: pinmux_twl6040_pins {
> +		pinctrl-single,pins = <
> +			0x126 (PIN_OUTPUT | MUX_MODE3)		/* usbb2_ulpitll_nxt.gpio_160 */
> +			0x160 (PIN_INPUT | MUX_MODE0)		/* sys_nirq2.sys_nirq2 */
> +		>;
> +	};
> +
> +	mcpdm_pins: pinmux_mcpdm_pins {
> +		pinctrl-single,pins = <
> +			0xc6 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_ul_data.abe_pdm_ul_data */
> +			0xc8 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_dl_data.abe_pdm_dl_data */
> +			0xca (PIN_INPUT_PULLUP   | MUX_MODE0)	/* abe_pdm_frame.abe_pdm_frame */
> +			0xcc (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_lb_clk.abe_pdm_lb_clk */
> +			0xce (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_clks.abe_clks */
> +		>;
> +	};
> +
> +	mcbsp1_pins: pinmux_mcbsp1_pins {
> +		pinctrl-single,pins = <
> +			0xbe (PIN_INPUT | MUX_MODE0)		/* abe_mcbsp1_clkx.abe_mcbsp1_clkx */
> +			0xc0 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_mcbsp1_dr.abe_mcbsp1_dr */
> +			0xc2 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)	/* abe_mcbsp1_dx.abe_mcbsp1_dx */
> +			0xc4 (PIN_INPUT | MUX_MODE0)		/* abe_mcbsp1_fsx.abe_mcbsp1_fsx */
> +		>;
> +	};
> +
> +	hsusbb1_pins: pinmux_hsusbb1_pins {
> +		pinctrl-single,pins = <
> +			0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_clk.usbb1_ulpiphy_clk */
> +			0x84 (PIN_OUTPUT | MUX_MODE4)		/* usbb1_ulpitll_stp.usbb1_ulpiphy_stp */
> +			0x86 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dir.usbb1_ulpiphy_dir */
> +			0x88 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt */
> +			0x8a (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 */
> +			0x8c (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 */
> +			0x8e (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 */
> +			0x90 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 */
> +			0x92 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 */
> +			0x94 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 */
> +			0x96 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 */
> +			0x98 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 */
> +		>;
> +	};
> +
> +	hsusb1phy_pins: pinmux_hsusb1phy_pins {
> +		pinctrl-single,pins = <
> +			0x4c (PIN_OUTPUT | MUX_MODE3)		/* gpmc_wait1.gpio_62 */
> +		>;
> +	};
> +
> +	w2cbw0015_pins: pinmux_w2cbw0015_pins {
> +		pinctrl-single,pins = <
> +			0x26 (PIN_OUTPUT | MUX_MODE3)		/* gpmc_a19.gpio_43 */
> +			0x3a (PIN_INPUT | MUX_MODE3)		/* gpmc_ncs3.gpio_53 */
> +		>;
> +	};
> +
> +	i2c1_pins: pinmux_i2c1_pins {
> +		pinctrl-single,pins = <
> +			0xe2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_scl */
> +			0xe4 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_sda */
> +		>;
> +	};
> +
> +	i2c4_pins: pinmux_i2c4_pins {
> +		pinctrl-single,pins = <
> +			0xee (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_scl */
> +			0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_sda */
> +		>;
> +	};
> +
> +	mmc1_pins: pinmux_mmc1_pins {
> +		pinctrl-single,pins = <
> +			0xa2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk */
> +			0xa4 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc1_cmd */
> +			0xa6 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc1_dat0 */
> +			0xa8 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat1 */
> +			0xaa (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat2 */
> +			0xac (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat3 */
> +		>;
> +	};
> +
> +	mmc5_pins: pinmux_mmc5_pins {
> +		pinctrl-single,pins = <
> +			0x108 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_clk */
> +			0x10a (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc5_cmd */
> +			0x10c (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc5_dat0 */
> +			0x10e (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat1 */
> +			0x110 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat2 */
> +			0x112 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat3 */
> +		>;
> +	};
> +};
> +
> +/* PMIC */
> +&i2c1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c1_pins>;
> +
> +	clock-frequency = <400000>;
> +
> +	twl: twl@48 {
> +		reg = <0x48>;
> +		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;		/* IRQ_SYS_1N cascaded to gic */
> +		interrupt-parent = <&gic>;
> +	};
> +
> +	twl6040: twl@4b {
> +		compatible = "ti,twl6040";
> +		reg = <0x4b>;
> +		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;		/* IRQ_SYS_2N cascaded to gic */
> +		interrupt-parent = <&gic>;
> +		ti,audpwron-gpio = <&gpio6 0 GPIO_ACTIVE_HIGH>;		/* gpio_160 */
> +
> +		vio-supply = <&v1v8>;
> +		v2v1-supply = <&v2v1>;
> +		enable-active-high;
> +	};
> +};
> +
> +#include "twl6030.dtsi"
> +#include "twl6030_omap4.dtsi"
> +
> +/* on-board bluetooth / WiFi module */
> +&i2c4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c4_pins>;
> +
> +	clock-frequency = <400000>;
> +};
> +
> +&mmc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc1_pins>;
> +
> +	vmmc-supply = <&vmmc>;
> +	ti,bus-width = <4>;
> +	ti,non-removable;		/* FIXME: use PMIC_MMC detect */
> +};
> +
> +&mmc2 {
> +	status = "disabled";
> +};
> +
> +/* mmc3 is available to the expansion board */
> +
> +&mmc4 {
> +	status = "disabled";
> +};
> +
> +/* on-board WiFi module */
> +&mmc5 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc5_pins>;
> +
> +	vmmc-supply = <&w2cbw0015_vmmc>;
> +	ti,bus-width = <4>;
> +	ti,non-removable;
> +	cap-power-off-card;
> +};
> +
> +&twl_usb_comparator {
> +	usb-supply = <&vusb>;
> +};
> +
> +&usb_otg_hs {
> +	interface-type = <1>;
> +	mode = <3>;
> +	power = <50>;
> +};
> +
> +&usbhshost {
> +	port1-mode = "ehci-phy";
> +};
> +
> +&usbhsehci {
> +	phys = <&hsusb1_phy>;
> +};
> +
> 

[PATCH 1/2] ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor

[Florian Vaussard]

Hi Tony, Benoit,

On 02/24/2014 06:07 PM, Florian Vaussard wrote:
> Gumstix DuoVero is an OMAP4430-based Computer On Module.
> Parlor is one of the available expansion board.
> 
> Tested features:
> - GPMC ethernet
> - HSUSB2 and OTG
> - Audio out
> - WiFi and Bluetooth (w2cbw0015 SDIO module)
> - LED and button
> 

Can this patch go into 3.15? The other one (HDMI support) can wait for
the DSS support to be merged, but I would like to give to this DTS a
wider exposure to testing opportunities.

Regards,
Florian

> Signed-off-by: Florian Vaussard <florian.vaussard@epfl.ch>
> ---
>  .../devicetree/bindings/arm/omap/omap.txt          |   3 +
>  arch/arm/boot/dts/Makefile                         |   1 +
>  arch/arm/boot/dts/omap4-duovero-parlor.dts         | 146 ++++++++++++
>  arch/arm/boot/dts/omap4-duovero.dtsi               | 252 +++++++++++++++++++++
>  4 files changed, 402 insertions(+)
>  create mode 100644 arch/arm/boot/dts/omap4-duovero-parlor.dts
>  create mode 100644 arch/arm/boot/dts/omap4-duovero.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt
> index af9b4a0..95b1372 100644
> --- a/Documentation/devicetree/bindings/arm/omap/omap.txt
> +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt
> @@ -99,6 +99,9 @@ Boards:
>  - OMAP4 PandaBoard : Low cost community board
>    compatible = "ti,omap4-panda", "ti,omap4430"
>  
> +- OMAP4 DuoVero with Parlor : Commercial expansion board with daughter board
> +  compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
> +
>  - OMAP3 EVM : Software Development Board for OMAP35x, AM/DM37x
>    compatible = "ti,omap3-evm", "ti,omap3"
>  
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 0320303..8b23abb 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -215,6 +215,7 @@ dtb-$(CONFIG_ARCH_OMAP2PLUS) += omap2420-h4.dtb \
>  	omap3-igep0020.dtb \
>  	omap3-igep0030.dtb \
>  	omap3-zoom3.dtb \
> +	omap4-duovero-parlor.dtb \
>  	omap4-panda.dtb \
>  	omap4-panda-a4.dtb \
>  	omap4-panda-es.dtb \
> diff --git a/arch/arm/boot/dts/omap4-duovero-parlor.dts b/arch/arm/boot/dts/omap4-duovero-parlor.dts
> new file mode 100644
> index 0000000..96f51d8
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4-duovero-parlor.dts
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +/dts-v1/;
> +
> +#include "omap4-duovero.dtsi"
> +
> +#include <dt-bindings/input/input.h>
> +
> +/ {
> +	model = "OMAP4430 Gumstix Duovero on Parlor";
> +	compatible = "gumstix,omap4-duovero-parlor", "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
> +
> +	leds {
> +		compatible = "gpio-leds";
> +		led0 {
> +			label = "duovero:blue:led0";
> +			gpios = <&gpio4 26 GPIO_ACTIVE_HIGH>;	/* gpio_122 */
> +			linux,default-trigger = "heartbeat";
> +		};
> +	};
> +
> +	gpio_keys {
> +		compatible = "gpio-keys";
> +		#address-cells = <1>;
> +		#size-cells = <0>;
> +		button0 at 121 {
> +			label = "button0";
> +			linux,code = <BTN_0>;
> +			gpios = <&gpio4 25 GPIO_ACTIVE_LOW>;	/* gpio_121 */
> +			gpio-key,wakeup;
> +		};
> +	};
> +};
> +
> +&omap4_pmx_core {
> +	pinctrl-0 = <
> +			&led_pins
> +			&button_pins
> +			&smsc_pins
> +	>;
> +
> +	led_pins: pinmux_led_pins {
> +		pinctrl-single,pins = <
> +			0xd6 (PIN_OUTPUT | MUX_MODE3)		/* abe_dmic_din3.gpio_122 */
> +		>;
> +	};
> +
> +	button_pins: pinmux_button_pins {
> +		pinctrl-single,pins = <
> +			0xd4 (PIN_INPUT_PULLUP | MUX_MODE3)	/* abe_dmic_din2.gpio_121 */
> +		>;
> +	};
> +
> +	i2c2_pins: pinmux_i2c2_pins {
> +		pinctrl-single,pins = <
> +			0xe6 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_scl */
> +			0xe8 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c2_sda */
> +		>;
> +	};
> +
> +	i2c3_pins: pinmux_i2c3_pins {
> +		pinctrl-single,pins = <
> +			0xea (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_scl */
> +			0xec (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c3_sda */
> +		>;
> +	};
> +
> +	smsc_pins: pinmux_smsc_pins {
> +		pinctrl-single,pins = <
> +			0x28 (PIN_INPUT | MUX_MODE3)		/* gpmc_a20.gpio_44: IRQ */
> +			0x2a (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a21.gpio_45: nReset */
> +			0x30 (PIN_INPUT_PULLUP | MUX_MODE3)	/* gpmc_a24.gpio_48: amdix enabled */
> +		>;
> +	};
> +};
> +
> +&i2c2 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c2_pins>;
> +
> +	clock-frequency = <400000>;
> +};
> +
> +&i2c3 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c3_pins>;
> +
> +	clock-frequency = <100000>;
> +
> +	/* optional 1K EEPROM with revision information */
> +	eeprom at 51 {
> +		compatible = "atmel,24c01";
> +		reg = <0x51>;
> +		pagesize = <8>;
> +	};
> +};
> +
> +&mmc3 {
> +	status = "disabled";
> +};
> +
> +#include "omap-gpmc-smsc911x.dtsi"
> +
> +&gpmc {
> +	ranges = <5 0 0x2c000000 0x1000000>;			/* CS5 */
> +
> +	ethernet at gpmc {
> +		reg = <5 0 0xff>;
> +		interrupt-parent = <&gpio2>;
> +		interrupts = <12 IRQ_TYPE_LEVEL_LOW>;		/* gpio_44 */
> +
> +		phy-mode = "mii";
> +
> +		gpmc,cs-on-ns = <10>;
> +		gpmc,cs-rd-off-ns = <50>;
> +		gpmc,cs-wr-off-ns = <50>;
> +		gpmc,adv-on-ns = <0>;
> +		gpmc,adv-rd-off-ns = <10>;
> +		gpmc,adv-wr-off-ns = <10>;
> +		gpmc,oe-on-ns = <15>;
> +		gpmc,oe-off-ns = <50>;
> +		gpmc,we-on-ns = <15>;
> +		gpmc,we-off-ns = <50>;
> +		gpmc,rd-cycle-ns = <50>;
> +		gpmc,wr-cycle-ns = <50>;
> +		gpmc,access-ns = <50>;
> +		gpmc,page-burst-access-ns = <0>;
> +		gpmc,bus-turnaround-ns = <35>;
> +		gpmc,cycle2cycle-delay-ns = <35>;
> +		gpmc,wr-data-mux-bus-ns = <35>;
> +		gpmc,wr-access-ns = <50>;
> +
> +		gpmc,mux-add-data = <2>;
> +		gpmc,sync-read;
> +		gpmc,sync-write;
> +		gpmc,clk-activation-ns = <5>;
> +		gpmc,sync-clk-ps = <20000>;
> +	};
> +};
> +
> +
> diff --git a/arch/arm/boot/dts/omap4-duovero.dtsi b/arch/arm/boot/dts/omap4-duovero.dtsi
> new file mode 100644
> index 0000000..a514791
> --- /dev/null
> +++ b/arch/arm/boot/dts/omap4-duovero.dtsi
> @@ -0,0 +1,252 @@
> +/*
> + * Copyright (C) 2014 Florian Vaussard, EPFL Mobots group
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include "omap443x.dtsi"
> +
> +/ {
> +	model = "Gumstix Duovero";
> +	compatible = "gumstix,omap4-duovero", "ti,omap4430", "ti,omap4";
> +
> +	memory {
> +		device_type = "memory";
> +		reg = <0x80000000 0x40000000>; /* 1 GB */
> +	};
> +
> +	sound {
> +		compatible = "ti,abe-twl6040";
> +		ti,model = "DuoVero";
> +
> +		ti,mclk-freq = <38400000>;
> +
> +		ti,mcpdm = <&mcpdm>;
> +
> +		ti,twl6040 = <&twl6040>;
> +
> +		/* Audio routing */
> +		ti,audio-routing =
> +			"Headset Stereophone", "HSOL",
> +			"Headset Stereophone", "HSOR",
> +			"HSMIC", "Headset Mic",
> +			"Headset Mic", "Headset Mic Bias";
> +	};
> +
> +	/* HS USB Host PHY on PORT 1 */
> +	hsusb1_phy: hsusb1_phy {
> +		compatible = "usb-nop-xceiv";
> +		reset-gpios = <&gpio2 30 GPIO_ACTIVE_LOW>;	/* gpio_62 */
> +
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&hsusb1phy_pins>;
> +
> +		clocks = <&auxclk3_ck>;
> +		clock-names = "main_clk";
> +		clock-frequency = <19200000>;
> +	};
> +
> +	/* regulator for w2cbw0015 on sdio5 */
> +	w2cbw0015_vmmc: w2cbw0015_vmmc {
> +		pinctrl-names = "default";
> +		pinctrl-0 = <&w2cbw0015_pins>;
> +		compatible = "regulator-fixed";
> +		regulator-name = "w2cbw0015";
> +		regulator-min-microvolt = <3000000>;
> +		regulator-max-microvolt = <3000000>;
> +		gpio = <&gpio2 11 GPIO_ACTIVE_LOW>;		/* gpio_43 */
> +		startup-delay-us = <70000>;
> +		enable-active-high;
> +		regulator-boot-on;
> +	};
> +};
> +
> +&omap4_pmx_core {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <
> +			&twl6040_pins
> +			&mcpdm_pins
> +			&mcbsp1_pins
> +			&hsusbb1_pins
> +	>;
> +
> +	twl6040_pins: pinmux_twl6040_pins {
> +		pinctrl-single,pins = <
> +			0x126 (PIN_OUTPUT | MUX_MODE3)		/* usbb2_ulpitll_nxt.gpio_160 */
> +			0x160 (PIN_INPUT | MUX_MODE0)		/* sys_nirq2.sys_nirq2 */
> +		>;
> +	};
> +
> +	mcpdm_pins: pinmux_mcpdm_pins {
> +		pinctrl-single,pins = <
> +			0xc6 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_ul_data.abe_pdm_ul_data */
> +			0xc8 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_dl_data.abe_pdm_dl_data */
> +			0xca (PIN_INPUT_PULLUP   | MUX_MODE0)	/* abe_pdm_frame.abe_pdm_frame */
> +			0xcc (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_pdm_lb_clk.abe_pdm_lb_clk */
> +			0xce (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_clks.abe_clks */
> +		>;
> +	};
> +
> +	mcbsp1_pins: pinmux_mcbsp1_pins {
> +		pinctrl-single,pins = <
> +			0xbe (PIN_INPUT | MUX_MODE0)		/* abe_mcbsp1_clkx.abe_mcbsp1_clkx */
> +			0xc0 (PIN_INPUT_PULLDOWN | MUX_MODE0)	/* abe_mcbsp1_dr.abe_mcbsp1_dr */
> +			0xc2 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)	/* abe_mcbsp1_dx.abe_mcbsp1_dx */
> +			0xc4 (PIN_INPUT | MUX_MODE0)		/* abe_mcbsp1_fsx.abe_mcbsp1_fsx */
> +		>;
> +	};
> +
> +	hsusbb1_pins: pinmux_hsusbb1_pins {
> +		pinctrl-single,pins = <
> +			0x82 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_clk.usbb1_ulpiphy_clk */
> +			0x84 (PIN_OUTPUT | MUX_MODE4)		/* usbb1_ulpitll_stp.usbb1_ulpiphy_stp */
> +			0x86 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dir.usbb1_ulpiphy_dir */
> +			0x88 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_nxt.usbb1_ulpiphy_nxt */
> +			0x8a (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat0.usbb1_ulpiphy_dat0 */
> +			0x8c (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat1.usbb1_ulpiphy_dat1 */
> +			0x8e (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat2.usbb1_ulpiphy_dat2 */
> +			0x90 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat3.usbb1_ulpiphy_dat3 */
> +			0x92 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat4.usbb1_ulpiphy_dat4 */
> +			0x94 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat5.usbb1_ulpiphy_dat5 */
> +			0x96 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat6.usbb1_ulpiphy_dat6 */
> +			0x98 (PIN_INPUT_PULLDOWN | MUX_MODE4)	/* usbb1_ulpitll_dat7.usbb1_ulpiphy_dat7 */
> +		>;
> +	};
> +
> +	hsusb1phy_pins: pinmux_hsusb1phy_pins {
> +		pinctrl-single,pins = <
> +			0x4c (PIN_OUTPUT | MUX_MODE3)		/* gpmc_wait1.gpio_62 */
> +		>;
> +	};
> +
> +	w2cbw0015_pins: pinmux_w2cbw0015_pins {
> +		pinctrl-single,pins = <
> +			0x26 (PIN_OUTPUT | MUX_MODE3)		/* gpmc_a19.gpio_43 */
> +			0x3a (PIN_INPUT | MUX_MODE3)		/* gpmc_ncs3.gpio_53 */
> +		>;
> +	};
> +
> +	i2c1_pins: pinmux_i2c1_pins {
> +		pinctrl-single,pins = <
> +			0xe2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_scl */
> +			0xe4 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c1_sda */
> +		>;
> +	};
> +
> +	i2c4_pins: pinmux_i2c4_pins {
> +		pinctrl-single,pins = <
> +			0xee (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_scl */
> +			0xf0 (PIN_INPUT_PULLUP | MUX_MODE0)	/* i2c4_sda */
> +		>;
> +	};
> +
> +	mmc1_pins: pinmux_mmc1_pins {
> +		pinctrl-single,pins = <
> +			0xa2 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_clk */
> +			0xa4 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc1_cmd */
> +			0xa6 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc1_dat0 */
> +			0xa8 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat1 */
> +			0xaa (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat2 */
> +			0xac (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc1_dat3 */
> +		>;
> +	};
> +
> +	mmc5_pins: pinmux_mmc5_pins {
> +		pinctrl-single,pins = <
> +			0x108 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_clk */
> +			0x10a (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc5_cmd */
> +			0x10c (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmcc5_dat0 */
> +			0x10e (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat1 */
> +			0x110 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat2 */
> +			0x112 (PIN_INPUT_PULLUP | MUX_MODE0)	/* sdmmc5_dat3 */
> +		>;
> +	};
> +};
> +
> +/* PMIC */
> +&i2c1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c1_pins>;
> +
> +	clock-frequency = <400000>;
> +
> +	twl: twl at 48 {
> +		reg = <0x48>;
> +		interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>;		/* IRQ_SYS_1N cascaded to gic */
> +		interrupt-parent = <&gic>;
> +	};
> +
> +	twl6040: twl at 4b {
> +		compatible = "ti,twl6040";
> +		reg = <0x4b>;
> +		interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH>;		/* IRQ_SYS_2N cascaded to gic */
> +		interrupt-parent = <&gic>;
> +		ti,audpwron-gpio = <&gpio6 0 GPIO_ACTIVE_HIGH>;		/* gpio_160 */
> +
> +		vio-supply = <&v1v8>;
> +		v2v1-supply = <&v2v1>;
> +		enable-active-high;
> +	};
> +};
> +
> +#include "twl6030.dtsi"
> +#include "twl6030_omap4.dtsi"
> +
> +/* on-board bluetooth / WiFi module */
> +&i2c4 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&i2c4_pins>;
> +
> +	clock-frequency = <400000>;
> +};
> +
> +&mmc1 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc1_pins>;
> +
> +	vmmc-supply = <&vmmc>;
> +	ti,bus-width = <4>;
> +	ti,non-removable;		/* FIXME: use PMIC_MMC detect */
> +};
> +
> +&mmc2 {
> +	status = "disabled";
> +};
> +
> +/* mmc3 is available to the expansion board */
> +
> +&mmc4 {
> +	status = "disabled";
> +};
> +
> +/* on-board WiFi module */
> +&mmc5 {
> +	pinctrl-names = "default";
> +	pinctrl-0 = <&mmc5_pins>;
> +
> +	vmmc-supply = <&w2cbw0015_vmmc>;
> +	ti,bus-width = <4>;
> +	ti,non-removable;
> +	cap-power-off-card;
> +};
> +
> +&twl_usb_comparator {
> +	usb-supply = <&vusb>;
> +};
> +
> +&usb_otg_hs {
> +	interface-type = <1>;
> +	mode = <3>;
> +	power = <50>;
> +};
> +
> +&usbhshost {
> +	port1-mode = "ehci-phy";
> +};
> +
> +&usbhsehci {
> +	phys = <&hsusb1_phy>;
> +};
> +
> 

Re: [PATCH 1/2] ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor

[Tony Lindgren]

* Florian Vaussard <florian.vaussard@epfl.ch> [140303 02:12]:
> Hi Tony, Benoit,
> 
> On 02/24/2014 06:07 PM, Florian Vaussard wrote:
> > Gumstix DuoVero is an OMAP4430-based Computer On Module.
> > Parlor is one of the available expansion board.
> > 
> > Tested features:
> > - GPMC ethernet
> > - HSUSB2 and OTG
> > - Audio out
> > - WiFi and Bluetooth (w2cbw0015 SDIO module)
> > - LED and button
> > 
> 
> Can this patch go into 3.15? The other one (HDMI support) can wait for
> the DSS support to be merged, but I would like to give to this DTS a
> wider exposure to testing opportunities.

Thanks applying into omap-for-v3.15/dt.

Regards,

Tony

[PATCH 1/2] ARM: dts: Add support for OMAP4 Gumstix DuoVero/Parlor

[Tony Lindgren]

* Florian Vaussard <florian.vaussard@epfl.ch> [140303 02:12]:
> Hi Tony, Benoit,
> 
> On 02/24/2014 06:07 PM, Florian Vaussard wrote:
> > Gumstix DuoVero is an OMAP4430-based Computer On Module.
> > Parlor is one of the available expansion board.
> > 
> > Tested features:
> > - GPMC ethernet
> > - HSUSB2 and OTG
> > - Audio out
> > - WiFi and Bluetooth (w2cbw0015 SDIO module)
> > - LED and button
> > 
> 
> Can this patch go into 3.15? The other one (HDMI support) can wait for
> the DSS support to be merged, but I would like to give to this DTS a
> wider exposure to testing opportunities.

Thanks applying into omap-for-v3.15/dt.

Regards,

Tony

Re: [PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Laurent Pinchart]

Hi Russell,

On Wednesday 26 February 2014 13:28:56 Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote:
> > > Also - DRM is not going to ever support hotplugging components - this
> > > was discussed at kernel summit last year and David Airlie was quite
> > 
> > Ok. Very odd stance. Maybe there's a reason for it that I just don't see.
> 
> DRM is like ALSA - it's a card level subsystem.  All components have
> to be present before the card level is brought up for the subsystem to
> function correctly.

I agree with Tomi here, I believe hot-plug (without hot-unplug) would be 
useful in case part of a video pipeline fails to probe. In a multi-output 
system (let's say HDMI and DSI panel for instance) I'd like the HDMI output to 
work if the DSI panel driver isn't loaded.

DRM doesn't support this, and will not in the near future, but let's just keep 
in mind that real use cases exist. I'm not asking anyone to implement DRM hot-
plug support now, but the idea itself shouldn't be nacked if someone can come 
up with a proper implementation.

> > > adamant about that.  So, any "framework" which forces hotplugging of
> > > components on subsystems isn't going to fly.
> > 
> > CDF doesn't force hotplugging.
> > 
> > Although without hotplugging (hot-unplug not needed), or at least some
> > minimal form of it, the system is a bit crippled. Leave one kernel
> > module out, or have one driver probe fail, the whole display subsystem
> > fails, even if some display pipelines would work fine.
> 
> That is, unfortunately, one of the side effects of the policy - but that's
> not a policy that's going to change any time soon.  As I said, that was
> made very clear at the last kernel summit - we had a /specific/ session
> on the issues around multi-device DRM chaired by David.
> 
> There are some DRM drivers which have tried to do this, but they're all
> buggy in some regard, whether that be to the point of oopsing the kernel
> if things don't quite go to plan, or whether it's races between different
> parts.
> 
> > > This is why we now have the component helpers in the driver model -
> > > to allow devices to be collected together into one logical subsystem
> > > group, and bound/unbound as a group.
> > 
> > Yep, it's a good start. The component helpers could well be used with CDF.
> > 
> > But if I'm not mistaken, it suffers from the problems above, when there
> > are multiple independent pipelines (simultaneous or non-simultaneous)
> > handled by the same IPs.
> 
> It may "suffer from the problems above" that you've raised, but that's
> by explicit design of it - because that's what subsystems like DRM and
> ALSA require, and this is _precisely_ the problem it's solving.
> 
> It's solving the "subsystem requires a stable view of hardware components,
> but we have multiple devices and drivers which need probing" problem.
> 
> > And, while I may be mistaken, it sounds that the component helpers leave
> > mostly everything up to the display drivers. Everyone devising their own
> > way to describe the hardware in DT, and the connections between the
> > components. Of course, the core component system shouldn't define
> > anything DT related, as it doesn't. But that part is still needed, which
> > is where CDF comes in.
> 
> Sigh.  It's very easy for people to get the wrong end of the stick.
> 
> What the component helpers do is provide a _subsystem_ _independent_
> method of collecting a set of devices together and binding them to the
> drivers at an appropriate time, in a way that is _completely_ independent
> of whether you're using platform data, DT, ACPI, or whatever other
> hardware description language comes along.

I think we all agree here, the component framework is required to implement 
clean support for component-based, DT-based systems, but doesn't depend on DT 
and doesn't imply any specific DT binding. What I believe bother people is 
that the example you have goes in a direction that might not be future-proof, 
and should thus not be used as an example to create display-related DT 
bindings. My understanding is that it's just an example to illustrate the kind 
of use case that the component framework can help with, not a proper DT 
bindings example that should be followed to design now DT bindings.

> It's up to the users of this to define how components are grouped
> together, whether that be at the subsystem level or at the driver
> level - whatever is appropriate.
> 
> If a subsystem (eg, a display subsystem) wants to define "this is how
> you define in DT the bindings between all components" and provide its
> own hook for the "add_components" callback which does this, then it's
> at liberty to do that.
> 
> If we can come up with a generic way to describe how all the components
> in a display subsystem should be connected together, then great - but
> that needs to happen very quickly.  Philipp Zabel is working on replacing
> the imx-drm binding method right now for 3.15, and is probably completely
> unaware of anything that's been talked about here.  I need to sort out
> Armada DRM at some point to use the component stuff, which includes
> sorting out TDA998x for DT - which again needs to be done in such a way
> that it follows a common theme.
> 
> > I need to ask Dave why he is so strongly opposed to hotplugging
> > components.
> 
> I suspect one reason for it is because it means rewriting the XF86
> backend to Xorg to cope with it...

<troll>The world is moving to Wayland anyway</troll>

;-)

> > > Remember that "hotplugging" in this context does not mean that the
> > > user can physically do something with the hardware.  It means that
> > > they're separate devices which can be probed/removed at will.  Every
> > > device in Linux can be bound and unbound from its driver at any time
> > > by userspace, and that is something which is expected to be handled
> > > gracefully.
> > 
> > Hmm, sorry, can you rephrase?
> 
> I'll do better than that.  Try running this script with the
> /sys/bus/.../drivers/whatever for the drivers you wish to test:
> 
> #!/bin/sh
> for driver in "$@"; do
>    if [ -f "${driver}/unbind" ]; then
>       for device in "${driver}"/*; do
>          if [ -d "${device}" ]; then
>             devname="$(basename "${device}")"
>             echo "$devname" > "${driver}/unbind"
>             echo "$devname" > "${driver}/bind"
>          fi
>       done
>    fi
> done
> 
> The system should survive that.

I've kept this problem in the back of my head for some time now and I'm 
curious to know whether you have thought about how to solve it for component-
based systems. Given that DRM doesn't support hot-unplug, is the solution 
based on preventing driver unbind by returning an error from the remove 
handler ?

> > So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
> > etc, could appear even after the initial probe of the display controller.
> 
> This is the exact situation that David is opposed to.  DRM, like ALSA,
> whats to have a stable view of hardware - once the drm_device has been
> created and probed, no further changes to it are allowed.
> 
> Certainly no changes to the CRTCs will _ever_ be permitted, because it
> completely destroys the user API for referecing which encoders can be
> associated with which CRTCs - not only at the kernel level, but also the
> Xorg and Xrandr level too.  That's done via a bitmask of allowable CRTCs,
> where bit 0 refers to the first CRTC, bit 1 to the second and so on.
> That's propagated all the way through to userspace, right through the Xorg
> interfaces to applications.
> 
> Connectors and encoders are fixed at the moment after initial probe time
> in DRM due to the way the fbdev emulation layer works.  There's also issues
> there concerning bitmasks for which connectors can be cloned onto other
> connectors which follows the same pattern as above - and again, that
> propagates all the way through userspace.
> 
> So, if this is going to get fixed, there has to be a desire to break
> userspace quite badly, and there is no such desire to do that.
> 
> For instance, let's say that Xorg is up and running, and you have the
> gnome applet for configuring your display open, and you have two CRTCs.
> Then the first CRTC is removed from the system, resulting in CRTC 1
> becoming CRTC 0 in the kernel.  What happens...
> 
> Think the same thing through for a system with three connectors, A, B, C
> numbered 0, 1, and 2 respectively.  A and be cloned onto B.  Now connector
> A is removed, meaning B and C appear to become numbers 0 and 1 in the
> kernel...

-- 
Regards,

Laurent Pinchart

[PATCH 2/2] ARM: dts: duovero-parlor: Add HDMI output

[Laurent Pinchart]

Hi Russell,

On Wednesday 26 February 2014 13:28:56 Russell King - ARM Linux wrote:
> On Wed, Feb 26, 2014 at 02:44:02PM +0200, Tomi Valkeinen wrote:
> > > Also - DRM is not going to ever support hotplugging components - this
> > > was discussed at kernel summit last year and David Airlie was quite
> > 
> > Ok. Very odd stance. Maybe there's a reason for it that I just don't see.
> 
> DRM is like ALSA - it's a card level subsystem.  All components have
> to be present before the card level is brought up for the subsystem to
> function correctly.

I agree with Tomi here, I believe hot-plug (without hot-unplug) would be 
useful in case part of a video pipeline fails to probe. In a multi-output 
system (let's say HDMI and DSI panel for instance) I'd like the HDMI output to 
work if the DSI panel driver isn't loaded.

DRM doesn't support this, and will not in the near future, but let's just keep 
in mind that real use cases exist. I'm not asking anyone to implement DRM hot-
plug support now, but the idea itself shouldn't be nacked if someone can come 
up with a proper implementation.

> > > adamant about that.  So, any "framework" which forces hotplugging of
> > > components on subsystems isn't going to fly.
> > 
> > CDF doesn't force hotplugging.
> > 
> > Although without hotplugging (hot-unplug not needed), or at least some
> > minimal form of it, the system is a bit crippled. Leave one kernel
> > module out, or have one driver probe fail, the whole display subsystem
> > fails, even if some display pipelines would work fine.
> 
> That is, unfortunately, one of the side effects of the policy - but that's
> not a policy that's going to change any time soon.  As I said, that was
> made very clear at the last kernel summit - we had a /specific/ session
> on the issues around multi-device DRM chaired by David.
> 
> There are some DRM drivers which have tried to do this, but they're all
> buggy in some regard, whether that be to the point of oopsing the kernel
> if things don't quite go to plan, or whether it's races between different
> parts.
> 
> > > This is why we now have the component helpers in the driver model -
> > > to allow devices to be collected together into one logical subsystem
> > > group, and bound/unbound as a group.
> > 
> > Yep, it's a good start. The component helpers could well be used with CDF.
> > 
> > But if I'm not mistaken, it suffers from the problems above, when there
> > are multiple independent pipelines (simultaneous or non-simultaneous)
> > handled by the same IPs.
> 
> It may "suffer from the problems above" that you've raised, but that's
> by explicit design of it - because that's what subsystems like DRM and
> ALSA require, and this is _precisely_ the problem it's solving.
> 
> It's solving the "subsystem requires a stable view of hardware components,
> but we have multiple devices and drivers which need probing" problem.
> 
> > And, while I may be mistaken, it sounds that the component helpers leave
> > mostly everything up to the display drivers. Everyone devising their own
> > way to describe the hardware in DT, and the connections between the
> > components. Of course, the core component system shouldn't define
> > anything DT related, as it doesn't. But that part is still needed, which
> > is where CDF comes in.
> 
> Sigh.  It's very easy for people to get the wrong end of the stick.
> 
> What the component helpers do is provide a _subsystem_ _independent_
> method of collecting a set of devices together and binding them to the
> drivers at an appropriate time, in a way that is _completely_ independent
> of whether you're using platform data, DT, ACPI, or whatever other
> hardware description language comes along.

I think we all agree here, the component framework is required to implement 
clean support for component-based, DT-based systems, but doesn't depend on DT 
and doesn't imply any specific DT binding. What I believe bother people is 
that the example you have goes in a direction that might not be future-proof, 
and should thus not be used as an example to create display-related DT 
bindings. My understanding is that it's just an example to illustrate the kind 
of use case that the component framework can help with, not a proper DT 
bindings example that should be followed to design now DT bindings.

> It's up to the users of this to define how components are grouped
> together, whether that be at the subsystem level or at the driver
> level - whatever is appropriate.
> 
> If a subsystem (eg, a display subsystem) wants to define "this is how
> you define in DT the bindings between all components" and provide its
> own hook for the "add_components" callback which does this, then it's
> at liberty to do that.
> 
> If we can come up with a generic way to describe how all the components
> in a display subsystem should be connected together, then great - but
> that needs to happen very quickly.  Philipp Zabel is working on replacing
> the imx-drm binding method right now for 3.15, and is probably completely
> unaware of anything that's been talked about here.  I need to sort out
> Armada DRM at some point to use the component stuff, which includes
> sorting out TDA998x for DT - which again needs to be done in such a way
> that it follows a common theme.
> 
> > I need to ask Dave why he is so strongly opposed to hotplugging
> > components.
> 
> I suspect one reason for it is because it means rewriting the XF86
> backend to Xorg to cope with it...

<troll>The world is moving to Wayland anyway</troll>

;-)

> > > Remember that "hotplugging" in this context does not mean that the
> > > user can physically do something with the hardware.  It means that
> > > they're separate devices which can be probed/removed at will.  Every
> > > device in Linux can be bound and unbound from its driver at any time
> > > by userspace, and that is something which is expected to be handled
> > > gracefully.
> > 
> > Hmm, sorry, can you rephrase?
> 
> I'll do better than that.  Try running this script with the
> /sys/bus/.../drivers/whatever for the drivers you wish to test:
> 
> #!/bin/sh
> for driver in "$@"; do
>    if [ -f "${driver}/unbind" ]; then
>       for device in "${driver}"/*; do
>          if [ -d "${device}" ]; then
>             devname="$(basename "${device}")"
>             echo "$devname" > "${driver}/unbind"
>             echo "$devname" > "${driver}/bind"
>          fi
>       done
>    fi
> done
> 
> The system should survive that.

I've kept this problem in the back of my head for some time now and I'm 
curious to know whether you have thought about how to solve it for component-
based systems. Given that DRM doesn't support hot-unplug, is the solution 
based on preventing driver unbind by returning an error from the remove 
handler ?

> > So with hotplug, a new fbdev or a combination of drm crtcs, encoders,
> > etc, could appear even after the initial probe of the display controller.
> 
> This is the exact situation that David is opposed to.  DRM, like ALSA,
> whats to have a stable view of hardware - once the drm_device has been
> created and probed, no further changes to it are allowed.
> 
> Certainly no changes to the CRTCs will _ever_ be permitted, because it
> completely destroys the user API for referecing which encoders can be
> associated with which CRTCs - not only at the kernel level, but also the
> Xorg and Xrandr level too.  That's done via a bitmask of allowable CRTCs,
> where bit 0 refers to the first CRTC, bit 1 to the second and so on.
> That's propagated all the way through to userspace, right through the Xorg
> interfaces to applications.
> 
> Connectors and encoders are fixed at the moment after initial probe time
> in DRM due to the way the fbdev emulation layer works.  There's also issues
> there concerning bitmasks for which connectors can be cloned onto other
> connectors which follows the same pattern as above - and again, that
> propagates all the way through userspace.
> 
> So, if this is going to get fixed, there has to be a desire to break
> userspace quite badly, and there is no such desire to do that.
> 
> For instance, let's say that Xorg is up and running, and you have the
> gnome applet for configuring your display open, and you have two CRTCs.
> Then the first CRTC is removed from the system, resulting in CRTC 1
> becoming CRTC 0 in the kernel.  What happens...
> 
> Think the same thing through for a system with three connectors, A, B, C
> numbered 0, 1, and 2 respectively.  A and be cloned onto B.  Now connector
> A is removed, meaning B and C appear to become numbers 0 and 1 in the
> kernel...

-- 
Regards,

Laurent Pinchart