* [PATCH 3/4] Doc/DT: Add DT binding documentation for SHARP LS037V7DW01
From: Tomi Valkeinen @ 2014-05-16 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400225402-18274-1-git-send-email-tomi.valkeinen@ti.com>
From: Tony Lindgren <tony@atomide.com>
Add DT binding documentation for SHARP LS037V7DW01 panel.
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org
---
.../bindings/video/sharp,ls037v7dw01.txt | 43 ++++++++++++++++++++++
1 file changed, 43 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
diff --git a/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
new file mode 100644
index 000000000000..0cc8981e9d49
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/sharp,ls037v7dw01.txt
@@ -0,0 +1,43 @@
+SHARP LS037V7DW01 TFT-LCD panel
+=================+
+Required properties:
+- compatible: "sharp,ls037v7dw01"
+
+Optional properties:
+- label: a symbolic name for the panel
+- enable-gpios: a GPIO spec for the optional enable pin.
+ This pin is the INI pin as specified in the LS037V7DW01.pdf file.
+- reset-gpios: a GPIO spec for the optional reset pin.
+ This pin is the RESB pin as specified in the LS037V7DW01.pdf file.
+- mode-gpios: a GPIO
+ ordered MO, LR, and UD as specified in the LS037V7DW01.pdf file.
+
+Required nodes:
+- Video port for DPI input
+
+This panel can have zero to five GPIOs to configure to change configuration
+between QVGA and VGA mode and the scan direction. As these pins can be also
+configured with external pulls, all the GPIOs are considered optional with holes
+in the array.
+
+Example
+-------
+
+Example when connected to a omap2+ based device:
+
+lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ power-supply = <&lcd_3v3>;
+ enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 4/4] ARM: dts: Add LCD panel sharp ls037v7dw01 support for omap3-evm and ldp
From: Tomi Valkeinen @ 2014-05-16 7:30 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400225402-18274-1-git-send-email-tomi.valkeinen@ti.com>
From: Tony Lindgren <tony@atomide.com>
Looks like quite a few omap3 boards have sharp ls037v7dw01 that's
configured as various panel dpi entries for whatever legacy reasons.
For device tree based support, let's just configure these properly for
panel ls037v7dw01 instead of panel dpi.
This patch creates a common file for panel ls037v7dw01, and makes
boards ldp and omap3-evm to use it.
The ls037v7dw01 also seems to be coupled with an ad7846 touchscreen
controller for the omaps, so let's add a basic configuration for
the touchscreen also using the default values.
Note that we can now remove the regulator-name = "vdds_dsi"
entry for ldp, that's no longer needed as we have the entry
for vdds_dsi-supply = <&vpll2>.
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
arch/arm/boot/dts/omap3-evm-37xx.dts | 50 ++++++++++++++++
arch/arm/boot/dts/omap3-evm-common.dtsi | 26 +++++++++
arch/arm/boot/dts/omap3-ldp.dts | 29 ++++++++--
.../boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi | 67 ++++++++++++++++++++++
4 files changed, 167 insertions(+), 5 deletions(-)
create mode 100644 arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
diff --git a/arch/arm/boot/dts/omap3-evm-37xx.dts b/arch/arm/boot/dts/omap3-evm-37xx.dts
index 4df68ad3736a..a181e30daaef 100644
--- a/arch/arm/boot/dts/omap3-evm-37xx.dts
+++ b/arch/arm/boot/dts/omap3-evm-37xx.dts
@@ -26,7 +26,44 @@
};
};
+&dss {
+ pinctrl-names = "default";
+ pinctrl-0 = <
+ &dss_dpi_pins1
+ &dss_dpi_pins2
+ >;
+};
+
&omap3_pmx_core {
+ dss_dpi_pins1: pinmux_dss_dpi_pins2 {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x20d4, PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
+ OMAP3_CORE1_IOPAD(0x20d6, PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
+ OMAP3_CORE1_IOPAD(0x20d8, PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
+ OMAP3_CORE1_IOPAD(0x20da, PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
+
+ OMAP3_CORE1_IOPAD(0x20e8, PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
+ OMAP3_CORE1_IOPAD(0x20ea, PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
+ OMAP3_CORE1_IOPAD(0x20ec, PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
+ OMAP3_CORE1_IOPAD(0x20ee, PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
+ OMAP3_CORE1_IOPAD(0x20f0, PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
+ OMAP3_CORE1_IOPAD(0x20f2, PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
+ OMAP3_CORE1_IOPAD(0x20f4, PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
+ OMAP3_CORE1_IOPAD(0x20f6, PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
+ OMAP3_CORE1_IOPAD(0x20f8, PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
+ OMAP3_CORE1_IOPAD(0x20fa, PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
+ OMAP3_CORE1_IOPAD(0x20fc, PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
+ OMAP3_CORE1_IOPAD(0x20fe, PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
+
+ OMAP3_CORE1_IOPAD(0x2100, PIN_OUTPUT | MUX_MODE3) /* dss_data18.dss_data0 */
+ OMAP3_CORE1_IOPAD(0x2102, PIN_OUTPUT | MUX_MODE3) /* dss_data19.dss_data1 */
+ OMAP3_CORE1_IOPAD(0x2104, PIN_OUTPUT | MUX_MODE3) /* dss_data20.dss_data2 */
+ OMAP3_CORE1_IOPAD(0x2106, PIN_OUTPUT | MUX_MODE3) /* dss_data21.dss_data3 */
+ OMAP3_CORE1_IOPAD(0x2108, PIN_OUTPUT | MUX_MODE3) /* dss_data22.dss_data4 */
+ OMAP3_CORE1_IOPAD(0x210a, PIN_OUTPUT | MUX_MODE3) /* dss_data23.dss_data5 */
+ >;
+ };
+
mmc1_pins: pinmux_mmc1_pins {
pinctrl-single,pins = <
0x114 (PIN_OUTPUT_PULLUP | MUX_MODE0) /* sdmmc1_clk.sdmmc1_clk */
@@ -75,6 +112,19 @@
};
};
+&omap3_pmx_wkup {
+ dss_dpi_pins2: pinmux_dss_dpi_pins1 {
+ pinctrl-single,pins = <
+ 0x0a (PIN_OUTPUT | MUX_MODE3) /* sys_boot0.dss_data18 */
+ 0x0c (PIN_OUTPUT | MUX_MODE3) /* sys_boot1.dss_data19 */
+ 0x10 (PIN_OUTPUT | MUX_MODE3) /* sys_boot3.dss_data20 */
+ 0x12 (PIN_OUTPUT | MUX_MODE3) /* sys_boot4.dss_data21 */
+ 0x14 (PIN_OUTPUT | MUX_MODE3) /* sys_boot5.dss_data22 */
+ 0x16 (PIN_OUTPUT | MUX_MODE3) /* sys_boot6.dss_data23 */
+ >;
+ };
+};
+
&mmc1 {
pinctrl-names = "default";
pinctrl-0 = <&mmc1_pins>;
diff --git a/arch/arm/boot/dts/omap3-evm-common.dtsi b/arch/arm/boot/dts/omap3-evm-common.dtsi
index 3007e79c9cd6..8ae8f007c8ad 100644
--- a/arch/arm/boot/dts/omap3-evm-common.dtsi
+++ b/arch/arm/boot/dts/omap3-evm-common.dtsi
@@ -44,6 +44,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 18 GPIO_ACTIVE_LOW>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -61,6 +66,27 @@
};
};
+&lcd_3v3 {
+ gpio = <&gpio5 25 GPIO_ACTIVE_LOW>; /* gpio153 */
+ enable-active-low;
+};
+
+&lcd0 {
+ enable-gpios = <&gpio5 24 GPIO_ACTIVE_HIGH>; /* gpio152, lcd INI */
+ reset-gpios = <&gpio5 27 GPIO_ACTIVE_HIGH>; /* gpio155, lcd RESB */
+ mode-gpios = <&gpio5 26 GPIO_ACTIVE_HIGH /* gpio154, lcd MO */
+ &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
+ &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio6>;
+ interrupts = <15 0>; /* gpio175 */
+ pendown-gpio = <&gpio6 15 0>;
+ };
+};
+
&mmc1 {
vmmc-supply = <&vmmc1>;
vmmc_aux-supply = <&vsim>;
diff --git a/arch/arm/boot/dts/omap3-ldp.dts b/arch/arm/boot/dts/omap3-ldp.dts
index 0abe986a4ecc..9c751e420f37 100644
--- a/arch/arm/boot/dts/omap3-ldp.dts
+++ b/arch/arm/boot/dts/omap3-ldp.dts
@@ -164,6 +164,11 @@
#include "twl4030.dtsi"
#include "twl4030_omap3.dtsi"
+#include "omap3-panel-sharp-ls037v7dw01.dtsi"
+
+&backlight0 {
+ gpios = <&twl_gpio 7 GPIO_ACTIVE_HIGH>;
+};
&i2c2 {
clock-frequency = <400000>;
@@ -173,6 +178,25 @@
clock-frequency = <400000>;
};
+/* tps61130rsa enabled by twl4030 regen */
+&lcd_3v3 {
+ regulator-always-on;
+};
+
+&lcd0 {
+ enable-gpios = <&twl_gpio 15 GPIO_ACTIVE_HIGH>; /* lcd INI */
+ reset-gpios = <&gpio2 23 GPIO_ACTIVE_HIGH>; /* gpio55, lcd RESB */
+ mode-gpios = <&gpio2 24 GPIO_ACTIVE_HIGH>; /* gpio56, lcd MO */
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ interrupt-parent = <&gpio2>;
+ interrupts = <22 0>; /* gpio54 */
+ pendown-gpio = <&gpio2 22 0>;
+ };
+};
+
&mmc1 {
/* See 35xx errata 2.1.1.128 in SPRZ278F */
compatible = "ti,omap3-pre-es3-hsmmc";
@@ -247,8 +271,3 @@
/* Needed for ads7846 */
regulator-name = "vcc";
};
-
-&vpll2 {
- /* Needed for DSS */
- regulator-name = "vdds_dsi";
-};
diff --git a/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
new file mode 100644
index 000000000000..93934762f6d5
--- /dev/null
+++ b/arch/arm/boot/dts/omap3-panel-sharp-ls037v7dw01.dtsi
@@ -0,0 +1,67 @@
+/*
+ * Common file for omap dpi panels with QVGA and reset pins
+ *
+ * Note that the board specifc DTS file needs to specify
+ * at minimum the GPIO enable-gpios for display, and
+ * gpios for gpio-backlight.
+ */
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ backlight0: backlight {
+ compatible = "gpio-backlight";
+ default-on;
+ };
+
+ /* 3.3V GPIO controlled regulator for LCD_ENVDD */
+ lcd_3v3: regulator-lcd-3v3 {
+ compatible = "regulator-fixed";
+ regulator-name = "lcd_3v3";
+ regulator-min-microvolt = <3300000>;
+ regulator-max-microvolt = <3300000>;
+ startup-delay-us = <70000>;
+ };
+
+ lcd0: display {
+ compatible = "sharp,ls037v7dw01";
+ label = "lcd";
+ power-supply = <&lcd_3v3>;
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+ };
+};
+
+&dss {
+ status = "ok";
+ vdds_dsi-supply = <&vpll2>;
+ port {
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <18>;
+ };
+ };
+};
+
+&mcspi1 {
+ tsc2046@0 {
+ reg = <0>; /* CS0 */
+ compatible = "ti,tsc2046";
+ spi-max-frequency = <1000000>;
+ vcc-supply = <&lcd_3v3>;
+ ti,x-min = /bits/ 16 <0>;
+ ti,x-max = /bits/ 16 <8000>;
+ ti,y-min = /bits/ 16 <0>;
+ ti,y-max = /bits/ 16 <4800>;
+ ti,x-plate-ohms = /bits/ 16 <40>;
+ ti,pressure-max = /bits/ 16 <255>;
+ ti,swap-xy;
+ linux,wakeup;
+ };
+};
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] video: omap: delete support for early fbmem allocation
From: Tomi Valkeinen @ 2014-05-16 8:56 UTC (permalink / raw)
To: Aaro Koskinen, linux-omap, linux-fbdev
Cc: linux-kernel, Peter Griffin, Arnd Bergmann,
Jean-Christophe Plagniol-Villard, Janusz Krzysztofik,
Tony Lindgren
In-Reply-To: <1399675964-22917-1-git-send-email-aaro.koskinen@iki.fi>
[-- Attachment #1: Type: text/plain, Size: 542 bytes --]
On 10/05/14 01:52, Aaro Koskinen wrote:
> Commit 1e434f9318efc3dddc0c0b8d2071712668154c2b (OMAPFB: remove early mem
> alloc from old omapfb) deleted the support for early fbmem allocation
> from the platform code, but some code still remains in the driver side.
> Delete this code now, as it repotedly causes build issues on !MMU.
>
> The patch was tested on Amstrad E3 and Nokia 770 and framebuffer
> functionality is not affected.
>
> Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v4] video: mx3fb: Add backlight control support
From: Tomi Valkeinen @ 2014-05-16 8:59 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1399876454-17882-1-git-send-email-alexander.stein@systec-electronic.com>
[-- Attachment #1: Type: text/plain, Size: 326 bytes --]
On 12/05/14 09:34, Alexander Stein wrote:
> This patch add backlight control support to allow dimming the backlight
> using the internal PWM. Currently the brightness is set fixed to a
> maximum of 255.
>
> Signed-off-by: Alexander Stein <alexander.stein@systec-electronic.com>
Thanks, queued for 3.16.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH V2] video : remove redundant error check
From: Daeseok Youn @ 2014-05-16 9:31 UTC (permalink / raw)
To: plagnioj
Cc: tomi.valkeinen, jg1.han, laurent.pinchart, robdclark,
daniel.vetter, Julia.Lawall, linux-fbdev, linux-kernel
It doesn't need to check "err" for printing info.
And also use pr_info instead of printk.
Signed-off-by: Daeseok Youn <daeseok.youn@gmail.com>
---
V2: removes unneeded lines for sending a patch
drivers/video/fbdev/i810/i810_main.c | 7 +++----
1 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/video/fbdev/i810/i810_main.c b/drivers/video/fbdev/i810/i810_main.c
index bb674e4..15cb397 100644
--- a/drivers/video/fbdev/i810/i810_main.c
+++ b/drivers/video/fbdev/i810/i810_main.c
@@ -1910,13 +1910,12 @@ static void i810fb_find_init_mode(struct fb_info *info)
for (i = 0; i < par->ddc_num + 1; i++) {
err = i810_probe_i2c_connector(info, &par->edid, i);
- if (!err)
+ if (!err) {
+ pr_info("i810fb_init_pci: DDC probe successful\n");
break;
+ }
}
- if (!err)
- printk("i810fb_init_pci: DDC probe successful\n");
-
fb_edid_to_monspecs(par->edid, specs);
if (specs->modedb = NULL)
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] OMAPDSS: Panel TPO-TD043MTEA1 DT support
From: Tomi Valkeinen @ 2014-05-16 9:55 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen, Grazvydas Ignotas
Add DT support for panel TPO-TD043MTEA1.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Grazvydas Ignotas <notasas@gmail.com>
---
.../omap2/displays-new/panel-tpo-td043mtea1.c | 41 +++++++++++++++++++++-
1 file changed, 40 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c b/drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c
index 875b40263b33..ce509fbd235d 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-tpo-td043mtea1.c
@@ -17,6 +17,7 @@
#include <linux/gpio.h>
#include <linux/err.h>
#include <linux/slab.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -376,7 +377,8 @@ static int tpo_td043_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
in->ops.dpi->set_timings(in, &ddata->videomode);
r = in->ops.dpi->enable(in);
@@ -489,6 +491,31 @@ static int tpo_td043_probe_pdata(struct spi_device *spi)
return 0;
}
+static int tpo_td043_probe_of(struct spi_device *spi)
+{
+ struct device_node *node = spi->dev.of_node;
+ struct panel_drv_data *ddata = dev_get_drvdata(&spi->dev);
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_named_gpio(node, "reset-gpios", 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(&spi->dev, "failed to parse enable gpio\n");
+ return gpio;
+ }
+ ddata->nreset_gpio = gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&spi->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int tpo_td043_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -518,6 +545,10 @@ static int tpo_td043_probe(struct spi_device *spi)
r = tpo_td043_probe_pdata(spi);
if (r)
return r;
+ } else if (spi->dev.of_node) {
+ r = tpo_td043_probe_of(spi);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -629,6 +660,13 @@ static int tpo_td043_spi_resume(struct device *dev)
static SIMPLE_DEV_PM_OPS(tpo_td043_spi_pm,
tpo_td043_spi_suspend, tpo_td043_spi_resume);
+static const struct of_device_id tpo_td043_of_match[] = {
+ { .compatible = "omapdss,tpo,td043mtea1", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tpo_td043_of_match);
+
static struct spi_driver tpo_td043_spi_driver = {
.driver = {
.name = "panel-tpo-td043mtea1",
@@ -641,6 +679,7 @@ static struct spi_driver tpo_td043_spi_driver = {
module_spi_driver(tpo_td043_spi_driver);
+MODULE_ALIAS("spi:tpo,td043mtea1");
MODULE_AUTHOR("Gražvydas Ignotas <notasas@gmail.com>");
MODULE_DESCRIPTION("TPO TD043MTEA1 LCD Driver");
MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* [PATCH 2/3] Doc/DT: Add DT binding documentation for TPO td043mtea1 panel
From: Tomi Valkeinen @ 2014-05-16 9:55 UTC (permalink / raw)
To: linux-fbdev, linux-omap
Cc: Archit Taneja, Tomi Valkeinen, devicetree, Grazvydas Ignotas
In-Reply-To: <1400234112-29306-1-git-send-email-tomi.valkeinen@ti.com>
Add DT binding documentation for TPO td043mtea1 panel
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: devicetree@vger.kernel.org
Cc: Grazvydas Ignotas <notasas@gmail.com>
---
.../devicetree/bindings/video/tpo,td043mtea1.txt | 33 ++++++++++++++++++++++
1 file changed, 33 insertions(+)
create mode 100644 Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
diff --git a/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
new file mode 100644
index 000000000000..ec6d62975162
--- /dev/null
+++ b/Documentation/devicetree/bindings/video/tpo,td043mtea1.txt
@@ -0,0 +1,33 @@
+TPO TD043MTEA1 Panel
+==========
+
+Required properties:
+- compatible: "tpo,td043mtea1"
+- reset-gpios: panel reset gpio
+
+Optional properties:
+- label: a symbolic name for the panel
+
+Required nodes:
+- Video port for DPI input
+
+Example
+-------
+
+lcd-panel: panel@0 {
+ compatible = "tpo,td043mtea1";
+ reg = <0>;
+ spi-max-frequency = <100000>;
+ spi-cpol;
+ spi-cpha;
+
+ label = "lcd";
+
+ reset-gpios = <&gpio7 7 0>;
+
+ port {
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+};
--
1.9.1
^ permalink raw reply related
* [PATCH 3/3] OMAPDSS: panel NEC-NL8048HL11 DT support
From: Tomi Valkeinen @ 2014-05-16 9:55 UTC (permalink / raw)
To: linux-fbdev, linux-omap; +Cc: Archit Taneja, Tomi Valkeinen, Erik Gilling
In-Reply-To: <1400234112-29306-1-git-send-email-tomi.valkeinen@ti.com>
We don't have any working boards using this panel right now, and the
panel driver looks odd compared to the panel specs. For example, the
panel spec does not mention any QVGA pin.
So, while this patch adds DT support to the driver, it's not really
supported and there are not bindings documentation for the panel until
someone can verify how the panel actually works.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Cc: Erik Gilling <konkers@android.com>
---
.../omap2/displays-new/panel-nec-nl8048hl11.c | 44 +++++++++++++++++++++-
1 file changed, 43 insertions(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/displays-new/panel-nec-nl8048hl11.c b/drivers/video/fbdev/omap2/displays-new/panel-nec-nl8048hl11.c
index 996fa004b48c..553e5643e4ba 100644
--- a/drivers/video/fbdev/omap2/displays-new/panel-nec-nl8048hl11.c
+++ b/drivers/video/fbdev/omap2/displays-new/panel-nec-nl8048hl11.c
@@ -16,6 +16,7 @@
#include <linux/spi/spi.h>
#include <linux/fb.h>
#include <linux/gpio.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -156,7 +157,8 @@ static int nec_8048_enable(struct omap_dss_device *dssdev)
if (omapdss_device_is_enabled(dssdev))
return 0;
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
in->ops.dpi->set_timings(in, &ddata->videomode);
r = in->ops.dpi->enable(in);
@@ -258,6 +260,34 @@ static int nec_8048_probe_pdata(struct spi_device *spi)
return 0;
}
+static int nec_8048_probe_of(struct spi_device *spi)
+{
+ struct device_node *node = spi->dev.of_node;
+ struct panel_drv_data *ddata = dev_get_drvdata(&spi->dev);
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_named_gpio(node, "reset-gpios", 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(&spi->dev, "failed to parse enable gpio\n");
+ return gpio;
+ }
+ ddata->res_gpio = gpio;
+
+ /* XXX the panel spec doesn't mention any QVGA pin?? */
+ ddata->qvga_gpio = -ENOENT;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&spi->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int nec_8048_probe(struct spi_device *spi)
{
struct panel_drv_data *ddata;
@@ -289,6 +319,10 @@ static int nec_8048_probe(struct spi_device *spi)
r = nec_8048_probe_pdata(spi);
if (r)
return r;
+ } else if (spi->dev.of_node) {
+ r = nec_8048_probe_of(spi);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -377,6 +411,13 @@ static SIMPLE_DEV_PM_OPS(nec_8048_pm_ops, nec_8048_suspend,
#define NEC_8048_PM_OPS NULL
#endif
+static const struct of_device_id lb035q02_of_match[] = {
+ { .compatible = "omapdss,nec,nl8048hl11", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, lb035q02_of_match);
+
static struct spi_driver nec_8048_driver = {
.driver = {
.name = "panel-nec-nl8048hl11",
@@ -389,6 +430,7 @@ static struct spi_driver nec_8048_driver = {
module_spi_driver(nec_8048_driver);
+MODULE_ALIAS("spi:nec,nl8048hl11");
MODULE_AUTHOR("Erik Gilling <konkers@android.com>");
MODULE_DESCRIPTION("NEC-NL8048HL11 Driver");
MODULE_LICENSE("GPL");
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 07/19] OMAPDSS: hdmi5_core: Fix compilation with OMAP5_DSS_HDMI_AUDIO
From: Tomi Valkeinen @ 2014-05-16 10:31 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <6e02441be6a699e4376e547ae99515d14079850d.1399884780.git.jsarha@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]
Hi,
On 12/05/14 12:12, Jyri Sarha wrote:
> Use correct variable name for base address.
>
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> drivers/video/fbdev/omap2/dss/hdmi5_core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/hdmi5_core.c b/drivers/video/fbdev/omap2/dss/hdmi5_core.c
> index 270ebdd..af88e3c 100644
> --- a/drivers/video/fbdev/omap2/dss/hdmi5_core.c
> +++ b/drivers/video/fbdev/omap2/dss/hdmi5_core.c
> @@ -786,7 +786,7 @@ static void hdmi5_core_audio_config(struct hdmi_core_data *core,
> REG_FLD_MOD(base, HDMI_CORE_AUD_GP_POL, 1, 0, 0);
>
> /* unmute audio */
> - REG_FLD_MOD(core_sys_base, HDMI_CORE_FC_AUDSCONF, 0, 7, 4);
> + REG_FLD_MOD(base, HDMI_CORE_FC_AUDSCONF, 0, 7, 4);
> }
>
> static void hdmi5_core_audio_infoframe_cfg(struct hdmi_core_data *core,
This fix is independent of the rest of the series, so I'll already pick
this one to my 3.16 omapdss branch.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
From: Tomi Valkeinen @ 2014-05-16 10:52 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <198496d6220a13b0e8910361d969b8f978ee1398.1399884780.git.jsarha@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]
Hi,
On 12/05/14 12:12, Jyri Sarha wrote:
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> drivers/video/fbdev/omap2/dss/Kconfig | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig
> index 8921a7a..ecc2f50 100644
> --- a/drivers/video/fbdev/omap2/dss/Kconfig
> +++ b/drivers/video/fbdev/omap2/dss/Kconfig
> @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI
> HDMI support for OMAP4 based SoCs.
>
> config OMAP4_DSS_HDMI_AUDIO
> - bool
> + bool "HDMI audio support for OMAP4"
> + depends on OMAP4_DSS_HDMI
> + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
> + default y
> + help
> + HDMI audio support for OMAP4 based SoCs. Adds integrated
> + ASoC Digital Audio Interface component driver into OMAPDSS
> + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with
> + devicetree description for full HDMI audio support.
What does "for full HDMI audio support" mean? What's the partial support? =)
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 14/19] ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
From: Tomi Valkeinen @ 2014-05-16 11:04 UTC (permalink / raw)
To: Jyri Sarha, alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <fdeddff24bc38efb7a155b2569a5f2056278cb9d.1399884780.git.jsarha@ti.com>
[-- Attachment #1: Type: text/plain, Size: 1852 bytes --]
On 12/05/14 12:12, Jyri Sarha wrote:
> Adds a simple-card sound node for HDMI audio, the associated
> hdmi-codec node, and sound-dai-cells propeties to the DAI nodes.
>
> Signed-off-by: Jyri Sarha <jsarha@ti.com>
> ---
> arch/arm/boot/dts/omap4-panda-common.dtsi | 21 ++++++++++++++++++++-
> 1 file changed, 20 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index d2c45bf..c04f453 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -41,7 +41,7 @@
> };
> };
>
> - sound: sound {
> + sound: sound@0 {
> compatible = "ti,abe-twl6040";
> ti,model = "PandaBoard";
>
> @@ -65,6 +65,24 @@
> "AFMR", "Line In";
> };
>
> + sound@1 {
> + compatible = "simple-audio-card";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&hdmi>;
> + };
> +
> + simple-audio-card,codec {
> + sound-dai = <&hdmi_audio>;
> + };
> + };
> +
> + hdmi_audio: hdmi_audio@0 {
> + #sound-dai-cells = <0>;
> + compatible = "linux,hdmi-audio";
> + status = "okay";
> + };
> +
> /* HS USB Port 1 Power */
> hsusb1_power: hsusb1_power_reg {
> compatible = "regulator-fixed";
> @@ -512,6 +530,7 @@
> };
>
> &hdmi {
> + #sound-dai-cells = <0>;
> status = "ok";
> vdda-supply = <&vdac>;
Maybe this is how this has to be done, but I'll still ask:
Considering that the HDMI audio is basically inseparable part of the
OMAP HDMI video, and if a board has HDMI video connector connected to
the SoC's HDMI, then it has HDMI audio.
So all of the above .dts changes are already implied when we have HDMI
video on the board. Is there no way to prevent every board needing to
add those exact same nodes to get HDMI audio?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 14/19] ARM: omap4-panda-common.dtsi: Add HDMI audio nodes
From: Mark Brown @ 2014-05-16 11:08 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Jyri Sarha, alsa-devel, linux-fbdev, devicetree, linux-omap,
peter.ujfalusi, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <5375F0CC.8090507@ti.com>
[-- Attachment #1: Type: text/plain, Size: 378 bytes --]
On Fri, May 16, 2014 at 02:04:44PM +0300, Tomi Valkeinen wrote:
> So all of the above .dts changes are already implied when we have HDMI
> video on the board. Is there no way to prevent every board needing to
> add those exact same nodes to get HDMI audio?
You can always instantiate devices directly from the HDMI controller
code, there's no need to put things in DT at all.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 05/19] OMAPDSS: Kconfig: Add depencies and help section to OMAP4_DSS_HDMI_AUDIO
From: Jyri Sarha @ 2014-05-16 11:56 UTC (permalink / raw)
To: Tomi Valkeinen, alsa-devel, linux-fbdev, devicetree, linux-omap
Cc: peter.ujfalusi, broonie, liam.r.girdwood, bcousson, detheridge
In-Reply-To: <5375EE07.4090802@ti.com>
On 05/16/2014 01:52 PM, Tomi Valkeinen wrote:
> Hi,
>
> On 12/05/14 12:12, Jyri Sarha wrote:
>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>> ---
>> drivers/video/fbdev/omap2/dss/Kconfig | 10 +++++++++-
>> 1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/video/fbdev/omap2/dss/Kconfig b/drivers/video/fbdev/omap2/dss/Kconfig
>> index 8921a7a..ecc2f50 100644
>> --- a/drivers/video/fbdev/omap2/dss/Kconfig
>> +++ b/drivers/video/fbdev/omap2/dss/Kconfig
>> @@ -70,7 +70,15 @@ config OMAP4_DSS_HDMI
>> HDMI support for OMAP4 based SoCs.
>>
>> config OMAP4_DSS_HDMI_AUDIO
>> - bool
>> + bool "HDMI audio support for OMAP4"
>> + depends on OMAP4_DSS_HDMI
>> + depends on SND_OMAP_SOC=y || OMAP2_DSS = SND_OMAP_SOC
>> + default y
>> + help
>> + HDMI audio support for OMAP4 based SoCs. Adds integrated
>> + ASoC Digital Audio Interface component driver into OMAPDSS
>> + module. Select SND_SOC_HDMI_CODEC and SND_SIMPLE_CARD with
>> + devicetree description for full HDMI audio support.
>
> What does "for full HDMI audio support" mean? What's the partial support? =)
>
The hdmi driver provides a digital audio interface (DAI) which can be
used to transmit audio over the HDMI cable. The ASoC DAI component
driver provides just that functionality. A machine, platform, and (in
this case a dummy) codec component driver is also needed for a complete
ALSA device functionality.
Anyway, I look into Mark's suggestion of instantiating all the necessary
component drivers from the HDMI driver.
Best regards,
Jyri
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-16 15:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5375A713.7030409@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:51]:
> On 15/05/14 21:25, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 01:42]:
> >> On 14/05/14 00:26, Tony Lindgren wrote:
> >>
> >>> + /* lcd MO */
> >>> + ddata->mo_gpio = sharp_ls_get_gpio_of(&pdev->dev, 0, 1, "mode");
> >>> + if (PTR_ERR(ddata->mo_gpio) = -EPROBE_DEFER)
> >>> + return -EPROBE_DEFER;
> >>> +
> >>> + if (!IS_ERR(ddata->mo_gpio))
> >>> + if (gpiod_get_raw_value_cansleep(ddata->mo_gpio))
> >>> + ddata->flags |= SHARP_LS_QVGA;
> >>
> >> Shouldn't there be an explicit flag in the DT data for this? If the
> >> panel's MO pin is hardwired to, say, pull up, then the mode-gpios won't
> >> have MO gpio, right? So something like:
> >>
> >>
> >> mode-gpios = <0 /* high, lcd MO */
> >> &gpio1 2 GPIO_ACTIVE_HIGH /* gpio2, lcd LR */
> >> &gpio1 3 GPIO_ACTIVE_HIGH>; /* gpio3, lcd UD */
> >>
> >> vga-mode; /* MO hardwired high */
> >
> > Yeah holes there are just fine. I figured let's keep the custom
> > vga-mode property out of the way until we actually run into a panel
> > that's not using a GPIO for mode.
>
> Ok, I'm fine with that, but in that case I think we have to use all the
> panels in the same mode, i.e. the driver either sets the MO gpio always
> low and uses VGA mode, or sets the MO always high and uses QVGA mode.
OK let's default to VGA mode for now.
> In your omap3-evm.dts patch, you set the MO gpio ACTIVE_LOW in order to
> change the mode, even if it really should be ACTIVE_HIGH. But if you do
> that, and we later add the support to the panel driver to manage the MO
> gpio dynamically (i.e. the user can select VGA/QVGA at runtime), then
> the panel won't work as the driver uses wrong polarity for the pin.
Getting the configured value seemed to work just fine with
gpiod_get_raw_value_cansleep(ddata->mo_gpio). But yeah I agree the
lack and confusion between polarity and desired default value for
a GPIO is is sucky. The ACTIVE_HIGH probably should mean polarity.
I don't know if there's an easy solution to that short of adding a
new GPIO binding that contains both the polarity and the desired
default value.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-16 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <5375A8A8.7080306@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> On 15/05/14 21:21, Tony Lindgren wrote:
>
> >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> >> alternative for the compatible-string conversion we do now. I guess it's
> >> a matter of taste, but I rather hide it inside the kernel, in an
> >> internal omapdss file, than pollute the .dts files with those compatible
> >> strings.
> >
> > Well it avoid you parsing through all the nodes during booting
> > and leaves out the function to do remapping. And removes the need
> > for maintaining a custom display mapping table. I'd say that's a
> > pretty good list of advantages right there :)
>
> Yep... I don't know. Maybe I'm being too careful about doing wrong
> things with .dts. I just like it more if any hacks are in kernel code,
> which I can remove without anyone noticing.
>
> Anyway, we already have board.dts files using the non-omapified
> compatible strings in the mainline, so if I would now add the omapified
> compatible strings to .dts files, those old board.dts files would break.
>
> So I guess the choice has already been made.
I really think you should remove this misuse of device tree code ASAP.
It's better to fix it up now than carry the hack for next two years
and keep on adding to it.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 0/4] OMAPDSS: sharp-ls037v7dw01 DT support
From: Tony Lindgren @ 2014-05-16 16:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1400225402-18274-1-git-send-email-tomi.valkeinen@ti.com>
* Tomi Valkeinen <tomi.valkeinen@ti.com> [140516 00:31]:
> Hi,
>
> These are slightly reworked versions of the patches Tony sent:
>
> * Split the DT doc into separate patch
> * Handle errors from gpio functions
> * Remove QVGA support
> * Removed the change to arch/arm/mach-omap2/display.c. I'll add that to my
> patch which moves the conversion code to omapdss. Note that if you test this
> version, you need to add the panel name to the conversion list for now.
> * Set MO gpio GPIO_ACTIVE_HIGH in omap3-evm-common.dtsi
> * Set the GPIO default values the same way for DT and non-DT versions.
>
> Tony, I removed the QVGA support as it was a new feature, not supported by the
> non-DT version. Also, I don't think it should be done as you had implemented
> it, but rather either have a flag in the DT data in case the pin is hardwired
> in the hardware, or let the user select the mode at runtime.
OK. Probably should have both options eventually.
> Also, I didn't quite understand the implementation. You had set initial values
> in the driver for MO and RESB differently than on the non-DT version. Was that
> on purpose?
I just configured things to what we had earlier for the legacy booting,
QVGA for ldp and VGA for omap3-evm.
> You said in a comment: "The LCD is sideways, so we want the VGA mode instead of
> QVGA mode.". Why is that? How does the resolution affect the orientation?
Yeah that's pretty confusing and probably written before I got the
image working properly. I probably initially thought the VGA mode also
switches the panel to 640x480, while it really sets it to 480x640.
> With my version, the panel (should) always be in VGA mode, like the non-DT
> version does.
>
> Only compile tested, I don't have boards with the panel.
Works for me on omap3-evm and ldp after patching in the mode to your
panel compatible translation database system.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Sebastian Reichel @ 2014-05-16 17:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516160717.GD22031@atomide.com>
[-- Attachment #1: Type: text/plain, Size: 2069 bytes --]
On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > On 15/05/14 21:21, Tony Lindgren wrote:
> > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > >> alternative for the compatible-string conversion we do now. I guess it's
> > >> a matter of taste, but I rather hide it inside the kernel, in an
> > >> internal omapdss file, than pollute the .dts files with those compatible
> > >> strings.
> > >
> > > Well it avoid you parsing through all the nodes during booting
> > > and leaves out the function to do remapping. And removes the need
> > > for maintaining a custom display mapping table. I'd say that's a
> > > pretty good list of advantages right there :)
> >
> > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > things with .dts. I just like it more if any hacks are in kernel code,
> > which I can remove without anyone noticing.
> >
> > Anyway, we already have board.dts files using the non-omapified
> > compatible strings in the mainline, so if I would now add the omapified
> > compatible strings to .dts files, those old board.dts files would break.
> >
> > So I guess the choice has already been made.
>
> I really think you should remove this misuse of device tree code ASAP.
> It's better to fix it up now than carry the hack for next two years
> and keep on adding to it.
IMHO appending -omap-dss to a random device is an even bigger hack,
since its adding lots of bloat to the API. Let's assume there is
another OS using DT for ARM, but has no proper API for SPI
controllers and it introduces your hack to SPI devices. That would
mean each SPI device has -omap-spi appended (or -exynos-spi,
-foo-spi, ...). At least I would blame them for creating a huge
unmaintainable mess.
I think Tomi's workaround is a much better hack, since it keeps the
API clean. If the code simply prefixes "omapdss," to all
"child"-devices of omapdss it can be left mostly untouched, too.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-16 18:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516174158.GA11733@earth.universe>
* Sebastian Reichel <sre@ring0.de> [140516 10:42]:
> On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > > On 15/05/14 21:21, Tony Lindgren wrote:
> > > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > > >> alternative for the compatible-string conversion we do now. I guess it's
> > > >> a matter of taste, but I rather hide it inside the kernel, in an
> > > >> internal omapdss file, than pollute the .dts files with those compatible
> > > >> strings.
> > > >
> > > > Well it avoid you parsing through all the nodes during booting
> > > > and leaves out the function to do remapping. And removes the need
> > > > for maintaining a custom display mapping table. I'd say that's a
> > > > pretty good list of advantages right there :)
> > >
> > > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > > things with .dts. I just like it more if any hacks are in kernel code,
> > > which I can remove without anyone noticing.
> > >
> > > Anyway, we already have board.dts files using the non-omapified
> > > compatible strings in the mainline, so if I would now add the omapified
> > > compatible strings to .dts files, those old board.dts files would break.
> > >
> > > So I guess the choice has already been made.
> >
> > I really think you should remove this misuse of device tree code ASAP.
> > It's better to fix it up now than carry the hack for next two years
> > and keep on adding to it.
>
> IMHO appending -omap-dss to a random device is an even bigger hack,
> since its adding lots of bloat to the API. Let's assume there is
> another OS using DT for ARM, but has no proper API for SPI
> controllers and it introduces your hack to SPI devices. That would
> mean each SPI device has -omap-spi appended (or -exynos-spi,
> -foo-spi, ...). At least I would blame them for creating a huge
> unmaintainable mess.
I think you're misunderstanding. I do not want the naming to
be Linux specific. The naming should naturally be as hardware
specific as possible. In this case something like:
compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
Or we should probably use:
compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
As dpi here reflects the hardware it's connected to. The dss
is probably a Linux name.
Not use what you're after with the SPI example though, but sounds
like that's something different.
> I think Tomi's workaround is a much better hack, since it keeps the
> API clean. If the code simply prefixes "omapdss," to all
> "child"-devices of omapdss it can be left mostly untouched, too.
AFAIK that remapping not needed at all. All that is already
available with the compatible flags.
Regards,
Tony
^ permalink raw reply
* Re: [PATCH 3/4] OMAPDSS: panel-sharp-ls037v7dw01: add device tree support
From: Tony Lindgren @ 2014-05-16 21:39 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20140516180154.GG22031@atomide.com>
* Tony Lindgren <tony@atomide.com> [140516 11:02]:
> * Sebastian Reichel <sre@ring0.de> [140516 10:42]:
> > On Fri, May 16, 2014 at 09:07:17AM -0700, Tony Lindgren wrote:
> > > * Tomi Valkeinen <tomi.valkeinen@ti.com> [140515 22:57]:
> > > > On 15/05/14 21:21, Tony Lindgren wrote:
> > > > >> But you're right, having "sharp,ls037v7dw01-omap-dss" in the .dts is an
> > > > >> alternative for the compatible-string conversion we do now. I guess it's
> > > > >> a matter of taste, but I rather hide it inside the kernel, in an
> > > > >> internal omapdss file, than pollute the .dts files with those compatible
> > > > >> strings.
> > > > >
> > > > > Well it avoid you parsing through all the nodes during booting
> > > > > and leaves out the function to do remapping. And removes the need
> > > > > for maintaining a custom display mapping table. I'd say that's a
> > > > > pretty good list of advantages right there :)
> > > >
> > > > Yep... I don't know. Maybe I'm being too careful about doing wrong
> > > > things with .dts. I just like it more if any hacks are in kernel code,
> > > > which I can remove without anyone noticing.
> > > >
> > > > Anyway, we already have board.dts files using the non-omapified
> > > > compatible strings in the mainline, so if I would now add the omapified
> > > > compatible strings to .dts files, those old board.dts files would break.
> > > >
> > > > So I guess the choice has already been made.
> > >
> > > I really think you should remove this misuse of device tree code ASAP.
> > > It's better to fix it up now than carry the hack for next two years
> > > and keep on adding to it.
> >
> > IMHO appending -omap-dss to a random device is an even bigger hack,
> > since its adding lots of bloat to the API. Let's assume there is
> > another OS using DT for ARM, but has no proper API for SPI
> > controllers and it introduces your hack to SPI devices. That would
> > mean each SPI device has -omap-spi appended (or -exynos-spi,
> > -foo-spi, ...). At least I would blame them for creating a huge
> > unmaintainable mess.
>
> I think you're misunderstanding. I do not want the naming to
> be Linux specific. The naming should naturally be as hardware
> specific as possible. In this case something like:
>
> compatible = "sharp,ls037v7dw01-dss", "sharp,ls037v7dw01";
>
> Or we should probably use:
>
> compatible = "sharp,ls037v7dw01-dpi", "sharp,ls037v7dw01";
>
> As dpi here reflects the hardware it's connected to. The dss
> is probably a Linux name.
>
> Not use what you're after with the SPI example though, but sounds
> like that's something different.
>
> > I think Tomi's workaround is a much better hack, since it keeps the
> > API clean. If the code simply prefixes "omapdss," to all
> > "child"-devices of omapdss it can be left mostly untouched, too.
>
> AFAIK that remapping not needed at all. All that is already
> available with the compatible flags.
And alternatively we can also just use the sharp,ls037v7dw01
in the panel driver(s). We can have the panels bail out in driver
probe based on of_machine_is_compatible if nothing else is available.
Also, currently the remapping code also probably keeps prepending
more and more omapdss,omapdss,omapdss,... on each kexec reboot? And
it would be quite silly for each display controller to have to do
their own remapping for shared panels?
If we still still despite all these reasons decide to go with
the remapping of the compatible strings, it should really be a
Linux generic (or drivers/video generic function), not implemented
for each display controller.
Cheers,
Tony
^ permalink raw reply
* [PATCH 2/8] radeonfb: Out of line errata workarounds
From: Andi Kleen @ 2014-05-16 21:43 UTC (permalink / raw)
To: linux-kernel; +Cc: akpm, Andi Kleen, Benjamin Herrenschmidt, linux-fbdev
In-Reply-To: <1400276595-6965-1-git-send-email-andi@firstfloor.org>
From: Andi Kleen <ak@linux.intel.com>
Out of lining _radeon_msleep and radeon_pll_errata_* saves about 40k text.
14193673 2003976 1507328 17704977 10e2811 vmlinux-before-radeon
14152713 2003976 1507328 17664017 10d8811 vmlinux-radeon
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: linux-fbdev@vger.kernel.org
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
drivers/video/fbdev/aty/radeon_base.c | 57 ++++++++++++++++++++++++++++++++++
drivers/video/fbdev/aty/radeonfb.h | 58 ++---------------------------------
2 files changed, 60 insertions(+), 55 deletions(-)
diff --git a/drivers/video/fbdev/aty/radeon_base.c b/drivers/video/fbdev/aty/radeon_base.c
index 26d80a4..abd89a9 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -282,6 +282,63 @@ static int backlight = 1;
static int backlight = 0;
#endif
+/* Note about this function: we have some rare cases where we must not schedule,
+ * this typically happen with our special "wake up early" hook which allows us to
+ * wake up the graphic chip (and thus get the console back) before everything else
+ * on some machines that support that mechanism. At this point, interrupts are off
+ * and scheduling is not permitted
+ */
+void _radeon_msleep(struct radeonfb_info *rinfo, unsigned long ms)
+{
+ if (rinfo->no_schedule || oops_in_progress)
+ mdelay(ms);
+ else
+ msleep(ms);
+}
+
+/*
+ * Note about PLL register accesses:
+ *
+ * I have removed the spinlock on them on purpose. The driver now
+ * expects that it will only manipulate the PLL registers in normal
+ * task environment, where radeon_msleep() will be called, protected
+ * by a semaphore (currently the console semaphore) so that no conflict
+ * will happen on the PLL register index.
+ *
+ * With the latest changes to the VT layer, this is guaranteed for all
+ * calls except the actual drawing/blits which aren't supposed to use
+ * the PLL registers anyway
+ *
+ * This is very important for the workarounds to work properly. The only
+ * possible exception to this rule is the call to unblank(), which may
+ * be done at irq time if an oops is in progress.
+ */
+void radeon_pll_errata_after_index(struct radeonfb_info *rinfo)
+{
+ if (!(rinfo->errata & CHIP_ERRATA_PLL_DUMMYREADS))
+ return;
+
+ (void)INREG(CLOCK_CNTL_DATA);
+ (void)INREG(CRTC_GEN_CNTL);
+}
+
+void radeon_pll_errata_after_data(struct radeonfb_info *rinfo)
+{
+ if (rinfo->errata & CHIP_ERRATA_PLL_DELAY) {
+ /* we can't deal with posted writes here ... */
+ _radeon_msleep(rinfo, 5);
+ }
+ if (rinfo->errata & CHIP_ERRATA_R300_CG) {
+ u32 save, tmp;
+ save = INREG(CLOCK_CNTL_INDEX);
+ tmp = save & ~(0x3f | PLL_WR_EN);
+ OUTREG(CLOCK_CNTL_INDEX, tmp);
+ tmp = INREG(CLOCK_CNTL_DATA);
+ OUTREG(CLOCK_CNTL_INDEX, save);
+ }
+}
+
+
/*
* prototypes
*/
diff --git a/drivers/video/fbdev/aty/radeonfb.h b/drivers/video/fbdev/aty/radeonfb.h
index cb84604..bb73446 100644
--- a/drivers/video/fbdev/aty/radeonfb.h
+++ b/drivers/video/fbdev/aty/radeonfb.h
@@ -370,20 +370,7 @@ struct radeonfb_info {
* IO macros
*/
-/* Note about this function: we have some rare cases where we must not schedule,
- * this typically happen with our special "wake up early" hook which allows us to
- * wake up the graphic chip (and thus get the console back) before everything else
- * on some machines that support that mechanism. At this point, interrupts are off
- * and scheduling is not permitted
- */
-static inline void _radeon_msleep(struct radeonfb_info *rinfo, unsigned long ms)
-{
- if (rinfo->no_schedule || oops_in_progress)
- mdelay(ms);
- else
- msleep(ms);
-}
-
+void _radeon_msleep(struct radeonfb_info *rinfo, unsigned long ms);
#define INREG8(addr) readb((rinfo->mmio_base)+addr)
#define OUTREG8(addr,val) writeb(val, (rinfo->mmio_base)+addr)
@@ -408,47 +395,8 @@ static inline void _OUTREGP(struct radeonfb_info *rinfo, u32 addr,
#define OUTREGP(addr,val,mask) _OUTREGP(rinfo, addr, val,mask)
-/*
- * Note about PLL register accesses:
- *
- * I have removed the spinlock on them on purpose. The driver now
- * expects that it will only manipulate the PLL registers in normal
- * task environment, where radeon_msleep() will be called, protected
- * by a semaphore (currently the console semaphore) so that no conflict
- * will happen on the PLL register index.
- *
- * With the latest changes to the VT layer, this is guaranteed for all
- * calls except the actual drawing/blits which aren't supposed to use
- * the PLL registers anyway
- *
- * This is very important for the workarounds to work properly. The only
- * possible exception to this rule is the call to unblank(), which may
- * be done at irq time if an oops is in progress.
- */
-static inline void radeon_pll_errata_after_index(struct radeonfb_info *rinfo)
-{
- if (!(rinfo->errata & CHIP_ERRATA_PLL_DUMMYREADS))
- return;
-
- (void)INREG(CLOCK_CNTL_DATA);
- (void)INREG(CRTC_GEN_CNTL);
-}
-
-static inline void radeon_pll_errata_after_data(struct radeonfb_info *rinfo)
-{
- if (rinfo->errata & CHIP_ERRATA_PLL_DELAY) {
- /* we can't deal with posted writes here ... */
- _radeon_msleep(rinfo, 5);
- }
- if (rinfo->errata & CHIP_ERRATA_R300_CG) {
- u32 save, tmp;
- save = INREG(CLOCK_CNTL_INDEX);
- tmp = save & ~(0x3f | PLL_WR_EN);
- OUTREG(CLOCK_CNTL_INDEX, tmp);
- tmp = INREG(CLOCK_CNTL_DATA);
- OUTREG(CLOCK_CNTL_INDEX, save);
- }
-}
+void radeon_pll_errata_after_index(struct radeonfb_info *rinfo);
+void radeon_pll_errata_after_data(struct radeonfb_info *rinfo);
static inline u32 __INPLL(struct radeonfb_info *rinfo, u32 addr)
{
--
1.9.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] video: clps711x: Add new Cirrus Logic CLPS711X framebuffer driver
From: Olof Johansson @ 2014-05-16 22:56 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1397285583-15187-1-git-send-email-shc_work@mail.ru>
On Thu, May 08, 2014 at 01:14:40PM +0300, Tomi Valkeinen wrote:
> On 08/05/14 11:27, Alexander Shiyan wrote:
>
> >>> At this time the driver has three user.
> >>> Only one of them should theoretically work.
> >>> clps711x-autcpu12 should not work in the absence of memblock_reserve().
> >>> clps711x-p720t should not work due to physical address limitation as i
> >>> noticed before. Board means to use SRAM instead of SDRAM.
> >>> Only clps711x-edb7211 should work fine (in theory).
> >>> Is this a good reason to replace the driver? I think yes.
> >>
> >> Ok, if the situation is that bad, maybe we can just switch to the new
> >> driver. Have you verified that those boards do not work from anyone? Or
> >> asked someone to test the new driver with those boards?
> >
> > I'm not familiar with other users of this platform .
> > I am do not have these boards, all that I have written before that it's just a theory.
> > Firm in which I work, uses its own board with CLPS711X CPU , this board is the
> > only way to check for changes on real hardware .
>
> Ok. That makes me a bit nervous... You're removing a driver, which may
> (or may not) have been working for other users. And adding a new one,
> which may not (or may) work for the other users.
Keep the old one around under another Kconfig name, mark it BROKEN,
and if nobody speaks up in a couple of releases, remove it?
> >> I'm still not really happy about it, and I'd much rather see the current
> >> driver fixed. But if no one having those boards is up to the task
> >> (probably not if they have not been working at all), maybe just ditching
> >> the old driver and adding a new is the only way forward.
> >>
> >> One change that I think would be good is to change the series to first
> >> remove the old driver, and then add the new one, with the same file name
> >> as the old one. That way git log will show the history for both the new
> >> and the old driver.
> >
> > In this case git-bisect will be broken. Is this OK?
>
> I think this is such a big change for the users of the driver that it's
> not an issue. Of course, kernel should still build at all steps, but I
> think it's fine if the fb driver in question will be out for a commit or
> two.
Agreed.
-Olof
^ permalink raw reply
* [PATCH 2/2] video: delete unneeded call to platform_get_drvdata
From: Julia Lawall @ 2014-05-17 6:32 UTC (permalink / raw)
To: Jean-Christophe Plagniol-Villard
Cc: kernel-janitors, Tomi Valkeinen, linux-fbdev, linux-kernel
From: Julia Lawall <Julia.Lawall@lip6.fr>
Platform_get_drvdata is an accessor function, and has no purpose if its
result is not used.
The semantic patch that fixes this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
identifier x;
type T;
@@
- T x = platform_get_drvdata(...);
... when != x
// </smpl>
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
---
drivers/video/fbdev/bf54x-lq043fb.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/video/fbdev/bf54x-lq043fb.c b/drivers/video/fbdev/bf54x-lq043fb.c
index e2c42ad..adbef54 100644
--- a/drivers/video/fbdev/bf54x-lq043fb.c
+++ b/drivers/video/fbdev/bf54x-lq043fb.c
@@ -717,8 +717,6 @@ static int bfin_bf54x_remove(struct platform_device *pdev)
#ifdef CONFIG_PM
static int bfin_bf54x_suspend(struct platform_device *pdev, pm_message_t state)
{
- struct fb_info *fbinfo = platform_get_drvdata(pdev);
-
bfin_write_EPPI0_CONTROL(bfin_read_EPPI0_CONTROL() & ~EPPI_EN);
disable_dma(CH_EPPI0);
bfin_write_EPPI0_STATUS(0xFFFF);
^ permalink raw reply related
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Joachim Eastwood @ 2014-05-17 8:51 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <CAGhQ9VzkGDPiQF7TiqiMgZY_oc9dyrW66yGsZR6ei2ejX-EXcw@mail.gmail.com>
On 14 May 2014 18:25, Joachim Eastwood <manabian@gmail.com> wrote:
> On 14 May 2014 12:02, Jyri Sarha <jsarha@ti.com> wrote:
>> On 05/13/2014 12:13 AM, Joachim Eastwood wrote:
>>>
>>> On 12 May 2014 11:12, Jyri Sarha <jsarha@ti.com> wrote:
>>
>> ...
>>
>>>
>>> hey, this worked straight away :)
>>>
>>> But there seems to be something wrong with the channel mapping.
>>>
>>> For stereo (speaker-test -c 2) the mapping is correct.
>>>
>>> But for -c 4 and -c 8 it gets weird:
>>> speaker-test -c 4 -s X # where X is 1-4
>>> 1: Front Left is Rear Left
>>> 2: Front Right is Rear Right
>>> 3: Rear Right is Front Right
>>> 4: Rear Left is Front Left
>>>
>>> speaker-test -c 8 -s X # where X is 1-8
>>> 1: Front Left is Rear Left
>>> 2: Center is Rear Left
>>> 3: Front Right is Rear Right
>>> 4: Side Right is Front Right
>>> 5: Rear Right is silent
>>> 6: Rear Left is Center
>>> 7: Side Left is Front Left
>>> 8: LFE - Rear Right
>>>
>>> I think you need to check what channel order ALSA expects. I believe
>>> speaker-test does the right thing on my HTPC normally connected to my
>>> receiver.
>>>
>>
>> I checked the implementation and there was indeed something weird there, but
>> the implementation can not explain the FL and FR channels jumping around. FL
>> and FL should always be the first two channels in all configurations and the
>> implementation does not touch them.
>>
>> The implementation uses 8ch HDMI setup for anything above 2ch with "Audio
>> InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs this means
>> following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC
>>
>> This is a closest match to ALSA 8ch mapping (according to
>> sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR
>
> hm, okey. I haven't look at the code but it do seem strange. But with
> speaker-test -c 4 the front and back are surely swapped here.
>
> I'll do some more testing and also check with my HTPC. btw, I only
> have a 5.1 setup over here so I can't test all the discrete channels.
>
>> Current implementation has FLE and FC channels correctly swapped, but it
>> shifts them to last two channels and RL, RR, SL, SR are shifted down to fill
>> the place. This is all wrong and I'll try to come up with a fix for that.
>> Unfortunately I can not test anything beyond 2 ch myself so I would need
>> someone to volunteer to test my patch.
>
> I have the dev kit setup up over here so I can test your patches.
I did some more testing over here.
My HTPC (nVidia ION2 based) works good with speaker-test and all
channels are where they are suppose to be.
On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s
1; done" and this had an interesting effect.
Most of the time FL (Front Left) is swapped with BL (Back Left) but
about every 10th time the sound comes out in the FL speaker... So
there something weird going on here. Same story for the right channel.
I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:
[ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
[ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open
interface 58006000.encoder: -19
But after replugging the HDMI connector a couple of times it starts to work.
I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [alsa-devel] [PATCH 00/19] Rework OMAP4+ HDMI audio support
From: Joachim Eastwood @ 2014-05-17 9:16 UTC (permalink / raw)
To: Jyri Sarha
Cc: alsa-devel, linux-fbdev, devicetree, linux-omap, liam.r.girdwood,
detheridge, broonie, peter.ujfalusi, Tomi Valkeinen,
Benoit Cousson
In-Reply-To: <CAGhQ9VwY_qeOLsa_oAUuL3XT2tmn-mLg0WBtOdL8JL6u+0PQcw@mail.gmail.com>
On 17 May 2014 10:51, Joachim Eastwood <manabian@gmail.com> wrote:
> On 14 May 2014 18:25, Joachim Eastwood <manabian@gmail.com> wrote:
>> On 14 May 2014 12:02, Jyri Sarha <jsarha@ti.com> wrote:
>>> On 05/13/2014 12:13 AM, Joachim Eastwood wrote:
>>>>
>>>> On 12 May 2014 11:12, Jyri Sarha <jsarha@ti.com> wrote:
>>>
>>> ...
>>>
>>>>
>>>> hey, this worked straight away :)
>>>>
>>>> But there seems to be something wrong with the channel mapping.
>>>>
>>>> For stereo (speaker-test -c 2) the mapping is correct.
>>>>
>>>> But for -c 4 and -c 8 it gets weird:
>>>> speaker-test -c 4 -s X # where X is 1-4
>>>> 1: Front Left is Rear Left
>>>> 2: Front Right is Rear Right
>>>> 3: Rear Right is Front Right
>>>> 4: Rear Left is Front Left
>>>>
>>>> speaker-test -c 8 -s X # where X is 1-8
>>>> 1: Front Left is Rear Left
>>>> 2: Center is Rear Left
>>>> 3: Front Right is Rear Right
>>>> 4: Side Right is Front Right
>>>> 5: Rear Right is silent
>>>> 6: Rear Left is Center
>>>> 7: Side Left is Front Left
>>>> 8: LFE - Rear Right
>>>>
>>>> I think you need to check what channel order ALSA expects. I believe
>>>> speaker-test does the right thing on my HTPC normally connected to my
>>>> receiver.
>>>>
>>>
>>> I checked the implementation and there was indeed something weird there, but
>>> the implementation can not explain the FL and FR channels jumping around. FL
>>> and FL should always be the first two channels in all configurations and the
>>> implementation does not touch them.
>>>
>>> The implementation uses 8ch HDMI setup for anything above 2ch with "Audio
>>> InfoFrame Data Byte 4" set to 0x13. According to CEA-861 specs this means
>>> following channel order: FL, FR, LFE, FC, RL, RR, RLC, RRC
>>>
>>> This is a closest match to ALSA 8ch mapping (according to
>>> sound/core/pcm_lib.c) which is: FL, FR, FC, LFE, RL, RR, SL, SR
>>
>> hm, okey. I haven't look at the code but it do seem strange. But with
>> speaker-test -c 4 the front and back are surely swapped here.
>>
>> I'll do some more testing and also check with my HTPC. btw, I only
>> have a 5.1 setup over here so I can't test all the discrete channels.
>>
>>> Current implementation has FLE and FC channels correctly swapped, but it
>>> shifts them to last two channels and RL, RR, SL, SR are shifted down to fill
>>> the place. This is all wrong and I'll try to come up with a fix for that.
>>> Unfortunately I can not test anything beyond 2 ch myself so I would need
>>> someone to volunteer to test my patch.
>>
>> I have the dev kit setup up over here so I can test your patches.
>
> I did some more testing over here.
>
> My HTPC (nVidia ION2 based) works good with speaker-test and all
> channels are where they are suppose to be.
>
> On the OMAP4 board I tried doing: "while true; do speaker-test -c 4 -s
> 1; done" and this had an interesting effect.
> Most of the time FL (Front Left) is swapped with BL (Back Left) but
> about every 10th time the sound comes out in the FL speaker... So
> there something weird going on here. Same story for the right channel.
>
> I also noticed that HDMI doesn't always work on boot up, it sometimes fail with:
> [ 193.985565] omapdss_hdmi 58006000.encoder: audio not supported
> [ 193.985565] omapdss_hdmi 58006000.encoder: ASoC: can't open
> interface 58006000.encoder: -19
>
> But after replugging the HDMI connector a couple of times it starts to work.
>
> I'll see if I can try with an old TI OMAP4 kernel (3.4) and see how that works.
On the 3.4 Variscite kernel:
Linux version 3.4.0-1489-omap4 (uri@pluto) (gcc version 4.6.3
(Ubuntu/Linaro 4.6.3-1ubuntu5) ) #27 SMP PREEMPT Sun Apr 7 13:27:10
IDT 2013
git://dev.omapzoom.org/pub/scm/integration/kernel-ubuntu.git +
Variscite vendor patches
Both speaker-test -c 4 and -c 8 works. All channels are where they are
suppose to be.
Hot plugging is broken, though. So the HDMI must be connected on boot,
but that might be the Variscite board setup.
regards
Joachim Eastwood
^ permalink raw reply
* Re: [PATCH v2 1/3] video: clps711x: Add new C =?UTF-8?B?aXJydXMgTG9naWMgQ
From: Alexander Shiyan @ 2014-05-18 12:01 UTC (permalink / raw)
To: linux-fbdev
In-Reply-To: <1398327006.501536964@f133.i.mail.ru>
RnJpLCAxNiBNYXkgMjAxNCAxNTo1NjoyNiAtMDcwMCDQvtGCIE9sb2YgSm9oYW5zc29uIDxvbG9m
QGxpeG9tLm5ldD46Cj4gT24gVGh1LCBNYXkgMDgsIDIwMTQgYXQgMDE6MTQ6NDBQTSArMDMwMCwg
VG9taSBWYWxrZWluZW4gd3JvdGU6Cj4gPiBPbiAwOC8wNS8xNCAxMToyNywgQWxleGFuZGVyIFNo
aXlhbiB3cm90ZToKPiA+IAo+ID4gPj4+IEF0IHRoaXMgdGltZSB0aGUgZHJpdmVyIGhhcyB0aHJl
ZSB1c2VyLgo+ID4gPj4+IE9ubHkgb25lIG9mIHRoZW0gc2hvdWxkIHRoZW9yZXRpY2FsbHkgd29y
ay4KPiA+ID4+PiBjbHBzNzExeC1hdXRjcHUxMiBzaG91bGQgbm90IHdvcmsgaW4gdGhlIGFic2Vu
Y2Ugb2YgbWVtYmxvY2tfcmVzZXJ2ZSgpLgo+ID4gPj4+IGNscHM3MTF4LXA3MjB0IHNob3VsZCBu
b3Qgd29yayBkdWUgdG8gcGh5c2ljYWwgYWRkcmVzcyBsaW1pdGF0aW9uIGFzIGkKPiA+ID4+PiBu
b3RpY2VkIGJlZm9yZS4gQm9hcmQgbWVhbnMgdG8gdXNlIFNSQU0gaW5zdGVhZCBvZiBTRFJBTS4K
PiA+ID4+PiBPbmx5IGNscHM3MTF4LWVkYjcyMTEgc2hvdWxkIHdvcmsgZmluZSAoaW4gdGhlb3J5
KS4KPiA+ID4+PiBJcyB0aGlzIGEgZ29vZCByZWFzb24gdG8gcmVwbGFjZSB0aGUgZHJpdmVyPyBJ
IHRoaW5rIHllcy4KPiA+ID4+Cj4gPiA+PiBPaywgaWYgdGhlIHNpdHVhdGlvbiBpcyB0aGF0IGJh
ZCwgbWF5YmUgd2UgY2FuIGp1c3Qgc3dpdGNoIHRvIHRoZSBuZXcKPiA+ID4+IGRyaXZlci4gSGF2
ZSB5b3UgdmVyaWZpZWQgdGhhdCB0aG9zZSBib2FyZHMgZG8gbm90IHdvcmsgZnJvbSBhbnlvbmU/
IE9yCj4gPiA+PiBhc2tlZCBzb21lb25lIHRvIHRlc3QgdGhlIG5ldyBkcml2ZXIgd2l0aCB0aG9z
ZSBib2FyZHM/Cj4gPiA+IAo+ID4gPiBJJ20gbm90IGZhbWlsaWFyIHdpdGggb3RoZXIgdXNlcnMg
b2YgdGhpcyBwbGF0Zm9ybSAuCj4gPiA+IEkgYW0gZG8gbm90IGhhdmUgdGhlc2UgYm9hcmRzLCBh
bGwgdGhhdCBJIGhhdmUgd3JpdHRlbiBiZWZvcmUgdGhhdCBpdCdzIGp1c3QgYSB0aGVvcnkuCj4g
PiA+IEZpcm0gaW4gd2hpY2ggSSB3b3JrLCB1c2VzIGl0cyBvd24gYm9hcmQgd2l0aCBDTFBTNzEx
WCBDUFUgLCB0aGlzIGJvYXJkIGlzIHRoZQo+ID4gPiBvbmx5IHdheSB0byBjaGVjayBmb3IgY2hh
bmdlcyBvbiByZWFsIGhhcmR3YXJlIC4KPiA+IAo+ID4gT2suIFRoYXQgbWFrZXMgbWUgYSBiaXQg
bmVydm91cy4uLiBZb3UncmUgcmVtb3ZpbmcgYSBkcml2ZXIsIHdoaWNoIG1heQo+ID4gKG9yIG1h
eSBub3QpIGhhdmUgYmVlbiB3b3JraW5nIGZvciBvdGhlciB1c2Vycy4gQW5kIGFkZGluZyBhIG5l
dyBvbmUsCj4gPiB3aGljaCBtYXkgbm90IChvciBtYXkpIHdvcmsgZm9yIHRoZSBvdGhlciB1c2Vy
cy4KPiAKPiBLZWVwIHRoZSBvbGQgb25lIGFyb3VuZCB1bmRlciBhbm90aGVyIEtjb25maWcgbmFt
ZSwgbWFyayBpdCBCUk9LRU4sCj4gYW5kIGlmIG5vYm9keSBzcGVha3MgdXAgaW4gYSBjb3VwbGUg
b2YgcmVsZWFzZXMsIHJlbW92ZSBpdD8KCkkgbGlrZSB0aGlzIHZhcmlhbnQsIFRvbWkgYXJlIHlv
dSBhZ3JlZSB3aXRoIHRoaXM/CgotLS0KCg=
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox