* [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen,
Laurent Pinchart, Stefan Roese, Sebastian Reichel, Robert Nelson,
Dr . H . Nikolaus Schaller, Marek Belisko
Hi,
Here's a new version for DT support to OMAP Display Subsystem. See
http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the
previous version, which contains thoughts about the related problems.
The major change in this version is the use of V4L2 and CDF style port/endpoint
style in the DT data. However, note that even if the DT data contains proper
port & endpoint data, the drivers only use the first endpoint. This is to
simplify the patches, as adding full support for the ports and endpoints to the
drivers will be a big task. This approach still works with more or less all the
boards, as the only cases where the simpler model is an issue are the boards
with multiple display devices connected to a single output.
Laurent, I'd appreciate if you could have a look at the .dts changes, to see if
there's anything that's clearly not CDF compatible.
The patches can also be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
A few notes:
- The DT data are added separately in the end of .dts files for clarity. In the
final version I will move them to appropriate places in the .dts files.
- No binding documentation. I will add them for the next version, if there are
no major changes needed. Hopefully the bindings are quite self-explanatory
for people with understanding of the hardware in question.
- The connectors' compatible strings are "ti,xxx". As there's nothing TI
specific there, I think I will rename them to be without "ti".
Tomi
Tomi Valkeinen (26):
OMAPDSS: rename display-sysfs 'name' entry
OMAPDSS: DSI: fix fifosize
ARM: OMAP: remove DSS DT hack
OMAPDSS: remove DT hacks for regulators
ARM: OMAP2+: add omapdss_init_of()
OMAPDSS: if dssdev->name=NULL, use alias
OMAPDSS: get dssdev->alias from DT alias
OMAPFB: clean up default display search
OMAPFB: search for default display with DT alias
OMAPDSS: add of helpers
OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC
OMAPDSS: Add DT support to DSI
ARM: omap3.dtsi: add omapdss information
ARM: omap4.dtsi: add omapdss information
ARM: omap4-panda.dts: add display information
ARM: omap4-sdp.dts: add display information
ARM: omap3-tobi.dts: add lcd (TEST)
ARM: omap3-beagle.dts: add display information
ARM: omap3-beagle-xm.dts: add display information
OMAPDSS: panel-dsi-cm: Add DT support
OMAPDSS: encoder-tfp410: Add DT support
OMAPDSS: connector-dvi: Add DT support
OMAPDSS: encoder-tpd12s015: Add DT support
OMAPDSS: hdmi-connector: Add DT support
OMAPDSS: panel-dpi: Add DT support
OMAPDSS: connector-analog-tv: Add DT support
arch/arm/boot/dts/omap3-beagle-xm.dts | 67 ++++++
arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++
arch/arm/boot/dts/omap3-tobi.dts | 40 ++++
arch/arm/boot/dts/omap3.dtsi | 43 ++++
arch/arm/boot/dts/omap4-panda-common.dtsi | 102 ++++++++
arch/arm/boot/dts/omap4-sdp.dts | 91 ++++++++
arch/arm/boot/dts/omap4.dtsi | 58 +++++
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/board-generic.c | 2 +
arch/arm/mach-omap2/common.h | 2 +
arch/arm/mach-omap2/display.c | 62 +++++
arch/arm/mach-omap2/dss-common.c | 259 ---------------------
arch/arm/mach-omap2/dss-common.h | 13 --
arch/arm/mach-omap2/pdata-quirks.c | 4 -
.../video/omap2/displays-new/connector-analog-tv.c | 66 +++++-
drivers/video/omap2/displays-new/connector-dvi.c | 43 ++++
drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++
drivers/video/omap2/displays-new/encoder-tfp410.c | 43 +++-
.../video/omap2/displays-new/encoder-tpd12s015.c | 56 +++++
drivers/video/omap2/displays-new/panel-dpi.c | 64 ++++-
drivers/video/omap2/displays-new/panel-dsi-cm.c | 65 +++++-
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dispc.c | 7 +
drivers/video/omap2/dss/display-sysfs.c | 4 +-
drivers/video/omap2/dss/display.c | 23 +-
drivers/video/omap2/dss/dpi.c | 50 ++++
drivers/video/omap2/dss/dsi.c | 166 +++++++++++--
drivers/video/omap2/dss/dss-of.c | 160 +++++++++++++
drivers/video/omap2/dss/dss.c | 10 +
drivers/video/omap2/dss/hdmi4.c | 10 +-
drivers/video/omap2/dss/venc.c | 34 +++
drivers/video/omap2/omapfb/omapfb-main.c | 67 ++++--
include/video/omapdss.h | 6 +
33 files changed, 1390 insertions(+), 328 deletions(-)
delete mode 100644 arch/arm/mach-omap2/dss-common.c
delete mode 100644 arch/arm/mach-omap2/dss-common.h
create mode 100644 drivers/video/omap2/dss/dss-of.c
--
1.8.3.2
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 01/26] OMAPDSS: rename display-sysfs 'name' entry
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
omapdss in compat mode creates some sysfs files into the device's sysfs
directory, including a 'name' file. This works fine for
platform_devices, but breaks with i2c or spi devices, as those already
have a 'name' file.
Fix this by renaming the omapdss's 'name' file to 'display_name'.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display-sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/display-sysfs.c b/drivers/video/omap2/dss/display-sysfs.c
index 21d7f77df702..f7b5f9561041 100644
--- a/drivers/video/omap2/dss/display-sysfs.c
+++ b/drivers/video/omap2/dss/display-sysfs.c
@@ -277,7 +277,7 @@ static ssize_t display_wss_store(struct device *dev,
return size;
}
-static DEVICE_ATTR(name, S_IRUGO, display_name_show, NULL);
+static DEVICE_ATTR(display_name, S_IRUGO, display_name_show, NULL);
static DEVICE_ATTR(enabled, S_IRUGO|S_IWUSR,
display_enabled_show, display_enabled_store);
static DEVICE_ATTR(tear_elim, S_IRUGO|S_IWUSR,
@@ -292,7 +292,7 @@ static DEVICE_ATTR(wss, S_IRUGO|S_IWUSR,
display_wss_show, display_wss_store);
static const struct attribute *display_sysfs_attrs[] = {
- &dev_attr_name.attr,
+ &dev_attr_display_name.attr,
&dev_attr_enabled.attr,
&dev_attr_tear_elim.attr,
&dev_attr_timings.attr,
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 01/26] OMAPDSS: rename display-sysfs 'name' entry
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
omapdss in compat mode creates some sysfs files into the device's sysfs
directory, including a 'name' file. This works fine for
platform_devices, but breaks with i2c or spi devices, as those already
have a 'name' file.
Fix this by renaming the omapdss's 'name' file to 'display_name'.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display-sysfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/display-sysfs.c b/drivers/video/omap2/dss/display-sysfs.c
index 21d7f77df702..f7b5f9561041 100644
--- a/drivers/video/omap2/dss/display-sysfs.c
+++ b/drivers/video/omap2/dss/display-sysfs.c
@@ -277,7 +277,7 @@ static ssize_t display_wss_store(struct device *dev,
return size;
}
-static DEVICE_ATTR(name, S_IRUGO, display_name_show, NULL);
+static DEVICE_ATTR(display_name, S_IRUGO, display_name_show, NULL);
static DEVICE_ATTR(enabled, S_IRUGO|S_IWUSR,
display_enabled_show, display_enabled_store);
static DEVICE_ATTR(tear_elim, S_IRUGO|S_IWUSR,
@@ -292,7 +292,7 @@ static DEVICE_ATTR(wss, S_IRUGO|S_IWUSR,
display_wss_show, display_wss_store);
static const struct attribute *display_sysfs_attrs[] = {
- &dev_attr_name.attr,
+ &dev_attr_display_name.attr,
&dev_attr_enabled.attr,
&dev_attr_tear_elim.attr,
&dev_attr_timings.attr,
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 02/26] OMAPDSS: DSI: fix fifosize
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
DSI has separate TX and RX fifos. However, the current code only has one
field where the fifo size is stored, and the code for both TX and RX
config write to the same field. This has not caused issues, as we've
been using the same fifo sizes.
Fix this bug by creating separate fields for TX and RX fifo sizes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6056b27cf73c..1cd3e47fd43f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -297,7 +297,8 @@ struct dsi_data {
struct {
enum dsi_vc_source source;
struct omap_dss_device *dssdev;
- enum fifo_size fifo_size;
+ enum fifo_size tx_fifo_size;
+ enum fifo_size rx_fifo_size;
int vc_id;
} vc[4];
@@ -2427,14 +2428,14 @@ static void dsi_config_tx_fifo(struct platform_device *dsidev,
int add = 0;
int i;
- dsi->vc[0].fifo_size = size1;
- dsi->vc[1].fifo_size = size2;
- dsi->vc[2].fifo_size = size3;
- dsi->vc[3].fifo_size = size4;
+ dsi->vc[0].tx_fifo_size = size1;
+ dsi->vc[1].tx_fifo_size = size2;
+ dsi->vc[2].tx_fifo_size = size3;
+ dsi->vc[3].tx_fifo_size = size4;
for (i = 0; i < 4; i++) {
u8 v;
- int size = dsi->vc[i].fifo_size;
+ int size = dsi->vc[i].tx_fifo_size;
if (add + size > 4) {
DSSERR("Illegal FIFO configuration\n");
@@ -2460,14 +2461,14 @@ static void dsi_config_rx_fifo(struct platform_device *dsidev,
int add = 0;
int i;
- dsi->vc[0].fifo_size = size1;
- dsi->vc[1].fifo_size = size2;
- dsi->vc[2].fifo_size = size3;
- dsi->vc[3].fifo_size = size4;
+ dsi->vc[0].rx_fifo_size = size1;
+ dsi->vc[1].rx_fifo_size = size2;
+ dsi->vc[2].rx_fifo_size = size3;
+ dsi->vc[3].rx_fifo_size = size4;
for (i = 0; i < 4; i++) {
u8 v;
- int size = dsi->vc[i].fifo_size;
+ int size = dsi->vc[i].rx_fifo_size;
if (add + size > 4) {
DSSERR("Illegal FIFO configuration\n");
@@ -2920,7 +2921,7 @@ static int dsi_vc_send_long(struct platform_device *dsidev, int channel,
DSSDBG("dsi_vc_send_long, %d bytes\n", len);
/* len + header */
- if (dsi->vc[channel].fifo_size * 32 * 4 < len + 4) {
+ if (dsi->vc[channel].tx_fifo_size * 32 * 4 < len + 4) {
DSSERR("unable to send long packet: packet too long.\n");
return -EINVAL;
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 02/26] OMAPDSS: DSI: fix fifosize
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
DSI has separate TX and RX fifos. However, the current code only has one
field where the fifo size is stored, and the code for both TX and RX
config write to the same field. This has not caused issues, as we've
been using the same fifo sizes.
Fix this bug by creating separate fields for TX and RX fifo sizes.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 25 +++++++++++++------------
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 6056b27cf73c..1cd3e47fd43f 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -297,7 +297,8 @@ struct dsi_data {
struct {
enum dsi_vc_source source;
struct omap_dss_device *dssdev;
- enum fifo_size fifo_size;
+ enum fifo_size tx_fifo_size;
+ enum fifo_size rx_fifo_size;
int vc_id;
} vc[4];
@@ -2427,14 +2428,14 @@ static void dsi_config_tx_fifo(struct platform_device *dsidev,
int add = 0;
int i;
- dsi->vc[0].fifo_size = size1;
- dsi->vc[1].fifo_size = size2;
- dsi->vc[2].fifo_size = size3;
- dsi->vc[3].fifo_size = size4;
+ dsi->vc[0].tx_fifo_size = size1;
+ dsi->vc[1].tx_fifo_size = size2;
+ dsi->vc[2].tx_fifo_size = size3;
+ dsi->vc[3].tx_fifo_size = size4;
for (i = 0; i < 4; i++) {
u8 v;
- int size = dsi->vc[i].fifo_size;
+ int size = dsi->vc[i].tx_fifo_size;
if (add + size > 4) {
DSSERR("Illegal FIFO configuration\n");
@@ -2460,14 +2461,14 @@ static void dsi_config_rx_fifo(struct platform_device *dsidev,
int add = 0;
int i;
- dsi->vc[0].fifo_size = size1;
- dsi->vc[1].fifo_size = size2;
- dsi->vc[2].fifo_size = size3;
- dsi->vc[3].fifo_size = size4;
+ dsi->vc[0].rx_fifo_size = size1;
+ dsi->vc[1].rx_fifo_size = size2;
+ dsi->vc[2].rx_fifo_size = size3;
+ dsi->vc[3].rx_fifo_size = size4;
for (i = 0; i < 4; i++) {
u8 v;
- int size = dsi->vc[i].fifo_size;
+ int size = dsi->vc[i].rx_fifo_size;
if (add + size > 4) {
DSSERR("Illegal FIFO configuration\n");
@@ -2920,7 +2921,7 @@ static int dsi_vc_send_long(struct platform_device *dsidev, int channel,
DSSDBG("dsi_vc_send_long, %d bytes\n", len);
/* len + header */
- if (dsi->vc[channel].fifo_size * 32 * 4 < len + 4) {
+ if (dsi->vc[channel].tx_fifo_size * 32 * 4 < len + 4) {
DSSERR("unable to send long packet: packet too long.\n");
return -EINVAL;
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 03/26] ARM: OMAP: remove DSS DT hack
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
As a temporary solution to enable DSS for selected boards when booting
with DT, a hack was added to board-generic.c in
63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
DSS for panda & sdp boards).
We're now adding proper DT support, so the hack can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/dss-common.c | 259 -------------------------------------
arch/arm/mach-omap2/dss-common.h | 13 --
arch/arm/mach-omap2/pdata-quirks.c | 4 -
4 files changed, 1 insertion(+), 277 deletions(-)
delete mode 100644 arch/arm/mach-omap2/dss-common.c
delete mode 100644 arch/arm/mach-omap2/dss-common.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1f25f3e99c05..5b6456d1d266 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -296,4 +296,4 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
-obj-y += common-board-devices.o twl-common.o dss-common.o
+obj-y += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
deleted file mode 100644
index 365bfd3d9c68..000000000000
--- a/arch/arm/mach-omap2/dss-common.c
+++ /dev/null
@@ -1,259 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments, Inc..
- * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-/*
- * NOTE: this is a transitional file to help with DT adaptation.
- * This file will be removed when DSS supports DT.
- */
-
-#include <linux/kernel.h>
-#include <linux/gpio.h>
-#include <linux/platform_device.h>
-
-#include <video/omapdss.h>
-#include <video/omap-panel-data.h>
-
-#include "soc.h"
-#include "dss-common.h"
-#include "mux.h"
-
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
-
-#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap4_panda_dvi_connector_pdata = {
- .name = "dvi",
- .source = "tfp410.0",
- .i2c_bus_num = 2,
-};
-
-static struct platform_device omap4_panda_dvi_connector_device = {
- .name = "connector-dvi",
- .id = 0,
- .dev.platform_data = &omap4_panda_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap4_panda_tfp410_pdata = {
- .name = "tfp410.0",
- .source = "dpi.0",
- .data_lines = 24,
- .power_down_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap4_panda_tfp410_device = {
- .name = "tfp410",
- .id = 0,
- .dev.platform_data = &omap4_panda_tfp410_pdata,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data omap4_panda_hdmi_connector_pdata = {
- .name = "hdmi",
- .source = "tpd12s015.0",
-};
-
-static struct platform_device omap4_panda_hdmi_connector_device = {
- .name = "connector-hdmi",
- .id = 0,
- .dev.platform_data = &omap4_panda_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection & level shifter chip */
-static struct encoder_tpd12s015_platform_data omap4_panda_tpd_pdata = {
- .name = "tpd12s015.0",
- .source = "hdmi.0",
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device omap4_panda_tpd_device = {
- .name = "tpd12s015",
- .id = 0,
- .dev.platform_data = &omap4_panda_tpd_pdata,
-};
-
-static struct omap_dss_board_info omap4_panda_dss_data = {
- .default_display_name = "dvi",
-};
-
-void __init omap4_panda_display_init_of(void)
-{
- omap_display_init(&omap4_panda_dss_data);
-
- platform_device_register(&omap4_panda_tfp410_device);
- platform_device_register(&omap4_panda_dvi_connector_device);
-
- platform_device_register(&omap4_panda_tpd_device);
- platform_device_register(&omap4_panda_hdmi_connector_device);
-}
-
-
-/* OMAP4 Blaze display data */
-
-#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO 40
-
-static struct panel_dsicm_platform_data dsi1_panel = {
- .name = "lcd",
- .source = "dsi.0",
- .reset_gpio = 102,
- .use_ext_te = false,
- .ext_te_gpio = 101,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct platform_device sdp4430_lcd_device = {
- .name = "panel-dsi-cm",
- .id = 0,
- .dev.platform_data = &dsi1_panel,
-};
-
-static struct panel_dsicm_platform_data dsi2_panel = {
- .name = "lcd2",
- .source = "dsi.1",
- .reset_gpio = 104,
- .use_ext_te = false,
- .ext_te_gpio = 103,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct platform_device sdp4430_lcd2_device = {
- .name = "panel-dsi-cm",
- .id = 1,
- .dev.platform_data = &dsi2_panel,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data sdp4430_hdmi_connector_pdata = {
- .name = "hdmi",
- .source = "tpd12s015.0",
-};
-
-static struct platform_device sdp4430_hdmi_connector_device = {
- .name = "connector-hdmi",
- .id = 0,
- .dev.platform_data = &sdp4430_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection & level shifter chip */
-static struct encoder_tpd12s015_platform_data sdp4430_tpd_pdata = {
- .name = "tpd12s015.0",
- .source = "hdmi.0",
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device sdp4430_tpd_device = {
- .name = "tpd12s015",
- .id = 0,
- .dev.platform_data = &sdp4430_tpd_pdata,
-};
-
-
-static struct omap_dss_board_info sdp4430_dss_data = {
- .default_display_name = "lcd",
-};
-
-/*
- * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
- * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
- * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
- * selected by default
- */
-void __init omap_4430sdp_display_init_of(void)
-{
- int r;
-
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- "display_sel");
- if (r)
- pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
- r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- "DLP POWER ON");
- if (r)
- pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
- omap_display_init(&sdp4430_dss_data);
-
- platform_device_register(&sdp4430_lcd_device);
- platform_device_register(&sdp4430_lcd2_device);
-
- platform_device_register(&sdp4430_tpd_device);
- platform_device_register(&sdp4430_hdmi_connector_device);
-}
-
-
-/* OMAP3 IGEPv2 data */
-
-#define IGEP2_DVI_TFP410_POWER_DOWN_GPIO 170
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap3_igep2_dvi_connector_pdata = {
- .name = "dvi",
- .source = "tfp410.0",
- .i2c_bus_num = 3,
-};
-
-static struct platform_device omap3_igep2_dvi_connector_device = {
- .name = "connector-dvi",
- .id = 0,
- .dev.platform_data = &omap3_igep2_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap3_igep2_tfp410_pdata = {
- .name = "tfp410.0",
- .source = "dpi.0",
- .data_lines = 24,
- .power_down_gpio = IGEP2_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap3_igep2_tfp410_device = {
- .name = "tfp410",
- .id = 0,
- .dev.platform_data = &omap3_igep2_tfp410_pdata,
-};
-
-static struct omap_dss_board_info igep2_dss_data = {
- .default_display_name = "dvi",
-};
-
-void __init omap3_igep2_display_init_of(void)
-{
- omap_display_init(&igep2_dss_data);
-
- platform_device_register(&omap3_igep2_tfp410_device);
- platform_device_register(&omap3_igep2_dvi_connector_device);
-}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
deleted file mode 100644
index a9becf0d5be8..000000000000
--- a/arch/arm/mach-omap2/dss-common.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __OMAP_DSS_COMMON__
-#define __OMAP_DSS_COMMON__
-
-/*
- * NOTE: this is a transitional file to help with DT adaptation.
- * This file will be removed when DSS supports DT.
- */
-
-void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init_of(void);
-void __init omap3_igep2_display_init_of(void);
-
-#endif
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 10c71450cf63..ff5b48eca778 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,7 +18,6 @@
#include "common.h"
#include "common-board-devices.h"
-#include "dss-common.h"
#include "control.h"
struct pdata_init {
@@ -80,7 +79,6 @@ static void __init hsmmc2_internal_input_clk(void)
static void __init omap3_igep0020_legacy_init(void)
{
- omap3_igep2_display_init_of();
}
static void __init omap3_evm_legacy_init(void)
@@ -97,14 +95,12 @@ static void __init omap3_zoom_legacy_init(void)
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
- omap_4430sdp_display_init_of();
legacy_init_wl12xx(WL12XX_REFCLOCK_26,
WL12XX_TCXOCLOCK_26, 53);
}
static void __init omap4_panda_legacy_init(void)
{
- omap4_panda_display_init_of();
legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 03/26] ARM: OMAP: remove DSS DT hack
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
As a temporary solution to enable DSS for selected boards when booting
with DT, a hack was added to board-generic.c in
63d5fc0c2f748e20f38a0a0ec1c8494bddf5c288 (OMAP: board-generic: enable
DSS for panda & sdp boards).
We're now adding proper DT support, so the hack can be removed.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/Makefile | 2 +-
arch/arm/mach-omap2/dss-common.c | 259 -------------------------------------
arch/arm/mach-omap2/dss-common.h | 13 --
arch/arm/mach-omap2/pdata-quirks.c | 4 -
4 files changed, 1 insertion(+), 277 deletions(-)
delete mode 100644 arch/arm/mach-omap2/dss-common.c
delete mode 100644 arch/arm/mach-omap2/dss-common.h
diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
index 1f25f3e99c05..5b6456d1d266 100644
--- a/arch/arm/mach-omap2/Makefile
+++ b/arch/arm/mach-omap2/Makefile
@@ -296,4 +296,4 @@ endif
emac-$(CONFIG_TI_DAVINCI_EMAC) := am35xx-emac.o
obj-y += $(emac-m) $(emac-y)
-obj-y += common-board-devices.o twl-common.o dss-common.o
+obj-y += common-board-devices.o twl-common.o
diff --git a/arch/arm/mach-omap2/dss-common.c b/arch/arm/mach-omap2/dss-common.c
deleted file mode 100644
index 365bfd3d9c68..000000000000
--- a/arch/arm/mach-omap2/dss-common.c
+++ /dev/null
@@ -1,259 +0,0 @@
-/*
- * Copyright (C) 2012 Texas Instruments, Inc..
- * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
- *
- * 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.
- *
- * This program is distributed in the hope that it will be useful, but
- * WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
- * General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
- * 02110-1301 USA
- *
- */
-
-/*
- * NOTE: this is a transitional file to help with DT adaptation.
- * This file will be removed when DSS supports DT.
- */
-
-#include <linux/kernel.h>
-#include <linux/gpio.h>
-#include <linux/platform_device.h>
-
-#include <video/omapdss.h>
-#include <video/omap-panel-data.h>
-
-#include "soc.h"
-#include "dss-common.h"
-#include "mux.h"
-
-#define HDMI_GPIO_CT_CP_HPD 60 /* HPD mode enable/disable */
-#define HDMI_GPIO_LS_OE 41 /* Level shifter for HDMI */
-#define HDMI_GPIO_HPD 63 /* Hotplug detect */
-
-#define PANDA_DVI_TFP410_POWER_DOWN_GPIO 0
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap4_panda_dvi_connector_pdata = {
- .name = "dvi",
- .source = "tfp410.0",
- .i2c_bus_num = 2,
-};
-
-static struct platform_device omap4_panda_dvi_connector_device = {
- .name = "connector-dvi",
- .id = 0,
- .dev.platform_data = &omap4_panda_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap4_panda_tfp410_pdata = {
- .name = "tfp410.0",
- .source = "dpi.0",
- .data_lines = 24,
- .power_down_gpio = PANDA_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap4_panda_tfp410_device = {
- .name = "tfp410",
- .id = 0,
- .dev.platform_data = &omap4_panda_tfp410_pdata,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data omap4_panda_hdmi_connector_pdata = {
- .name = "hdmi",
- .source = "tpd12s015.0",
-};
-
-static struct platform_device omap4_panda_hdmi_connector_device = {
- .name = "connector-hdmi",
- .id = 0,
- .dev.platform_data = &omap4_panda_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection & level shifter chip */
-static struct encoder_tpd12s015_platform_data omap4_panda_tpd_pdata = {
- .name = "tpd12s015.0",
- .source = "hdmi.0",
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device omap4_panda_tpd_device = {
- .name = "tpd12s015",
- .id = 0,
- .dev.platform_data = &omap4_panda_tpd_pdata,
-};
-
-static struct omap_dss_board_info omap4_panda_dss_data = {
- .default_display_name = "dvi",
-};
-
-void __init omap4_panda_display_init_of(void)
-{
- omap_display_init(&omap4_panda_dss_data);
-
- platform_device_register(&omap4_panda_tfp410_device);
- platform_device_register(&omap4_panda_dvi_connector_device);
-
- platform_device_register(&omap4_panda_tpd_device);
- platform_device_register(&omap4_panda_hdmi_connector_device);
-}
-
-
-/* OMAP4 Blaze display data */
-
-#define DISPLAY_SEL_GPIO 59 /* LCD2/PicoDLP switch */
-#define DLP_POWER_ON_GPIO 40
-
-static struct panel_dsicm_platform_data dsi1_panel = {
- .name = "lcd",
- .source = "dsi.0",
- .reset_gpio = 102,
- .use_ext_te = false,
- .ext_te_gpio = 101,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct platform_device sdp4430_lcd_device = {
- .name = "panel-dsi-cm",
- .id = 0,
- .dev.platform_data = &dsi1_panel,
-};
-
-static struct panel_dsicm_platform_data dsi2_panel = {
- .name = "lcd2",
- .source = "dsi.1",
- .reset_gpio = 104,
- .use_ext_te = false,
- .ext_te_gpio = 103,
- .pin_config = {
- .num_pins = 6,
- .pins = { 0, 1, 2, 3, 4, 5 },
- },
-};
-
-static struct platform_device sdp4430_lcd2_device = {
- .name = "panel-dsi-cm",
- .id = 1,
- .dev.platform_data = &dsi2_panel,
-};
-
-/* HDMI Connector */
-static struct connector_hdmi_platform_data sdp4430_hdmi_connector_pdata = {
- .name = "hdmi",
- .source = "tpd12s015.0",
-};
-
-static struct platform_device sdp4430_hdmi_connector_device = {
- .name = "connector-hdmi",
- .id = 0,
- .dev.platform_data = &sdp4430_hdmi_connector_pdata,
-};
-
-/* TPD12S015 HDMI ESD protection & level shifter chip */
-static struct encoder_tpd12s015_platform_data sdp4430_tpd_pdata = {
- .name = "tpd12s015.0",
- .source = "hdmi.0",
-
- .ct_cp_hpd_gpio = HDMI_GPIO_CT_CP_HPD,
- .ls_oe_gpio = HDMI_GPIO_LS_OE,
- .hpd_gpio = HDMI_GPIO_HPD,
-};
-
-static struct platform_device sdp4430_tpd_device = {
- .name = "tpd12s015",
- .id = 0,
- .dev.platform_data = &sdp4430_tpd_pdata,
-};
-
-
-static struct omap_dss_board_info sdp4430_dss_data = {
- .default_display_name = "lcd",
-};
-
-/*
- * we select LCD2 by default (instead of Pico DLP) by setting DISPLAY_SEL_GPIO.
- * Setting DLP_POWER_ON gpio enables the VDLP_2V5 VDLP_1V8 and VDLP_1V0 rails
- * used by picodlp on the 4430sdp platform. Keep this gpio disabled as LCD2 is
- * selected by default
- */
-void __init omap_4430sdp_display_init_of(void)
-{
- int r;
-
- r = gpio_request_one(DISPLAY_SEL_GPIO, GPIOF_OUT_INIT_HIGH,
- "display_sel");
- if (r)
- pr_err("%s: Could not get display_sel GPIO\n", __func__);
-
- r = gpio_request_one(DLP_POWER_ON_GPIO, GPIOF_OUT_INIT_LOW,
- "DLP POWER ON");
- if (r)
- pr_err("%s: Could not get DLP POWER ON GPIO\n", __func__);
-
- omap_display_init(&sdp4430_dss_data);
-
- platform_device_register(&sdp4430_lcd_device);
- platform_device_register(&sdp4430_lcd2_device);
-
- platform_device_register(&sdp4430_tpd_device);
- platform_device_register(&sdp4430_hdmi_connector_device);
-}
-
-
-/* OMAP3 IGEPv2 data */
-
-#define IGEP2_DVI_TFP410_POWER_DOWN_GPIO 170
-
-/* DVI Connector */
-static struct connector_dvi_platform_data omap3_igep2_dvi_connector_pdata = {
- .name = "dvi",
- .source = "tfp410.0",
- .i2c_bus_num = 3,
-};
-
-static struct platform_device omap3_igep2_dvi_connector_device = {
- .name = "connector-dvi",
- .id = 0,
- .dev.platform_data = &omap3_igep2_dvi_connector_pdata,
-};
-
-/* TFP410 DPI-to-DVI chip */
-static struct encoder_tfp410_platform_data omap3_igep2_tfp410_pdata = {
- .name = "tfp410.0",
- .source = "dpi.0",
- .data_lines = 24,
- .power_down_gpio = IGEP2_DVI_TFP410_POWER_DOWN_GPIO,
-};
-
-static struct platform_device omap3_igep2_tfp410_device = {
- .name = "tfp410",
- .id = 0,
- .dev.platform_data = &omap3_igep2_tfp410_pdata,
-};
-
-static struct omap_dss_board_info igep2_dss_data = {
- .default_display_name = "dvi",
-};
-
-void __init omap3_igep2_display_init_of(void)
-{
- omap_display_init(&igep2_dss_data);
-
- platform_device_register(&omap3_igep2_tfp410_device);
- platform_device_register(&omap3_igep2_dvi_connector_device);
-}
diff --git a/arch/arm/mach-omap2/dss-common.h b/arch/arm/mach-omap2/dss-common.h
deleted file mode 100644
index a9becf0d5be8..000000000000
--- a/arch/arm/mach-omap2/dss-common.h
+++ /dev/null
@@ -1,13 +0,0 @@
-#ifndef __OMAP_DSS_COMMON__
-#define __OMAP_DSS_COMMON__
-
-/*
- * NOTE: this is a transitional file to help with DT adaptation.
- * This file will be removed when DSS supports DT.
- */
-
-void __init omap4_panda_display_init_of(void);
-void __init omap_4430sdp_display_init_of(void);
-void __init omap3_igep2_display_init_of(void);
-
-#endif
diff --git a/arch/arm/mach-omap2/pdata-quirks.c b/arch/arm/mach-omap2/pdata-quirks.c
index 10c71450cf63..ff5b48eca778 100644
--- a/arch/arm/mach-omap2/pdata-quirks.c
+++ b/arch/arm/mach-omap2/pdata-quirks.c
@@ -18,7 +18,6 @@
#include "common.h"
#include "common-board-devices.h"
-#include "dss-common.h"
#include "control.h"
struct pdata_init {
@@ -80,7 +79,6 @@ static void __init hsmmc2_internal_input_clk(void)
static void __init omap3_igep0020_legacy_init(void)
{
- omap3_igep2_display_init_of();
}
static void __init omap3_evm_legacy_init(void)
@@ -97,14 +95,12 @@ static void __init omap3_zoom_legacy_init(void)
#ifdef CONFIG_ARCH_OMAP4
static void __init omap4_sdp_legacy_init(void)
{
- omap_4430sdp_display_init_of();
legacy_init_wl12xx(WL12XX_REFCLOCK_26,
WL12XX_TCXOCLOCK_26, 53);
}
static void __init omap4_panda_legacy_init(void)
{
- omap4_panda_display_init_of();
legacy_init_ehci_clk("auxclk3_ck");
legacy_init_wl12xx(WL12XX_REFCLOCK_38, 0, 53);
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 04/26] OMAPDSS: remove DT hacks for regulators
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
For booting Panda and 4430SDP with DT, while DSS did not support DT, we
had to had small hacks in the omapdss driver to get the regulators. With
DT now supported in DSS, we can remove those hacks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 5 -----
drivers/video/omap2/dss/hdmi4.c | 4 ----
2 files changed, 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1cd3e47fd43f..18b5e84165bb 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1124,11 +1124,6 @@ static int dsi_regulator_init(struct platform_device *dsidev)
return 0;
vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "vdds_dsi");
-
- /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
- if (IS_ERR(vdds_dsi))
- vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "VCXIO");
-
if (IS_ERR(vdds_dsi)) {
DSSERR("can't get VDDS_DSI regulator\n");
return PTR_ERR(vdds_dsi);
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index e14009614338..16e598787522 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -90,10 +90,6 @@ static int hdmi_init_regulator(void)
reg = devm_regulator_get(&hdmi.pdev->dev, "vdda_hdmi_dac");
- /* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
- if (IS_ERR(reg))
- reg = devm_regulator_get(&hdmi.pdev->dev, "VDAC");
-
if (IS_ERR(reg)) {
DSSERR("can't get VDDA_HDMI_DAC regulator\n");
return PTR_ERR(reg);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 04/26] OMAPDSS: remove DT hacks for regulators
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
For booting Panda and 4430SDP with DT, while DSS did not support DT, we
had to had small hacks in the omapdss driver to get the regulators. With
DT now supported in DSS, we can remove those hacks.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 5 -----
drivers/video/omap2/dss/hdmi4.c | 4 ----
2 files changed, 9 deletions(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 1cd3e47fd43f..18b5e84165bb 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -1124,11 +1124,6 @@ static int dsi_regulator_init(struct platform_device *dsidev)
return 0;
vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "vdds_dsi");
-
- /* DT HACK: try VCXIO to make omapdss work for o4 sdp/panda */
- if (IS_ERR(vdds_dsi))
- vdds_dsi = devm_regulator_get(&dsi->pdev->dev, "VCXIO");
-
if (IS_ERR(vdds_dsi)) {
DSSERR("can't get VDDS_DSI regulator\n");
return PTR_ERR(vdds_dsi);
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index e14009614338..16e598787522 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -90,10 +90,6 @@ static int hdmi_init_regulator(void)
reg = devm_regulator_get(&hdmi.pdev->dev, "vdda_hdmi_dac");
- /* DT HACK: try VDAC to make omapdss work for o4 sdp/panda */
- if (IS_ERR(reg))
- reg = devm_regulator_get(&hdmi.pdev->dev, "VDAC");
-
if (IS_ERR(reg)) {
DSSERR("can't get VDDA_HDMI_DAC regulator\n");
return PTR_ERR(reg);
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 2 ++
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/display.c | 62 +++++++++++++++++++++++++++++++++++++
3 files changed, 66 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 19f1652e94cf..0e06771d7bee 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
static void __init omap_generic_init(void)
{
pdata_quirks_init(omap_dt_match_table);
+
+ omapdss_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f7644febee81..48e9cd34cae0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -308,5 +308,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
/* SoC specific clock initializer */
extern int (*omap_clk_init)(void);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a4e536b11ec9..3279afc5f0b5 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
#include <video/omapdss.h>
#include "omap_hwmod.h"
@@ -592,3 +594,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver == OMAPDSS_VER_UNKNOWN) {
+ pr_err("DSS not supported on this SoC\n");
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = &board_data;
+
+ r = platform_device_register(&omap_display_device);
+ if (r < 0) {
+ pr_err("Unable to register omapdss device\n");
+ return r;
+ }
+
+ /* create DRM device */
+ r = omap_init_drm();
+ if (r < 0) {
+ pr_err("Unable to register omapdrm device\n");
+ return r;
+ }
+
+ /* create vrfb device */
+ r = omap_init_vrfb();
+ if (r < 0) {
+ pr_err("Unable to register omapvrfb device\n");
+ return r;
+ }
+
+ /* create FB device */
+ r = omap_init_fb();
+ if (r < 0) {
+ pr_err("Unable to register omapfb device\n");
+ return r;
+ }
+
+ /* create V4L2 display device */
+ r = omap_init_vout();
+ if (r < 0) {
+ pr_err("Unable to register omap_vout device\n");
+ return r;
+ }
+
+ return 0;
+}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
omapdss driver uses a omapdss platform device to pass platform specific
function pointers and DSS hardware version from the arch code to the
driver. This device is needed also when booting with DT.
This patch adds omapdss_init_of() function, called from board-generic at
init time, which creates the omapdss device.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/board-generic.c | 2 ++
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/display.c | 62 +++++++++++++++++++++++++++++++++++++
3 files changed, 66 insertions(+)
diff --git a/arch/arm/mach-omap2/board-generic.c b/arch/arm/mach-omap2/board-generic.c
index 19f1652e94cf..0e06771d7bee 100644
--- a/arch/arm/mach-omap2/board-generic.c
+++ b/arch/arm/mach-omap2/board-generic.c
@@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[] __initdata = {
static void __init omap_generic_init(void)
{
pdata_quirks_init(omap_dt_match_table);
+
+ omapdss_init_of();
}
#ifdef CONFIG_SOC_OMAP2420
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index f7644febee81..48e9cd34cae0 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -308,5 +308,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
/* SoC specific clock initializer */
extern int (*omap_clk_init)(void);
+int __init omapdss_init_of(void);
+
#endif /* __ASSEMBLER__ */
#endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index a4e536b11ec9..3279afc5f0b5 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -23,6 +23,8 @@
#include <linux/clk.h>
#include <linux/err.h>
#include <linux/delay.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
#include <video/omapdss.h>
#include "omap_hwmod.h"
@@ -592,3 +594,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
return r;
}
+
+int __init omapdss_init_of(void)
+{
+ int r;
+ enum omapdss_version ver;
+
+ static struct omap_dss_board_info board_data = {
+ .dsi_enable_pads = omap_dsi_enable_pads,
+ .dsi_disable_pads = omap_dsi_disable_pads,
+ .get_context_loss_count = omap_pm_get_dev_context_loss_count,
+ .set_min_bus_tput = omap_dss_set_min_bus_tput,
+ };
+
+ ver = omap_display_get_version();
+
+ if (ver = OMAPDSS_VER_UNKNOWN) {
+ pr_err("DSS not supported on this SoC\n");
+ return -ENODEV;
+ }
+
+ board_data.version = ver;
+
+ omap_display_device.dev.platform_data = &board_data;
+
+ r = platform_device_register(&omap_display_device);
+ if (r < 0) {
+ pr_err("Unable to register omapdss device\n");
+ return r;
+ }
+
+ /* create DRM device */
+ r = omap_init_drm();
+ if (r < 0) {
+ pr_err("Unable to register omapdrm device\n");
+ return r;
+ }
+
+ /* create vrfb device */
+ r = omap_init_vrfb();
+ if (r < 0) {
+ pr_err("Unable to register omapvrfb device\n");
+ return r;
+ }
+
+ /* create FB device */
+ r = omap_init_fb();
+ if (r < 0) {
+ pr_err("Unable to register omapfb device\n");
+ return r;
+ }
+
+ /* create V4L2 display device */
+ r = omap_init_vout();
+ if (r < 0) {
+ pr_err("Unable to register omap_vout device\n");
+ return r;
+ }
+
+ return 0;
+}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-11 23:10 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
> omapdss driver uses a omapdss platform device to pass platform specific
> function pointers and DSS hardware version from the arch code to the
> driver. This device is needed also when booting with DT.
>
> This patch adds omapdss_init_of() function, called from board-generic at
> init time, which creates the omapdss device.
Is this a temporary solution that you plan to later replace with DT-only
device instantiation ?
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/board-generic.c | 2 ++
> arch/arm/mach-omap2/common.h | 2 ++
> arch/arm/mach-omap2/display.c | 62 ++++++++++++++++++++++++++++++++++
> 3 files changed, 66 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c index 19f1652e94cf..0e06771d7bee
> 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[]
> __initdata = { static void __init omap_generic_init(void)
> {
> pdata_quirks_init(omap_dt_match_table);
> +
> + omapdss_init_of();
> }
>
> #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index f7644febee81..48e9cd34cae0 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -308,5 +308,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
> /* SoC specific clock initializer */
> extern int (*omap_clk_init)(void);
>
> +int __init omapdss_init_of(void);
> +
> #endif /* __ASSEMBLER__ */
> #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index a4e536b11ec9..3279afc5f0b5 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -23,6 +23,8 @@
> #include <linux/clk.h>
> #include <linux/err.h>
> #include <linux/delay.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>
> #include <video/omapdss.h>
> #include "omap_hwmod.h"
> @@ -592,3 +594,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
>
> return r;
> }
> +
> +int __init omapdss_init_of(void)
> +{
> + int r;
> + enum omapdss_version ver;
> +
> + static struct omap_dss_board_info board_data = {
> + .dsi_enable_pads = omap_dsi_enable_pads,
> + .dsi_disable_pads = omap_dsi_disable_pads,
> + .get_context_loss_count = omap_pm_get_dev_context_loss_count,
> + .set_min_bus_tput = omap_dss_set_min_bus_tput,
> + };
> +
> + ver = omap_display_get_version();
> +
> + if (ver == OMAPDSS_VER_UNKNOWN) {
> + pr_err("DSS not supported on this SoC\n");
> + return -ENODEV;
> + }
> +
> + board_data.version = ver;
> +
> + omap_display_device.dev.platform_data = &board_data;
> +
> + r = platform_device_register(&omap_display_device);
> + if (r < 0) {
> + pr_err("Unable to register omapdss device\n");
> + return r;
> + }
> +
> + /* create DRM device */
> + r = omap_init_drm();
> + if (r < 0) {
> + pr_err("Unable to register omapdrm device\n");
> + return r;
> + }
> +
> + /* create vrfb device */
> + r = omap_init_vrfb();
> + if (r < 0) {
> + pr_err("Unable to register omapvrfb device\n");
> + return r;
> + }
> +
> + /* create FB device */
> + r = omap_init_fb();
> + if (r < 0) {
> + pr_err("Unable to register omapfb device\n");
> + return r;
> + }
> +
> + /* create V4L2 display device */
> + r = omap_init_vout();
> + if (r < 0) {
> + pr_err("Unable to register omap_vout device\n");
> + return r;
> + }
> +
> + return 0;
> +}
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
@ 2013-12-11 23:10 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
> omapdss driver uses a omapdss platform device to pass platform specific
> function pointers and DSS hardware version from the arch code to the
> driver. This device is needed also when booting with DT.
>
> This patch adds omapdss_init_of() function, called from board-generic at
> init time, which creates the omapdss device.
Is this a temporary solution that you plan to later replace with DT-only
device instantiation ?
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/mach-omap2/board-generic.c | 2 ++
> arch/arm/mach-omap2/common.h | 2 ++
> arch/arm/mach-omap2/display.c | 62 ++++++++++++++++++++++++++++++++++
> 3 files changed, 66 insertions(+)
>
> diff --git a/arch/arm/mach-omap2/board-generic.c
> b/arch/arm/mach-omap2/board-generic.c index 19f1652e94cf..0e06771d7bee
> 100644
> --- a/arch/arm/mach-omap2/board-generic.c
> +++ b/arch/arm/mach-omap2/board-generic.c
> @@ -36,6 +36,8 @@ static struct of_device_id omap_dt_match_table[]
> __initdata = { static void __init omap_generic_init(void)
> {
> pdata_quirks_init(omap_dt_match_table);
> +
> + omapdss_init_of();
> }
>
> #ifdef CONFIG_SOC_OMAP2420
> diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
> index f7644febee81..48e9cd34cae0 100644
> --- a/arch/arm/mach-omap2/common.h
> +++ b/arch/arm/mach-omap2/common.h
> @@ -308,5 +308,7 @@ extern int omap_dss_reset(struct omap_hwmod *);
> /* SoC specific clock initializer */
> extern int (*omap_clk_init)(void);
>
> +int __init omapdss_init_of(void);
> +
> #endif /* __ASSEMBLER__ */
> #endif /* __ARCH_ARM_MACH_OMAP2PLUS_COMMON_H */
> diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
> index a4e536b11ec9..3279afc5f0b5 100644
> --- a/arch/arm/mach-omap2/display.c
> +++ b/arch/arm/mach-omap2/display.c
> @@ -23,6 +23,8 @@
> #include <linux/clk.h>
> #include <linux/err.h>
> #include <linux/delay.h>
> +#include <linux/of.h>
> +#include <linux/of_platform.h>
>
> #include <video/omapdss.h>
> #include "omap_hwmod.h"
> @@ -592,3 +594,63 @@ int omap_dss_reset(struct omap_hwmod *oh)
>
> return r;
> }
> +
> +int __init omapdss_init_of(void)
> +{
> + int r;
> + enum omapdss_version ver;
> +
> + static struct omap_dss_board_info board_data = {
> + .dsi_enable_pads = omap_dsi_enable_pads,
> + .dsi_disable_pads = omap_dsi_disable_pads,
> + .get_context_loss_count = omap_pm_get_dev_context_loss_count,
> + .set_min_bus_tput = omap_dss_set_min_bus_tput,
> + };
> +
> + ver = omap_display_get_version();
> +
> + if (ver = OMAPDSS_VER_UNKNOWN) {
> + pr_err("DSS not supported on this SoC\n");
> + return -ENODEV;
> + }
> +
> + board_data.version = ver;
> +
> + omap_display_device.dev.platform_data = &board_data;
> +
> + r = platform_device_register(&omap_display_device);
> + if (r < 0) {
> + pr_err("Unable to register omapdss device\n");
> + return r;
> + }
> +
> + /* create DRM device */
> + r = omap_init_drm();
> + if (r < 0) {
> + pr_err("Unable to register omapdrm device\n");
> + return r;
> + }
> +
> + /* create vrfb device */
> + r = omap_init_vrfb();
> + if (r < 0) {
> + pr_err("Unable to register omapvrfb device\n");
> + return r;
> + }
> +
> + /* create FB device */
> + r = omap_init_fb();
> + if (r < 0) {
> + pr_err("Unable to register omapfb device\n");
> + return r;
> + }
> +
> + /* create V4L2 display device */
> + r = omap_init_vout();
> + if (r < 0) {
> + pr_err("Unable to register omap_vout device\n");
> + return r;
> + }
> +
> + return 0;
> +}
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
2013-12-11 23:10 ` Laurent Pinchart
@ 2013-12-12 7:30 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 7:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]
On 2013-12-12 01:10, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>> omapdss driver uses a omapdss platform device to pass platform specific
>> function pointers and DSS hardware version from the arch code to the
>> driver. This device is needed also when booting with DT.
>>
>> This patch adds omapdss_init_of() function, called from board-generic at
>> init time, which creates the omapdss device.
>
> Is this a temporary solution that you plan to later replace with DT-only
> device instantiation ?
It's a long term task to remove the "virtual" omapdss device. Removing
the platform data that we pass has been very difficult.
For example, we need to get the OMAP revision to know which OMAP DSS
hardware we have. We can't get that information from the DSS hardware
(thank you, HW designers! ;).
Another is DSI pin muxing. I think we need a new pinmuxing driver for
that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
very simple, but the register fields are varying lengths and at varying
positions, so pinmux-single doesn't work for it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
@ 2013-12-12 7:30 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 7:30 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]
On 2013-12-12 01:10, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>> omapdss driver uses a omapdss platform device to pass platform specific
>> function pointers and DSS hardware version from the arch code to the
>> driver. This device is needed also when booting with DT.
>>
>> This patch adds omapdss_init_of() function, called from board-generic at
>> init time, which creates the omapdss device.
>
> Is this a temporary solution that you plan to later replace with DT-only
> device instantiation ?
It's a long term task to remove the "virtual" omapdss device. Removing
the platform data that we pass has been very difficult.
For example, we need to get the OMAP revision to know which OMAP DSS
hardware we have. We can't get that information from the DSS hardware
(thank you, HW designers! ;).
Another is DSI pin muxing. I think we need a new pinmuxing driver for
that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
very simple, but the register fields are varying lengths and at varying
positions, so pinmux-single doesn't work for it.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
2013-12-12 7:30 ` Tomi Valkeinen
@ 2013-12-13 8:44 ` Archit Taneja
-1 siblings, 0 replies; 183+ messages in thread
From: Archit Taneja @ 2013-12-13 8:32 UTC (permalink / raw)
To: Tomi Valkeinen, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Darren Etheridge, Tony Lindgren
On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:
> On 2013-12-12 01:10, Laurent Pinchart wrote:
>> Hi Tomi,
>>
>> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>>> omapdss driver uses a omapdss platform device to pass platform specific
>>> function pointers and DSS hardware version from the arch code to the
>>> driver. This device is needed also when booting with DT.
>>>
>>> This patch adds omapdss_init_of() function, called from board-generic at
>>> init time, which creates the omapdss device.
>>
>> Is this a temporary solution that you plan to later replace with DT-only
>> device instantiation ?
>
> It's a long term task to remove the "virtual" omapdss device. Removing
> the platform data that we pass has been very difficult.
Even if we remove the platform data, what would be the right place to
register the drm, fb and vout devices? We need to make sure their
drivers are probed only after omapdss is initialised.
>
> For example, we need to get the OMAP revision to know which OMAP DSS
> hardware we have. We can't get that information from the DSS hardware
> (thank you, HW designers! ;).
>
> Another is DSI pin muxing. I think we need a new pinmuxing driver for
> that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
> very simple, but the register fields are varying lengths and at varying
> positions, so pinmux-single doesn't work for it.
I have seen other OMAP drivers passing control module register info to
their DT node. Instead of having a pinmux driver for a single register,
we might want to consider just passing the control module register, and
take care of the reg fields and masks in the OMAP DSI driver itself.
The parsing of the DSI pins from DT, however, can be kept generic.
Archit
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
@ 2013-12-13 8:44 ` Archit Taneja
0 siblings, 0 replies; 183+ messages in thread
From: Archit Taneja @ 2013-12-13 8:44 UTC (permalink / raw)
To: Tomi Valkeinen, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Darren Etheridge, Tony Lindgren
On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:
> On 2013-12-12 01:10, Laurent Pinchart wrote:
>> Hi Tomi,
>>
>> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>>> omapdss driver uses a omapdss platform device to pass platform specific
>>> function pointers and DSS hardware version from the arch code to the
>>> driver. This device is needed also when booting with DT.
>>>
>>> This patch adds omapdss_init_of() function, called from board-generic at
>>> init time, which creates the omapdss device.
>>
>> Is this a temporary solution that you plan to later replace with DT-only
>> device instantiation ?
>
> It's a long term task to remove the "virtual" omapdss device. Removing
> the platform data that we pass has been very difficult.
Even if we remove the platform data, what would be the right place to
register the drm, fb and vout devices? We need to make sure their
drivers are probed only after omapdss is initialised.
>
> For example, we need to get the OMAP revision to know which OMAP DSS
> hardware we have. We can't get that information from the DSS hardware
> (thank you, HW designers! ;).
>
> Another is DSI pin muxing. I think we need a new pinmuxing driver for
> that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
> very simple, but the register fields are varying lengths and at varying
> positions, so pinmux-single doesn't work for it.
I have seen other OMAP drivers passing control module register info to
their DT node. Instead of having a pinmux driver for a single register,
we might want to consider just passing the control module register, and
take care of the reg fields and masks in the OMAP DSI driver itself.
The parsing of the DSI pins from DT, however, can be kept generic.
Archit
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
2013-12-13 8:44 ` Archit Taneja
@ 2013-12-13 8:40 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 8:40 UTC (permalink / raw)
To: Archit Taneja, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]
On 2013-12-13 10:32, Archit Taneja wrote:
> On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:
>> On 2013-12-12 01:10, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>>>> omapdss driver uses a omapdss platform device to pass platform specific
>>>> function pointers and DSS hardware version from the arch code to the
>>>> driver. This device is needed also when booting with DT.
>>>>
>>>> This patch adds omapdss_init_of() function, called from
>>>> board-generic at
>>>> init time, which creates the omapdss device.
>>>
>>> Is this a temporary solution that you plan to later replace with DT-only
>>> device instantiation ?
>>
>> It's a long term task to remove the "virtual" omapdss device. Removing
>> the platform data that we pass has been very difficult.
>
> Even if we remove the platform data, what would be the right place to
> register the drm, fb and vout devices? We need to make sure their
> drivers are probed only after omapdss is initialised.
That's the same issue as we have already, so removing omapdss doesn't
affect that.
I don't think we have any good way to ensure those devices are not
probed before omapdss. We just have to manage the case that omapdss has
not been probed yet, by checking if omapdss is there and if not, return
EPROBE_DEFER.
>> For example, we need to get the OMAP revision to know which OMAP DSS
>> hardware we have. We can't get that information from the DSS hardware
>> (thank you, HW designers! ;).
>>
>
>> Another is DSI pin muxing. I think we need a new pinmuxing driver for
>> that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
>> very simple, but the register fields are varying lengths and at varying
>> positions, so pinmux-single doesn't work for it.
>
> I have seen other OMAP drivers passing control module register info to
> their DT node. Instead of having a pinmux driver for a single register,
> we might want to consider just passing the control module register, and
> take care of the reg fields and masks in the OMAP DSI driver itself.
Yes, that's also one option. Quite ugly, though =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
@ 2013-12-13 8:40 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 8:40 UTC (permalink / raw)
To: Archit Taneja, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]
On 2013-12-13 10:32, Archit Taneja wrote:
> On Thursday 12 December 2013 01:00 PM, Tomi Valkeinen wrote:
>> On 2013-12-12 01:10, Laurent Pinchart wrote:
>>> Hi Tomi,
>>>
>>> On Wednesday 04 December 2013 14:28:32 Tomi Valkeinen wrote:
>>>> omapdss driver uses a omapdss platform device to pass platform specific
>>>> function pointers and DSS hardware version from the arch code to the
>>>> driver. This device is needed also when booting with DT.
>>>>
>>>> This patch adds omapdss_init_of() function, called from
>>>> board-generic at
>>>> init time, which creates the omapdss device.
>>>
>>> Is this a temporary solution that you plan to later replace with DT-only
>>> device instantiation ?
>>
>> It's a long term task to remove the "virtual" omapdss device. Removing
>> the platform data that we pass has been very difficult.
>
> Even if we remove the platform data, what would be the right place to
> register the drm, fb and vout devices? We need to make sure their
> drivers are probed only after omapdss is initialised.
That's the same issue as we have already, so removing omapdss doesn't
affect that.
I don't think we have any good way to ensure those devices are not
probed before omapdss. We just have to manage the case that omapdss has
not been probed yet, by checking if omapdss is there and if not, return
EPROBE_DEFER.
>> For example, we need to get the OMAP revision to know which OMAP DSS
>> hardware we have. We can't get that information from the DSS hardware
>> (thank you, HW designers! ;).
>>
>
>> Another is DSI pin muxing. I think we need a new pinmuxing driver for
>> that, or maybe change pinmux-single quite a bit. The DSI pinmuxing is
>> very simple, but the register fields are varying lengths and at varying
>> positions, so pinmux-single doesn't work for it.
>
> I have seen other OMAP drivers passing control module register info to
> their DT node. Instead of having a pinmux driver for a single register,
> we might want to consider just passing the control module register, and
> take care of the reg fields and masks in the OMAP DSI driver itself.
Yes, that's also one option. Quite ugly, though =).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
2013-12-13 8:44 ` Archit Taneja
@ 2013-12-13 17:07 ` Tony Lindgren
-1 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-13 17:07 UTC (permalink / raw)
To: Archit Taneja
Cc: Tomi Valkeinen, Laurent Pinchart, linux-omap, linux-fbdev,
devicetree, Darren Etheridge
* Archit Taneja <archit@ti.com> [131213 00:33]:
>
> I have seen other OMAP drivers passing control module register info
> to their DT node. Instead of having a pinmux driver for a single
> register, we might want to consider just passing the control module
> register, and take care of the reg fields and masks in the OMAP DSI
> driver itself.
See the PBIAS control module patches and their comments from Balaji.
We can map the misc registers of SCM using drivers/mfd/syscon.c and
that way drivers can access them via syscon.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 05/26] ARM: OMAP2+: add omapdss_init_of()
@ 2013-12-13 17:07 ` Tony Lindgren
0 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-13 17:07 UTC (permalink / raw)
To: Archit Taneja
Cc: Tomi Valkeinen, Laurent Pinchart, linux-omap, linux-fbdev,
devicetree, Darren Etheridge
* Archit Taneja <archit@ti.com> [131213 00:33]:
>
> I have seen other OMAP drivers passing control module register info
> to their DT node. Instead of having a pinmux driver for a single
> register, we might want to consider just passing the control module
> register, and take care of the reg fields and masks in the OMAP DSI
> driver itself.
See the PBIAS control module patches and their comments from Balaji.
We can map the misc registers of SCM using drivers/mfd/syscon.c and
that way drivers can access them via syscon.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
To avoid the need for a "nickname" property for each display, change
the display registration so that the display's alias (i.e. "display0"
etc) will be used for the dssdev->name if the display driver didn't
provide a name.
This means that when booting with board files, we will have more
descriptive names for displays, like "lcd1", "hdmi". With DT we'll only
have "display0", etc. But as there are no "nicknames" for things like
serials ports either, I hope we will do fine with this approach.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index 669a81fdf58e..a946cf7ed00f 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device *dssdev)
snprintf(dssdev->alias, sizeof(dssdev->alias),
"display%d", disp_num_counter++);
+ if (dssdev->name == NULL)
+ dssdev->name = dssdev->alias;
+
if (drv && drv->get_resolution == NULL)
drv->get_resolution = omapdss_default_get_resolution;
if (drv && drv->get_recommended_bpp == NULL)
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
To avoid the need for a "nickname" property for each display, change
the display registration so that the display's alias (i.e. "display0"
etc) will be used for the dssdev->name if the display driver didn't
provide a name.
This means that when booting with board files, we will have more
descriptive names for displays, like "lcd1", "hdmi". With DT we'll only
have "display0", etc. But as there are no "nicknames" for things like
serials ports either, I hope we will do fine with this approach.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index 669a81fdf58e..a946cf7ed00f 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device *dssdev)
snprintf(dssdev->alias, sizeof(dssdev->alias),
"display%d", disp_num_counter++);
+ if (dssdev->name = NULL)
+ dssdev->name = dssdev->alias;
+
if (drv && drv->get_resolution = NULL)
drv->get_resolution = omapdss_default_get_resolution;
if (drv && drv->get_recommended_bpp = NULL)
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-11 23:13 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:13 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
> To avoid the need for a "nickname" property for each display, change
> the display registration so that the display's alias (i.e. "display0"
> etc) will be used for the dssdev->name if the display driver didn't
> provide a name.
>
> This means that when booting with board files, we will have more
> descriptive names for displays, like "lcd1", "hdmi".
Where are those names used ? Are they reported to userspace, or limited to
kernel internal use only ?
> With DT we'll only have "display0", etc. But as there are no "nicknames" for
> things like serials ports either, I hope we will do fine with this approach.
Just a random thought, maybe the aliases node could help here. I'm not sure
what rules govern its usage. Adding labels to display DT nodes could be an
option too.
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/display.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/omap2/dss/display.c
> b/drivers/video/omap2/dss/display.c index 669a81fdf58e..a946cf7ed00f 100644
> --- a/drivers/video/omap2/dss/display.c
> +++ b/drivers/video/omap2/dss/display.c
> @@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device
> *dssdev) snprintf(dssdev->alias, sizeof(dssdev->alias),
> "display%d", disp_num_counter++);
>
> + if (dssdev->name == NULL)
> + dssdev->name = dssdev->alias;
> +
> if (drv && drv->get_resolution == NULL)
> drv->get_resolution = omapdss_default_get_resolution;
> if (drv && drv->get_recommended_bpp == NULL)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-11 23:13 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:13 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
> To avoid the need for a "nickname" property for each display, change
> the display registration so that the display's alias (i.e. "display0"
> etc) will be used for the dssdev->name if the display driver didn't
> provide a name.
>
> This means that when booting with board files, we will have more
> descriptive names for displays, like "lcd1", "hdmi".
Where are those names used ? Are they reported to userspace, or limited to
kernel internal use only ?
> With DT we'll only have "display0", etc. But as there are no "nicknames" for
> things like serials ports either, I hope we will do fine with this approach.
Just a random thought, maybe the aliases node could help here. I'm not sure
what rules govern its usage. Adding labels to display DT nodes could be an
option too.
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/display.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/video/omap2/dss/display.c
> b/drivers/video/omap2/dss/display.c index 669a81fdf58e..a946cf7ed00f 100644
> --- a/drivers/video/omap2/dss/display.c
> +++ b/drivers/video/omap2/dss/display.c
> @@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device
> *dssdev) snprintf(dssdev->alias, sizeof(dssdev->alias),
> "display%d", disp_num_counter++);
>
> + if (dssdev->name = NULL)
> + dssdev->name = dssdev->alias;
> +
> if (drv && drv->get_resolution = NULL)
> drv->get_resolution = omapdss_default_get_resolution;
> if (drv && drv->get_recommended_bpp = NULL)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-11 23:13 ` Laurent Pinchart
@ 2013-12-11 23:56 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Thursday 12 December 2013 00:13:01 Laurent Pinchart wrote:
> On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
> > To avoid the need for a "nickname" property for each display, change
> > the display registration so that the display's alias (i.e. "display0"
> > etc) will be used for the dssdev->name if the display driver didn't
> > provide a name.
> >
> > This means that when booting with board files, we will have more
> > descriptive names for displays, like "lcd1", "hdmi".
>
> Where are those names used ? Are they reported to userspace, or limited to
> kernel internal use only ?
>
> > With DT we'll only have "display0", etc. But as there are no "nicknames"
> > for things like serials ports either, I hope we will do fine with this
>
> Just a random thought, maybe the aliases node could help here.
I should have read the next patches before replying, sorry :-)
> I'm not sure what rules govern its usage. Adding labels to display DT nodes
> could be an option too.
A label property is still an option.
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> >
> > drivers/video/omap2/dss/display.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/video/omap2/dss/display.c
> > b/drivers/video/omap2/dss/display.c index 669a81fdf58e..a946cf7ed00f
> > 100644
> > --- a/drivers/video/omap2/dss/display.c
> > +++ b/drivers/video/omap2/dss/display.c
> > @@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device
> > *dssdev)
> > snprintf(dssdev->alias, sizeof(dssdev->alias),
> > "display%d", disp_num_counter++);
> >
> > + if (dssdev->name == NULL)
> > + dssdev->name = dssdev->alias;
> > +
> > if (drv && drv->get_resolution == NULL)
> > drv->get_resolution = omapdss_default_get_resolution;
> > if (drv && drv->get_recommended_bpp == NULL)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-11 23:56 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:56 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Thursday 12 December 2013 00:13:01 Laurent Pinchart wrote:
> On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
> > To avoid the need for a "nickname" property for each display, change
> > the display registration so that the display's alias (i.e. "display0"
> > etc) will be used for the dssdev->name if the display driver didn't
> > provide a name.
> >
> > This means that when booting with board files, we will have more
> > descriptive names for displays, like "lcd1", "hdmi".
>
> Where are those names used ? Are they reported to userspace, or limited to
> kernel internal use only ?
>
> > With DT we'll only have "display0", etc. But as there are no "nicknames"
> > for things like serials ports either, I hope we will do fine with this
>
> Just a random thought, maybe the aliases node could help here.
I should have read the next patches before replying, sorry :-)
> I'm not sure what rules govern its usage. Adding labels to display DT nodes
> could be an option too.
A label property is still an option.
> > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> > ---
> >
> > drivers/video/omap2/dss/display.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/video/omap2/dss/display.c
> > b/drivers/video/omap2/dss/display.c index 669a81fdf58e..a946cf7ed00f
> > 100644
> > --- a/drivers/video/omap2/dss/display.c
> > +++ b/drivers/video/omap2/dss/display.c
> > @@ -137,6 +137,9 @@ int omapdss_register_display(struct omap_dss_device
> > *dssdev)
> > snprintf(dssdev->alias, sizeof(dssdev->alias),
> > "display%d", disp_num_counter++);
> >
> > + if (dssdev->name = NULL)
> > + dssdev->name = dssdev->alias;
> > +
> > if (drv && drv->get_resolution = NULL)
> > drv->get_resolution = omapdss_default_get_resolution;
> > if (drv && drv->get_recommended_bpp = NULL)
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-11 23:56 ` Laurent Pinchart
@ 2013-12-12 7:41 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 7:41 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]
On 2013-12-12 01:56, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Thursday 12 December 2013 00:13:01 Laurent Pinchart wrote:
>> On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
>>> To avoid the need for a "nickname" property for each display, change
>>> the display registration so that the display's alias (i.e. "display0"
>>> etc) will be used for the dssdev->name if the display driver didn't
>>> provide a name.
>>>
>>> This means that when booting with board files, we will have more
>>> descriptive names for displays, like "lcd1", "hdmi".
>>
>> Where are those names used ? Are they reported to userspace, or limited to
>> kernel internal use only ?
They are visible via omapdss's sysfs, when using omapfb. They are used
for debug prints and by the user for selecting the default display and
display modes via kernel cmdline, and when he sets the video pipeline
routing. So changing them could be considered breaking the API, but...
With omapdrm the sysfs files do not exist, and I think omapdrm doesn't
use them (except maybe for some debug prints).
>>> With DT we'll only have "display0", etc. But as there are no "nicknames"
>>> for things like serials ports either, I hope we will do fine with this
>>
>> Just a random thought, maybe the aliases node could help here.
>
> I should have read the next patches before replying, sorry :-)
>
>> I'm not sure what rules govern its usage. Adding labels to display DT nodes
>> could be an option too.
Using of_alias_get_id() means that the alias is in the form "nameX"
where X is a number.
> A label property is still an option.
Hmm, what do you mean? Label as in:
foo : node {
};
Isn't that 'foo' label only visible in DT itself, as a shortcut?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-12 7:41 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 7:41 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1777 bytes --]
On 2013-12-12 01:56, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Thursday 12 December 2013 00:13:01 Laurent Pinchart wrote:
>> On Wednesday 04 December 2013 14:28:33 Tomi Valkeinen wrote:
>>> To avoid the need for a "nickname" property for each display, change
>>> the display registration so that the display's alias (i.e. "display0"
>>> etc) will be used for the dssdev->name if the display driver didn't
>>> provide a name.
>>>
>>> This means that when booting with board files, we will have more
>>> descriptive names for displays, like "lcd1", "hdmi".
>>
>> Where are those names used ? Are they reported to userspace, or limited to
>> kernel internal use only ?
They are visible via omapdss's sysfs, when using omapfb. They are used
for debug prints and by the user for selecting the default display and
display modes via kernel cmdline, and when he sets the video pipeline
routing. So changing them could be considered breaking the API, but...
With omapdrm the sysfs files do not exist, and I think omapdrm doesn't
use them (except maybe for some debug prints).
>>> With DT we'll only have "display0", etc. But as there are no "nicknames"
>>> for things like serials ports either, I hope we will do fine with this
>>
>> Just a random thought, maybe the aliases node could help here.
>
> I should have read the next patches before replying, sorry :-)
>
>> I'm not sure what rules govern its usage. Adding labels to display DT nodes
>> could be an option too.
Using of_alias_get_id() means that the alias is in the form "nameX"
where X is a number.
> A label property is still an option.
Hmm, what do you mean? Label as in:
foo : node {
};
Isn't that 'foo' label only visible in DT itself, as a shortcut?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread[parent not found: <52A968BD.20304-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
[not found] ` <52A968BD.20304-l0cyMroinI0@public.gmane.org>
@ 2013-12-12 10:05 ` Sebastian Reichel
0 siblings, 0 replies; 183+ messages in thread
From: Sebastian Reichel @ 2013-12-12 10:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> > A label property is still an option.
>
> Hmm, what do you mean? Label as in:
>
> foo : node {
> };
>
> Isn't that 'foo' label only visible in DT itself, as a shortcut?
Some driver use a "label" property like this:
foo : node {
label = "lcd";
...
};
See for example
Documentation/devicetree/bindings/leds/common.txt
Documentation/devicetree/bindings/mtd/partition.txt
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-12 10:05 ` Sebastian Reichel
0 siblings, 0 replies; 183+ messages in thread
From: Sebastian Reichel @ 2013-12-12 10:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> > A label property is still an option.
>
> Hmm, what do you mean? Label as in:
>
> foo : node {
> };
>
> Isn't that 'foo' label only visible in DT itself, as a shortcut?
Some driver use a "label" property like this:
foo : node {
label = "lcd";
...
};
See for example
Documentation/devicetree/bindings/leds/common.txt
Documentation/devicetree/bindings/mtd/partition.txt
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-12 10:05 ` Sebastian Reichel
@ 2013-12-12 13:22 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-12 13:22 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
On Thursday 12 December 2013 11:05:28 Sebastian Reichel wrote:
> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> > > A label property is still an option.
> >
> > Hmm, what do you mean? Label as in:
> >
> > foo : node {
> > };
> >
> > Isn't that 'foo' label only visible in DT itself, as a shortcut?
>
> Some driver use a "label" property like this:
>
> foo : node {
> label = "lcd";
>
> ...
> };
Yes, that's what I meant.
> See for example
>
> Documentation/devicetree/bindings/leds/common.txt
> Documentation/devicetree/bindings/mtd/partition.txt
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-12 13:22 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-12 13:22 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
On Thursday 12 December 2013 11:05:28 Sebastian Reichel wrote:
> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> > > A label property is still an option.
> >
> > Hmm, what do you mean? Label as in:
> >
> > foo : node {
> > };
> >
> > Isn't that 'foo' label only visible in DT itself, as a shortcut?
>
> Some driver use a "label" property like this:
>
> foo : node {
> label = "lcd";
>
> ...
> };
Yes, that's what I meant.
> See for example
>
> Documentation/devicetree/bindings/leds/common.txt
> Documentation/devicetree/bindings/mtd/partition.txt
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-12 10:05 ` Sebastian Reichel
@ 2013-12-12 14:13 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 14:13 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On 2013-12-12 12:05, Sebastian Reichel wrote:
> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
>>> A label property is still an option.
>>
>> Hmm, what do you mean? Label as in:
>>
>> foo : node {
>> };
>>
>> Isn't that 'foo' label only visible in DT itself, as a shortcut?
>
> Some driver use a "label" property like this:
>
> foo : node {
> label = "lcd";
>
> ...
> };
>
> See for example
>
> Documentation/devicetree/bindings/leds/common.txt
> Documentation/devicetree/bindings/mtd/partition.txt
Ah, I see. That kind of label was actually the first thing I did when
starting to work on DSS DT. But I removed it, as it didn't describe the
hardware and I didn't see others using anything similar.
But I guess one could argue it does describe hardware, not in electrical
level but in conceptual level.
The question is, do we need labeling for displays? For backward
compatibility omapdss would need it, but in general? I'm quite content
with having just display0, display1 etc. Using the alias node, those can
be fixed and display0 is always the same display.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-12 14:13 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 14:13 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On 2013-12-12 12:05, Sebastian Reichel wrote:
> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
>>> A label property is still an option.
>>
>> Hmm, what do you mean? Label as in:
>>
>> foo : node {
>> };
>>
>> Isn't that 'foo' label only visible in DT itself, as a shortcut?
>
> Some driver use a "label" property like this:
>
> foo : node {
> label = "lcd";
>
> ...
> };
>
> See for example
>
> Documentation/devicetree/bindings/leds/common.txt
> Documentation/devicetree/bindings/mtd/partition.txt
Ah, I see. That kind of label was actually the first thing I did when
starting to work on DSS DT. But I removed it, as it didn't describe the
hardware and I didn't see others using anything similar.
But I guess one could argue it does describe hardware, not in electrical
level but in conceptual level.
The question is, do we need labeling for displays? For backward
compatibility omapdss would need it, but in general? I'm quite content
with having just display0, display1 etc. Using the alias node, those can
be fixed and display0 is always the same display.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-12 14:13 ` Tomi Valkeinen
@ 2013-12-12 14:15 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-12 14:15 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Sebastian Reichel, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
Hi Tomi,
On Thursday 12 December 2013 16:13:04 Tomi Valkeinen wrote:
> On 2013-12-12 12:05, Sebastian Reichel wrote:
> > On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> >>> A label property is still an option.
> >>
> >> Hmm, what do you mean? Label as in:
> >>
> >> foo : node {
> >> };
> >>
> >> Isn't that 'foo' label only visible in DT itself, as a shortcut?
> >
> > Some driver use a "label" property like this:
> >
> > foo : node {
> >
> > label = "lcd";
> >
> > ...
> >
> > };
> >
> > See for example
> >
> > Documentation/devicetree/bindings/leds/common.txt
> > Documentation/devicetree/bindings/mtd/partition.txt
>
> Ah, I see. That kind of label was actually the first thing I did when
> starting to work on DSS DT. But I removed it, as it didn't describe the
> hardware and I didn't see others using anything similar.
>
> But I guess one could argue it does describe hardware, not in electrical
> level but in conceptual level.
>
> The question is, do we need labeling for displays? For backward
> compatibility omapdss would need it, but in general? I'm quite content
> with having just display0, display1 etc. Using the alias node, those can
> be fixed and display0 is always the same display.
As you mentioned in your previous e-mail, if the labels are used by omapfb
only, I won't strongly push to keep them. I wonder, however, when using
DRM/KMS, where do the connector labels that are displayed by xrandr for
instance come from ?
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-12 14:15 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-12 14:15 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Sebastian Reichel, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1526 bytes --]
Hi Tomi,
On Thursday 12 December 2013 16:13:04 Tomi Valkeinen wrote:
> On 2013-12-12 12:05, Sebastian Reichel wrote:
> > On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
> >>> A label property is still an option.
> >>
> >> Hmm, what do you mean? Label as in:
> >>
> >> foo : node {
> >> };
> >>
> >> Isn't that 'foo' label only visible in DT itself, as a shortcut?
> >
> > Some driver use a "label" property like this:
> >
> > foo : node {
> >
> > label = "lcd";
> >
> > ...
> >
> > };
> >
> > See for example
> >
> > Documentation/devicetree/bindings/leds/common.txt
> > Documentation/devicetree/bindings/mtd/partition.txt
>
> Ah, I see. That kind of label was actually the first thing I did when
> starting to work on DSS DT. But I removed it, as it didn't describe the
> hardware and I didn't see others using anything similar.
>
> But I guess one could argue it does describe hardware, not in electrical
> level but in conceptual level.
>
> The question is, do we need labeling for displays? For backward
> compatibility omapdss would need it, but in general? I'm quite content
> with having just display0, display1 etc. Using the alias node, those can
> be fixed and display0 is always the same display.
As you mentioned in your previous e-mail, if the labels are used by omapfb
only, I won't strongly push to keep them. I wonder, however, when using
DRM/KMS, where do the connector labels that are displayed by xrandr for
instance come from ?
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-12 14:15 ` Laurent Pinchart
@ 2013-12-12 14:19 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 14:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sebastian Reichel, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
On 2013-12-12 16:15, Laurent Pinchart wrote:
> As you mentioned in your previous e-mail, if the labels are used by omapfb
> only, I won't strongly push to keep them. I wonder, however, when using
> DRM/KMS, where do the connector labels that are displayed by xrandr for
> instance come from ?
drivers/gpu/drm/drm_crtc.c has lists, with names like "DVI-D", "HDMI-A",
for connectors and encoders. Maybe from those.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-12 14:19 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 14:19 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Sebastian Reichel, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
On 2013-12-12 16:15, Laurent Pinchart wrote:
> As you mentioned in your previous e-mail, if the labels are used by omapfb
> only, I won't strongly push to keep them. I wonder, however, when using
> DRM/KMS, where do the connector labels that are displayed by xrandr for
> instance come from ?
drivers/gpu/drm/drm_crtc.c has lists, with names like "DVI-D", "HDMI-A",
for connectors and encoders. Maybe from those.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-12 14:19 ` Tomi Valkeinen
@ 2013-12-12 17:31 ` Sebastian Reichel
-1 siblings, 0 replies; 183+ messages in thread
From: Sebastian Reichel @ 2013-12-12 17:31 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
On Thu, Dec 12, 2013 at 04:19:01PM +0200, Tomi Valkeinen wrote:
> On 2013-12-12 16:15, Laurent Pinchart wrote:
>
> > As you mentioned in your previous e-mail, if the labels are used by omapfb
> > only, I won't strongly push to keep them. I wonder, however, when using
> > DRM/KMS, where do the connector labels that are displayed by xrandr for
> > instance come from ?
>
> drivers/gpu/drm/drm_crtc.c has lists, with names like "DVI-D", "HDMI-A",
> for connectors and encoders. Maybe from those.
The xrandr names are generated from the list Tomi mentioned.
=> drm_connector_enum_list
This requires a mapping from omapdss types to DRM types, which is
done in drivers/gpu/drm/omapdrm/omap_drv.c:get_connector_type().
Currently only HDMI and DVI are handled properly.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-12 17:31 ` Sebastian Reichel
0 siblings, 0 replies; 183+ messages in thread
From: Sebastian Reichel @ 2013-12-12 17:31 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
On Thu, Dec 12, 2013 at 04:19:01PM +0200, Tomi Valkeinen wrote:
> On 2013-12-12 16:15, Laurent Pinchart wrote:
>
> > As you mentioned in your previous e-mail, if the labels are used by omapfb
> > only, I won't strongly push to keep them. I wonder, however, when using
> > DRM/KMS, where do the connector labels that are displayed by xrandr for
> > instance come from ?
>
> drivers/gpu/drm/drm_crtc.c has lists, with names like "DVI-D", "HDMI-A",
> for connectors and encoders. Maybe from those.
The xrandr names are generated from the list Tomi mentioned.
=> drm_connector_enum_list
This requires a mapping from omapdss types to DRM types, which is
done in drivers/gpu/drm/omapdrm/omap_drv.c:get_connector_type().
Currently only HDMI and DVI are handled properly.
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
2013-12-12 14:13 ` Tomi Valkeinen
@ 2013-12-13 12:01 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 12:01 UTC (permalink / raw)
To: Sebastian Reichel, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Florian Vaussard
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
On 2013-12-12 16:13, Tomi Valkeinen wrote:
> On 2013-12-12 12:05, Sebastian Reichel wrote:
>> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
>>>> A label property is still an option.
>>>
>>> Hmm, what do you mean? Label as in:
>>>
>>> foo : node {
>>> };
>>>
>>> Isn't that 'foo' label only visible in DT itself, as a shortcut?
>>
>> Some driver use a "label" property like this:
>>
>> foo : node {
>> label = "lcd";
>>
>> ...
>> };
>>
>> See for example
>>
>> Documentation/devicetree/bindings/leds/common.txt
>> Documentation/devicetree/bindings/mtd/partition.txt
>
> Ah, I see. That kind of label was actually the first thing I did when
> starting to work on DSS DT. But I removed it, as it didn't describe the
> hardware and I didn't see others using anything similar.
>
> But I guess one could argue it does describe hardware, not in electrical
> level but in conceptual level.
>
> The question is, do we need labeling for displays? For backward
> compatibility omapdss would need it, but in general? I'm quite content
> with having just display0, display1 etc. Using the alias node, those can
> be fixed and display0 is always the same display.
I came to the conclusion that it's better to add the label to keep
backward compatibility, especially as it was very easy to add.
So we'll have 'name' and 'alias' for each display (as we have already).
In the current non-DT boot (which is going away):
- 'alias' is created by omapdss dynamically (first display to be
registered is display0, etc.)
- 'name' comes from platform data
In the DT boot:
- 'alias' comes from the DT aliases node, or if there are no display
aliases, it's created the same way as to non-DT. The code presumes that
there either is a DT alias for all displays, or there are none.
- 'name' comes from 'label' property
In both non-DT and DT cases, if 'name' is NULL (i.e. not set in platform
data or no 'label' property), the alias is used as a name.
I think this works fine, and was a trivial change.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 06/26] OMAPDSS: if dssdev->name==NULL, use alias
@ 2013-12-13 12:01 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 12:01 UTC (permalink / raw)
To: Sebastian Reichel, Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Florian Vaussard
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
On 2013-12-12 16:13, Tomi Valkeinen wrote:
> On 2013-12-12 12:05, Sebastian Reichel wrote:
>> On Thu, Dec 12, 2013 at 09:41:49AM +0200, Tomi Valkeinen wrote:
>>>> A label property is still an option.
>>>
>>> Hmm, what do you mean? Label as in:
>>>
>>> foo : node {
>>> };
>>>
>>> Isn't that 'foo' label only visible in DT itself, as a shortcut?
>>
>> Some driver use a "label" property like this:
>>
>> foo : node {
>> label = "lcd";
>>
>> ...
>> };
>>
>> See for example
>>
>> Documentation/devicetree/bindings/leds/common.txt
>> Documentation/devicetree/bindings/mtd/partition.txt
>
> Ah, I see. That kind of label was actually the first thing I did when
> starting to work on DSS DT. But I removed it, as it didn't describe the
> hardware and I didn't see others using anything similar.
>
> But I guess one could argue it does describe hardware, not in electrical
> level but in conceptual level.
>
> The question is, do we need labeling for displays? For backward
> compatibility omapdss would need it, but in general? I'm quite content
> with having just display0, display1 etc. Using the alias node, those can
> be fixed and display0 is always the same display.
I came to the conclusion that it's better to add the label to keep
backward compatibility, especially as it was very easy to add.
So we'll have 'name' and 'alias' for each display (as we have already).
In the current non-DT boot (which is going away):
- 'alias' is created by omapdss dynamically (first display to be
registered is display0, etc.)
- 'name' comes from platform data
In the DT boot:
- 'alias' comes from the DT aliases node, or if there are no display
aliases, it's created the same way as to non-DT. The code presumes that
there either is a DT alias for all displays, or there are none.
- 'name' comes from 'label' property
In both non-DT and DT cases, if 'name' is NULL (i.e. not set in platform
data or no 'label' property), the alias is used as a name.
I think this works fine, and was a trivial change.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 07/26] OMAPDSS: get dssdev->alias from DT alias
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
We currently create a "displayX" style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.
This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.
This means that "display0" is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index a946cf7ed00f..2f689a5fc45b 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -26,6 +26,7 @@
#include <linux/module.h>
#include <linux/jiffies.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <video/omapdss.h>
#include "dss.h"
@@ -133,9 +134,24 @@ static int disp_num_counter;
int omapdss_register_display(struct omap_dss_device *dssdev)
{
struct omap_dss_driver *drv = dssdev->driver;
+ int id;
- snprintf(dssdev->alias, sizeof(dssdev->alias),
- "display%d", disp_num_counter++);
+ /*
+ * Note: this presumes all the displays are either using DT or non-DT,
+ * which normally should be the case. This also presumes that all
+ * displays either have an DT alias, or none has.
+ */
+
+ if (dssdev->dev->of_node) {
+ id = of_alias_get_id(dssdev->dev->of_node, "display");
+
+ if (id < 0)
+ id = disp_num_counter++;
+ } else {
+ id = disp_num_counter++;
+ }
+
+ snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
if (dssdev->name == NULL)
dssdev->name = dssdev->alias;
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 07/26] OMAPDSS: get dssdev->alias from DT alias
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
We currently create a "displayX" style alias name for all displays,
using a number that is incremented for each registered display. With the
new DSS device model there is no clear order in which the displays are
registered, and thus the numbering is somewhat random.
This patch improves the behavior for DT case so that if the displays
have been assigned DT aliases, those aliases will be used as DSS
aliases.
This means that "display0" is always the one specified in the DT alias,
and thus display0 can be used as default display in case the user didn't
specify a default display.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/display.c | 20 ++++++++++++++++++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/drivers/video/omap2/dss/display.c b/drivers/video/omap2/dss/display.c
index a946cf7ed00f..2f689a5fc45b 100644
--- a/drivers/video/omap2/dss/display.c
+++ b/drivers/video/omap2/dss/display.c
@@ -26,6 +26,7 @@
#include <linux/module.h>
#include <linux/jiffies.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <video/omapdss.h>
#include "dss.h"
@@ -133,9 +134,24 @@ static int disp_num_counter;
int omapdss_register_display(struct omap_dss_device *dssdev)
{
struct omap_dss_driver *drv = dssdev->driver;
+ int id;
- snprintf(dssdev->alias, sizeof(dssdev->alias),
- "display%d", disp_num_counter++);
+ /*
+ * Note: this presumes all the displays are either using DT or non-DT,
+ * which normally should be the case. This also presumes that all
+ * displays either have an DT alias, or none has.
+ */
+
+ if (dssdev->dev->of_node) {
+ id = of_alias_get_id(dssdev->dev->of_node, "display");
+
+ if (id < 0)
+ id = disp_num_counter++;
+ } else {
+ id = disp_num_counter++;
+ }
+
+ snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
if (dssdev->name = NULL)
dssdev->name = dssdev->alias;
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 08/26] OMAPFB: clean up default display search
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Separate the code for finding the default display into a function for
clarity and to make it easier to extend it in the future.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 46 ++++++++++++++++++++------------
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905683f3..8bfe973e55ec 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2407,6 +2407,34 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev,
return 0;
}
+static struct omap_dss_device *
+omapfb_find_default_display(struct omapfb2_device *fbdev)
+{
+ const char *def_name;
+ int i;
+
+ /* search with the display name from the user or the board file */
+
+ def_name = omapdss_get_default_display_name();
+
+ if (def_name) {
+ for (i = 0; i < fbdev->num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+
+ dssdev = fbdev->displays[i].dssdev;
+
+ if (dssdev->name && strcmp(def_name, dssdev->name) == 0)
+ return dssdev;
+ }
+
+ /* def_name given but not found */
+ return NULL;
+ }
+
+ /* return the first display we have in the list */
+ return fbdev->displays[0].dssdev;
+}
+
static int omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
@@ -2484,23 +2512,7 @@ static int omapfb_probe(struct platform_device *pdev)
for (i = 0; i < fbdev->num_managers; i++)
fbdev->managers[i] = omap_dss_get_overlay_manager(i);
- def_display = NULL;
-
- for (i = 0; i < fbdev->num_displays; ++i) {
- struct omap_dss_device *dssdev;
- const char *def_name;
-
- def_name = omapdss_get_default_display_name();
-
- dssdev = fbdev->displays[i].dssdev;
-
- if (def_name == NULL ||
- (dssdev->name && strcmp(def_name, dssdev->name) == 0)) {
- def_display = dssdev;
- break;
- }
- }
-
+ def_display = omapfb_find_default_display(fbdev);
if (def_display == NULL) {
dev_err(fbdev->dev, "failed to find default display\n");
r = -EPROBE_DEFER;
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 08/26] OMAPFB: clean up default display search
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Separate the code for finding the default display into a function for
clarity and to make it easier to extend it in the future.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 46 ++++++++++++++++++++------------
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 27d6905683f3..8bfe973e55ec 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2407,6 +2407,34 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev,
return 0;
}
+static struct omap_dss_device *
+omapfb_find_default_display(struct omapfb2_device *fbdev)
+{
+ const char *def_name;
+ int i;
+
+ /* search with the display name from the user or the board file */
+
+ def_name = omapdss_get_default_display_name();
+
+ if (def_name) {
+ for (i = 0; i < fbdev->num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+
+ dssdev = fbdev->displays[i].dssdev;
+
+ if (dssdev->name && strcmp(def_name, dssdev->name) = 0)
+ return dssdev;
+ }
+
+ /* def_name given but not found */
+ return NULL;
+ }
+
+ /* return the first display we have in the list */
+ return fbdev->displays[0].dssdev;
+}
+
static int omapfb_probe(struct platform_device *pdev)
{
struct omapfb2_device *fbdev = NULL;
@@ -2484,23 +2512,7 @@ static int omapfb_probe(struct platform_device *pdev)
for (i = 0; i < fbdev->num_managers; i++)
fbdev->managers[i] = omap_dss_get_overlay_manager(i);
- def_display = NULL;
-
- for (i = 0; i < fbdev->num_displays; ++i) {
- struct omap_dss_device *dssdev;
- const char *def_name;
-
- def_name = omapdss_get_default_display_name();
-
- dssdev = fbdev->displays[i].dssdev;
-
- if (def_name = NULL ||
- (dssdev->name && strcmp(def_name, dssdev->name) = 0)) {
- def_display = dssdev;
- break;
- }
- }
-
+ def_display = omapfb_find_default_display(fbdev);
if (def_display = NULL) {
dev_err(fbdev->dev, "failed to find default display\n");
r = -EPROBE_DEFER;
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 09/26] OMAPFB: search for default display with DT alias
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for "display0" DT alias
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 8bfe973e55ec..961c5c251f63 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2413,7 +2413,10 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
const char *def_name;
int i;
- /* search with the display name from the user or the board file */
+ /*
+ * Search with the display name from the user or the board file,
+ * comparing to display names and aliases
+ */
def_name = omapdss_get_default_display_name();
@@ -2425,12 +2428,30 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
if (dssdev->name && strcmp(def_name, dssdev->name) == 0)
return dssdev;
+
+ if (strcmp(def_name, dssdev->alias) == 0)
+ return dssdev;
}
/* def_name given but not found */
return NULL;
}
+ /* then look for DT alias display0 */
+ for (i = 0; i < fbdev->num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+ int id;
+
+ dssdev = fbdev->displays[i].dssdev;
+
+ if (dssdev->dev->of_node == NULL)
+ continue;
+
+ id = of_alias_get_id(dssdev->dev->of_node, "display");
+ if (id == 0)
+ return dssdev;
+ }
+
/* return the first display we have in the list */
return fbdev->displays[0].dssdev;
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 09/26] OMAPFB: search for default display with DT alias
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Improve the search for the default display in two ways:
* compare the given display name to the display's alias
* if no display name is given, look for "display0" DT alias
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/omapfb/omapfb-main.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/omapfb/omapfb-main.c b/drivers/video/omap2/omapfb/omapfb-main.c
index 8bfe973e55ec..961c5c251f63 100644
--- a/drivers/video/omap2/omapfb/omapfb-main.c
+++ b/drivers/video/omap2/omapfb/omapfb-main.c
@@ -2413,7 +2413,10 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
const char *def_name;
int i;
- /* search with the display name from the user or the board file */
+ /*
+ * Search with the display name from the user or the board file,
+ * comparing to display names and aliases
+ */
def_name = omapdss_get_default_display_name();
@@ -2425,12 +2428,30 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)
if (dssdev->name && strcmp(def_name, dssdev->name) = 0)
return dssdev;
+
+ if (strcmp(def_name, dssdev->alias) = 0)
+ return dssdev;
}
/* def_name given but not found */
return NULL;
}
+ /* then look for DT alias display0 */
+ for (i = 0; i < fbdev->num_displays; ++i) {
+ struct omap_dss_device *dssdev;
+ int id;
+
+ dssdev = fbdev->displays[i].dssdev;
+
+ if (dssdev->dev->of_node = NULL)
+ continue;
+
+ id = of_alias_get_id(dssdev->dev->of_node, "display");
+ if (id = 0)
+ return dssdev;
+ }
+
/* return the first display we have in the list */
return fbdev->displays[0].dssdev;
}
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 10/26] OMAPDSS: add of helpers
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Add helpers to get ports and endpoints from DT data.
While all the functions in dss-of.c might be useful for panel drivers if
they need to parse full port/endpoint data, at the moment we only need a
few of them outside dss-of.c, so only those functions are exported.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dss-of.c | 160 +++++++++++++++++++++++++++++++++++++++
include/video/omapdss.h | 6 ++
3 files changed, 167 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/omap2/dss/dss-of.c
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index d3aa91bdd6a8..8aec8bda27cc 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -1,7 +1,7 @@
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
- output.o
+ output.o dss-of.o
# DSS compat layer files
omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
dispc-compat.o display-sysfs.o
diff --git a/drivers/video/omap2/dss/dss-of.c b/drivers/video/omap2/dss/dss-of.c
new file mode 100644
index 000000000000..9aa61d4bdb3d
--- /dev/null
+++ b/drivers/video/omap2/dss/dss-of.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/seq_file.h>
+
+#include <video/omapdss.h>
+
+#include "dss.h"
+#include "dss_features.h"
+
+static struct device_node *
+omapdss_of_get_next_port(const struct device_node *parent,
+ struct device_node *prev)
+{
+ struct device_node *port = NULL;
+
+ if (!parent)
+ return NULL;
+
+ if (!prev) {
+ struct device_node *ports;
+ /*
+ * It's the first call, we have to find a port subnode
+ * within this node or within an optional 'ports' node.
+ */
+ ports = of_get_child_by_name(parent, "ports");
+ if (ports)
+ parent = ports;
+
+ port = of_get_child_by_name(parent, "port");
+
+ /* release the 'ports' node */
+ of_node_put(ports);
+ } else {
+ struct device_node *ports;
+
+ ports = of_get_parent(prev);
+ if (!ports)
+ return NULL;
+
+ do {
+ port = of_get_next_child(ports, prev);
+ if (!port) {
+ of_node_put(ports);
+ return NULL;
+ }
+ prev = port;
+ } while (of_node_cmp(port->name, "port") != 0);
+ }
+
+ return port;
+}
+
+static struct device_node *
+omapdss_of_get_next_endpoint(const struct device_node *parent,
+ struct device_node *prev)
+{
+ struct device_node *ep = NULL;
+
+ if (!parent)
+ return NULL;
+
+ do {
+ ep = of_get_next_child(parent, prev);
+ if (!ep)
+ return NULL;
+ prev = ep;
+ } while (of_node_cmp(ep->name, "endpoint") != 0);
+
+ return ep;
+}
+
+static struct device_node *
+omapdss_of_get_remote_device_node(const struct device_node *node)
+{
+ struct device_node *np;
+ int i;
+
+ np = of_parse_phandle(node, "remote-endpoint", 0);
+
+ if (!np)
+ return NULL;
+
+ np = of_get_next_parent(np);
+
+ for (i = 0; i < 3 && np; ++i) {
+ struct property *prop;
+
+ prop = of_find_property(np, "compatible", NULL);
+
+ if (prop)
+ return np;
+
+ np = of_get_next_parent(np);
+ }
+
+ return NULL;
+}
+
+struct device_node *
+omapdss_of_get_first_endpoint(const struct device_node *parent)
+{
+ struct device_node *port;
+ struct device_node *ep;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (port) {
+ ep = omapdss_of_get_next_endpoint(port, NULL);
+ of_node_put(port);
+ } else {
+ ep = omapdss_of_get_next_endpoint(parent, NULL);
+ }
+
+ return ep;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
+
+struct omap_dss_device *
+omapdss_of_find_source_for_first_ep(struct device_node *node)
+{
+ struct device_node *ep;
+ struct device_node *src_node;
+ struct omap_dss_device *src;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return ERR_PTR(-EINVAL);
+
+ src_node = omapdss_of_get_remote_device_node(ep);
+
+ of_node_put(ep);
+
+ if (!src_node)
+ return ERR_PTR(-EINVAL);
+
+ src = omap_dss_find_output_by_node(src_node);
+
+ of_node_put(src_node);
+
+ if (!src)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return src;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_find_source_for_first_ep);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 3d7c51a6f9ff..c510591df1b8 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -1019,4 +1019,10 @@ static inline bool omapdss_device_is_enabled(struct omap_dss_device *dssdev)
return dssdev->state == OMAP_DSS_DISPLAY_ACTIVE;
}
+struct device_node *
+omapdss_of_get_first_endpoint(const struct device_node *parent);
+
+struct omap_dss_device *
+omapdss_of_find_source_for_first_ep(struct device_node *node);
+
#endif
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 10/26] OMAPDSS: add of helpers
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Add helpers to get ports and endpoints from DT data.
While all the functions in dss-of.c might be useful for panel drivers if
they need to parse full port/endpoint data, at the moment we only need a
few of them outside dss-of.c, so only those functions are exported.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dss-of.c | 160 +++++++++++++++++++++++++++++++++++++++
include/video/omapdss.h | 6 ++
3 files changed, 167 insertions(+), 1 deletion(-)
create mode 100644 drivers/video/omap2/dss/dss-of.c
diff --git a/drivers/video/omap2/dss/Makefile b/drivers/video/omap2/dss/Makefile
index d3aa91bdd6a8..8aec8bda27cc 100644
--- a/drivers/video/omap2/dss/Makefile
+++ b/drivers/video/omap2/dss/Makefile
@@ -1,7 +1,7 @@
obj-$(CONFIG_OMAP2_DSS) += omapdss.o
# Core DSS files
omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
- output.o
+ output.o dss-of.o
# DSS compat layer files
omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
dispc-compat.o display-sysfs.o
diff --git a/drivers/video/omap2/dss/dss-of.c b/drivers/video/omap2/dss/dss-of.c
new file mode 100644
index 000000000000..9aa61d4bdb3d
--- /dev/null
+++ b/drivers/video/omap2/dss/dss-of.c
@@ -0,0 +1,160 @@
+/*
+ * Copyright (C) 2013 Texas Instruments
+ * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ */
+
+#include <linux/device.h>
+#include <linux/err.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/seq_file.h>
+
+#include <video/omapdss.h>
+
+#include "dss.h"
+#include "dss_features.h"
+
+static struct device_node *
+omapdss_of_get_next_port(const struct device_node *parent,
+ struct device_node *prev)
+{
+ struct device_node *port = NULL;
+
+ if (!parent)
+ return NULL;
+
+ if (!prev) {
+ struct device_node *ports;
+ /*
+ * It's the first call, we have to find a port subnode
+ * within this node or within an optional 'ports' node.
+ */
+ ports = of_get_child_by_name(parent, "ports");
+ if (ports)
+ parent = ports;
+
+ port = of_get_child_by_name(parent, "port");
+
+ /* release the 'ports' node */
+ of_node_put(ports);
+ } else {
+ struct device_node *ports;
+
+ ports = of_get_parent(prev);
+ if (!ports)
+ return NULL;
+
+ do {
+ port = of_get_next_child(ports, prev);
+ if (!port) {
+ of_node_put(ports);
+ return NULL;
+ }
+ prev = port;
+ } while (of_node_cmp(port->name, "port") != 0);
+ }
+
+ return port;
+}
+
+static struct device_node *
+omapdss_of_get_next_endpoint(const struct device_node *parent,
+ struct device_node *prev)
+{
+ struct device_node *ep = NULL;
+
+ if (!parent)
+ return NULL;
+
+ do {
+ ep = of_get_next_child(parent, prev);
+ if (!ep)
+ return NULL;
+ prev = ep;
+ } while (of_node_cmp(ep->name, "endpoint") != 0);
+
+ return ep;
+}
+
+static struct device_node *
+omapdss_of_get_remote_device_node(const struct device_node *node)
+{
+ struct device_node *np;
+ int i;
+
+ np = of_parse_phandle(node, "remote-endpoint", 0);
+
+ if (!np)
+ return NULL;
+
+ np = of_get_next_parent(np);
+
+ for (i = 0; i < 3 && np; ++i) {
+ struct property *prop;
+
+ prop = of_find_property(np, "compatible", NULL);
+
+ if (prop)
+ return np;
+
+ np = of_get_next_parent(np);
+ }
+
+ return NULL;
+}
+
+struct device_node *
+omapdss_of_get_first_endpoint(const struct device_node *parent)
+{
+ struct device_node *port;
+ struct device_node *ep;
+
+ port = omapdss_of_get_next_port(parent, NULL);
+ if (port) {
+ ep = omapdss_of_get_next_endpoint(port, NULL);
+ of_node_put(port);
+ } else {
+ ep = omapdss_of_get_next_endpoint(parent, NULL);
+ }
+
+ return ep;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
+
+struct omap_dss_device *
+omapdss_of_find_source_for_first_ep(struct device_node *node)
+{
+ struct device_node *ep;
+ struct device_node *src_node;
+ struct omap_dss_device *src;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return ERR_PTR(-EINVAL);
+
+ src_node = omapdss_of_get_remote_device_node(ep);
+
+ of_node_put(ep);
+
+ if (!src_node)
+ return ERR_PTR(-EINVAL);
+
+ src = omap_dss_find_output_by_node(src_node);
+
+ of_node_put(src_node);
+
+ if (!src)
+ return ERR_PTR(-EPROBE_DEFER);
+
+ return src;
+}
+EXPORT_SYMBOL_GPL(omapdss_of_find_source_for_first_ep);
diff --git a/include/video/omapdss.h b/include/video/omapdss.h
index 3d7c51a6f9ff..c510591df1b8 100644
--- a/include/video/omapdss.h
+++ b/include/video/omapdss.h
@@ -1019,4 +1019,10 @@ static inline bool omapdss_device_is_enabled(struct omap_dss_device *dssdev)
return dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
}
+struct device_node *
+omapdss_of_get_first_endpoint(const struct device_node *parent);
+
+struct omap_dss_device *
+omapdss_of_find_source_for_first_ep(struct device_node *node);
+
#endif
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 10/26] OMAPDSS: add of helpers
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-11 23:19 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
> Add helpers to get ports and endpoints from DT data.
>
> While all the functions in dss-of.c might be useful for panel drivers if
> they need to parse full port/endpoint data, at the moment we only need a
> few of them outside dss-of.c, so only those functions are exported.
I totally understand that it was easier to add this code to the OMAP DSS
driver, but I believe we should refactor the existing drivers/media/v4l2-
core/v4l2-of.c and move it to a non V4L2-specific location (what about
drivers/media ?) sooner rather than later. That's on my to-do list for
Saturday.
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/Makefile | 2 +-
> drivers/video/omap2/dss/dss-of.c | 160 ++++++++++++++++++++++++++++++++++++
> include/video/omapdss.h | 6 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
> create mode 100644 drivers/video/omap2/dss/dss-of.c
>
> diff --git a/drivers/video/omap2/dss/Makefile
> b/drivers/video/omap2/dss/Makefile index d3aa91bdd6a8..8aec8bda27cc 100644
> --- a/drivers/video/omap2/dss/Makefile
> +++ b/drivers/video/omap2/dss/Makefile
> @@ -1,7 +1,7 @@
> obj-$(CONFIG_OMAP2_DSS) += omapdss.o
> # Core DSS files
> omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
> - output.o
> + output.o dss-of.o
> # DSS compat layer files
> omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
> dispc-compat.o display-sysfs.o
> diff --git a/drivers/video/omap2/dss/dss-of.c
> b/drivers/video/omap2/dss/dss-of.c new file mode 100644
> index 000000000000..9aa61d4bdb3d
> --- /dev/null
> +++ b/drivers/video/omap2/dss/dss-of.c
> @@ -0,0 +1,160 @@
> +/*
> + * Copyright (C) 2013 Texas Instruments
> + * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> General Public License for + * more details.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/seq_file.h>
> +
> +#include <video/omapdss.h>
> +
> +#include "dss.h"
> +#include "dss_features.h"
> +
> +static struct device_node *
> +omapdss_of_get_next_port(const struct device_node *parent,
> + struct device_node *prev)
> +{
> + struct device_node *port = NULL;
> +
> + if (!parent)
> + return NULL;
> +
> + if (!prev) {
> + struct device_node *ports;
> + /*
> + * It's the first call, we have to find a port subnode
> + * within this node or within an optional 'ports' node.
> + */
> + ports = of_get_child_by_name(parent, "ports");
> + if (ports)
> + parent = ports;
> +
> + port = of_get_child_by_name(parent, "port");
> +
> + /* release the 'ports' node */
> + of_node_put(ports);
> + } else {
> + struct device_node *ports;
> +
> + ports = of_get_parent(prev);
> + if (!ports)
> + return NULL;
> +
> + do {
> + port = of_get_next_child(ports, prev);
> + if (!port) {
> + of_node_put(ports);
> + return NULL;
> + }
> + prev = port;
> + } while (of_node_cmp(port->name, "port") != 0);
> + }
> +
> + return port;
> +}
> +
> +static struct device_node *
> +omapdss_of_get_next_endpoint(const struct device_node *parent,
> + struct device_node *prev)
> +{
> + struct device_node *ep = NULL;
> +
> + if (!parent)
> + return NULL;
> +
> + do {
> + ep = of_get_next_child(parent, prev);
> + if (!ep)
> + return NULL;
> + prev = ep;
> + } while (of_node_cmp(ep->name, "endpoint") != 0);
> +
> + return ep;
> +}
> +
> +static struct device_node *
> +omapdss_of_get_remote_device_node(const struct device_node *node)
> +{
> + struct device_node *np;
> + int i;
> +
> + np = of_parse_phandle(node, "remote-endpoint", 0);
> +
> + if (!np)
> + return NULL;
> +
> + np = of_get_next_parent(np);
> +
> + for (i = 0; i < 3 && np; ++i) {
> + struct property *prop;
> +
> + prop = of_find_property(np, "compatible", NULL);
> +
> + if (prop)
> + return np;
> +
> + np = of_get_next_parent(np);
> + }
> +
> + return NULL;
> +}
> +
> +struct device_node *
> +omapdss_of_get_first_endpoint(const struct device_node *parent)
> +{
> + struct device_node *port;
> + struct device_node *ep;
> +
> + port = omapdss_of_get_next_port(parent, NULL);
> + if (port) {
> + ep = omapdss_of_get_next_endpoint(port, NULL);
> + of_node_put(port);
> + } else {
> + ep = omapdss_of_get_next_endpoint(parent, NULL);
> + }
> +
> + return ep;
> +}
> +EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
> +
> +struct omap_dss_device *
> +omapdss_of_find_source_for_first_ep(struct device_node *node)
> +{
> + struct device_node *ep;
> + struct device_node *src_node;
> + struct omap_dss_device *src;
> +
> + ep = omapdss_of_get_first_endpoint(node);
> + if (!ep)
> + return ERR_PTR(-EINVAL);
> +
> + src_node = omapdss_of_get_remote_device_node(ep);
> +
> + of_node_put(ep);
> +
> + if (!src_node)
> + return ERR_PTR(-EINVAL);
> +
> + src = omap_dss_find_output_by_node(src_node);
> +
> + of_node_put(src_node);
> +
> + if (!src)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return src;
> +}
> +EXPORT_SYMBOL_GPL(omapdss_of_find_source_for_first_ep);
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 3d7c51a6f9ff..c510591df1b8 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -1019,4 +1019,10 @@ static inline bool omapdss_device_is_enabled(struct
> omap_dss_device *dssdev) return dssdev->state == OMAP_DSS_DISPLAY_ACTIVE;
> }
>
> +struct device_node *
> +omapdss_of_get_first_endpoint(const struct device_node *parent);
> +
> +struct omap_dss_device *
> +omapdss_of_find_source_for_first_ep(struct device_node *node);
> +
> #endif
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 10/26] OMAPDSS: add of helpers
@ 2013-12-11 23:19 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:19 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
> Add helpers to get ports and endpoints from DT data.
>
> While all the functions in dss-of.c might be useful for panel drivers if
> they need to parse full port/endpoint data, at the moment we only need a
> few of them outside dss-of.c, so only those functions are exported.
I totally understand that it was easier to add this code to the OMAP DSS
driver, but I believe we should refactor the existing drivers/media/v4l2-
core/v4l2-of.c and move it to a non V4L2-specific location (what about
drivers/media ?) sooner rather than later. That's on my to-do list for
Saturday.
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> drivers/video/omap2/dss/Makefile | 2 +-
> drivers/video/omap2/dss/dss-of.c | 160 ++++++++++++++++++++++++++++++++++++
> include/video/omapdss.h | 6 ++
> 3 files changed, 167 insertions(+), 1 deletion(-)
> create mode 100644 drivers/video/omap2/dss/dss-of.c
>
> diff --git a/drivers/video/omap2/dss/Makefile
> b/drivers/video/omap2/dss/Makefile index d3aa91bdd6a8..8aec8bda27cc 100644
> --- a/drivers/video/omap2/dss/Makefile
> +++ b/drivers/video/omap2/dss/Makefile
> @@ -1,7 +1,7 @@
> obj-$(CONFIG_OMAP2_DSS) += omapdss.o
> # Core DSS files
> omapdss-y := core.o dss.o dss_features.o dispc.o dispc_coefs.o display.o \
> - output.o
> + output.o dss-of.o
> # DSS compat layer files
> omapdss-y += manager.o manager-sysfs.o overlay.o overlay-sysfs.o apply.o \
> dispc-compat.o display-sysfs.o
> diff --git a/drivers/video/omap2/dss/dss-of.c
> b/drivers/video/omap2/dss/dss-of.c new file mode 100644
> index 000000000000..9aa61d4bdb3d
> --- /dev/null
> +++ b/drivers/video/omap2/dss/dss-of.c
> @@ -0,0 +1,160 @@
> +/*
> + * Copyright (C) 2013 Texas Instruments
> + * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>
> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful, but
> WITHOUT + * ANY WARRANTY; without even the implied warranty of
> MERCHANTABILITY or + * FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> General Public License for + * more details.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/err.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/seq_file.h>
> +
> +#include <video/omapdss.h>
> +
> +#include "dss.h"
> +#include "dss_features.h"
> +
> +static struct device_node *
> +omapdss_of_get_next_port(const struct device_node *parent,
> + struct device_node *prev)
> +{
> + struct device_node *port = NULL;
> +
> + if (!parent)
> + return NULL;
> +
> + if (!prev) {
> + struct device_node *ports;
> + /*
> + * It's the first call, we have to find a port subnode
> + * within this node or within an optional 'ports' node.
> + */
> + ports = of_get_child_by_name(parent, "ports");
> + if (ports)
> + parent = ports;
> +
> + port = of_get_child_by_name(parent, "port");
> +
> + /* release the 'ports' node */
> + of_node_put(ports);
> + } else {
> + struct device_node *ports;
> +
> + ports = of_get_parent(prev);
> + if (!ports)
> + return NULL;
> +
> + do {
> + port = of_get_next_child(ports, prev);
> + if (!port) {
> + of_node_put(ports);
> + return NULL;
> + }
> + prev = port;
> + } while (of_node_cmp(port->name, "port") != 0);
> + }
> +
> + return port;
> +}
> +
> +static struct device_node *
> +omapdss_of_get_next_endpoint(const struct device_node *parent,
> + struct device_node *prev)
> +{
> + struct device_node *ep = NULL;
> +
> + if (!parent)
> + return NULL;
> +
> + do {
> + ep = of_get_next_child(parent, prev);
> + if (!ep)
> + return NULL;
> + prev = ep;
> + } while (of_node_cmp(ep->name, "endpoint") != 0);
> +
> + return ep;
> +}
> +
> +static struct device_node *
> +omapdss_of_get_remote_device_node(const struct device_node *node)
> +{
> + struct device_node *np;
> + int i;
> +
> + np = of_parse_phandle(node, "remote-endpoint", 0);
> +
> + if (!np)
> + return NULL;
> +
> + np = of_get_next_parent(np);
> +
> + for (i = 0; i < 3 && np; ++i) {
> + struct property *prop;
> +
> + prop = of_find_property(np, "compatible", NULL);
> +
> + if (prop)
> + return np;
> +
> + np = of_get_next_parent(np);
> + }
> +
> + return NULL;
> +}
> +
> +struct device_node *
> +omapdss_of_get_first_endpoint(const struct device_node *parent)
> +{
> + struct device_node *port;
> + struct device_node *ep;
> +
> + port = omapdss_of_get_next_port(parent, NULL);
> + if (port) {
> + ep = omapdss_of_get_next_endpoint(port, NULL);
> + of_node_put(port);
> + } else {
> + ep = omapdss_of_get_next_endpoint(parent, NULL);
> + }
> +
> + return ep;
> +}
> +EXPORT_SYMBOL_GPL(omapdss_of_get_first_endpoint);
> +
> +struct omap_dss_device *
> +omapdss_of_find_source_for_first_ep(struct device_node *node)
> +{
> + struct device_node *ep;
> + struct device_node *src_node;
> + struct omap_dss_device *src;
> +
> + ep = omapdss_of_get_first_endpoint(node);
> + if (!ep)
> + return ERR_PTR(-EINVAL);
> +
> + src_node = omapdss_of_get_remote_device_node(ep);
> +
> + of_node_put(ep);
> +
> + if (!src_node)
> + return ERR_PTR(-EINVAL);
> +
> + src = omap_dss_find_output_by_node(src_node);
> +
> + of_node_put(src_node);
> +
> + if (!src)
> + return ERR_PTR(-EPROBE_DEFER);
> +
> + return src;
> +}
> +EXPORT_SYMBOL_GPL(omapdss_of_find_source_for_first_ep);
> diff --git a/include/video/omapdss.h b/include/video/omapdss.h
> index 3d7c51a6f9ff..c510591df1b8 100644
> --- a/include/video/omapdss.h
> +++ b/include/video/omapdss.h
> @@ -1019,4 +1019,10 @@ static inline bool omapdss_device_is_enabled(struct
> omap_dss_device *dssdev) return dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
> }
>
> +struct device_node *
> +omapdss_of_get_first_endpoint(const struct device_node *parent);
> +
> +struct omap_dss_device *
> +omapdss_of_find_source_for_first_ep(struct device_node *node);
> +
> #endif
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 10/26] OMAPDSS: add of helpers
2013-12-11 23:19 ` Laurent Pinchart
@ 2013-12-12 7:48 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 7:48 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
On 2013-12-12 01:19, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
>> Add helpers to get ports and endpoints from DT data.
>>
>> While all the functions in dss-of.c might be useful for panel drivers if
>> they need to parse full port/endpoint data, at the moment we only need a
>> few of them outside dss-of.c, so only those functions are exported.
>
> I totally understand that it was easier to add this code to the OMAP DSS
> driver, but I believe we should refactor the existing drivers/media/v4l2-
> core/v4l2-of.c and move it to a non V4L2-specific location (what about
> drivers/media ?) sooner rather than later. That's on my to-do list for
> Saturday.
I agree. I just didn't want to go that way yet =).
Have you thought of the API? You had one version in your CDF series, but
I think that was a bit too limited (I don't remember right now how), so
I wrote my own versions.
What I tried to do here is to add simple ways for the drivers to iterate
the ports and endpoints with omapdss_of_get_next_port and
omapdss_of_get_next_endpoint.
But I'm not sure what the use pattern would be. If in most of the cases
the driver always goes through all the ports and all the endpoints, we
could as well have a helper function that goes through all the endpoints
in all the ports, and returns both the port and endpoint for each iteration.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 10/26] OMAPDSS: add of helpers
@ 2013-12-12 7:48 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 7:48 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1441 bytes --]
On 2013-12-12 01:19, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
>> Add helpers to get ports and endpoints from DT data.
>>
>> While all the functions in dss-of.c might be useful for panel drivers if
>> they need to parse full port/endpoint data, at the moment we only need a
>> few of them outside dss-of.c, so only those functions are exported.
>
> I totally understand that it was easier to add this code to the OMAP DSS
> driver, but I believe we should refactor the existing drivers/media/v4l2-
> core/v4l2-of.c and move it to a non V4L2-specific location (what about
> drivers/media ?) sooner rather than later. That's on my to-do list for
> Saturday.
I agree. I just didn't want to go that way yet =).
Have you thought of the API? You had one version in your CDF series, but
I think that was a bit too limited (I don't remember right now how), so
I wrote my own versions.
What I tried to do here is to add simple ways for the drivers to iterate
the ports and endpoints with omapdss_of_get_next_port and
omapdss_of_get_next_endpoint.
But I'm not sure what the use pattern would be. If in most of the cases
the driver always goes through all the ports and all the endpoints, we
could as well have a helper function that goes through all the endpoints
in all the ports, and returns both the port and endpoint for each iteration.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 10/26] OMAPDSS: add of helpers
2013-12-12 7:48 ` Tomi Valkeinen
@ 2013-12-13 2:37 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 2:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
Hi Tomi,
On Thursday 12 December 2013 09:48:30 Tomi Valkeinen wrote:
> On 2013-12-12 01:19, Laurent Pinchart wrote:
> > On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
> >> Add helpers to get ports and endpoints from DT data.
> >>
> >> While all the functions in dss-of.c might be useful for panel drivers if
> >> they need to parse full port/endpoint data, at the moment we only need a
> >> few of them outside dss-of.c, so only those functions are exported.
> >
> > I totally understand that it was easier to add this code to the OMAP DSS
> > driver, but I believe we should refactor the existing drivers/media/v4l2-
> > core/v4l2-of.c and move it to a non V4L2-specific location (what about
> > drivers/media ?) sooner rather than later. That's on my to-do list for
> > Saturday.
>
> I agree. I just didn't want to go that way yet =).
>
> Have you thought of the API? You had one version in your CDF series, but
> I think that was a bit too limited (I don't remember right now how), so
> I wrote my own versions.
>
> What I tried to do here is to add simple ways for the drivers to iterate
> the ports and endpoints with omapdss_of_get_next_port and
> omapdss_of_get_next_endpoint.
>
> But I'm not sure what the use pattern would be. If in most of the cases
> the driver always goes through all the ports and all the endpoints, we
> could as well have a helper function that goes through all the endpoints
> in all the ports, and returns both the port and endpoint for each iteration.
My plan is to keep it simple. I'll take the V4L2 code and add helpers needed
by this patch series and by my Renesas KMS drivers. I'll then see whether
refactoring makes sense, and will post the result. We will then add new
helpers whenever needed on a case by case basis.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 10/26] OMAPDSS: add of helpers
@ 2013-12-13 2:37 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 2:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1816 bytes --]
Hi Tomi,
On Thursday 12 December 2013 09:48:30 Tomi Valkeinen wrote:
> On 2013-12-12 01:19, Laurent Pinchart wrote:
> > On Wednesday 04 December 2013 14:28:37 Tomi Valkeinen wrote:
> >> Add helpers to get ports and endpoints from DT data.
> >>
> >> While all the functions in dss-of.c might be useful for panel drivers if
> >> they need to parse full port/endpoint data, at the moment we only need a
> >> few of them outside dss-of.c, so only those functions are exported.
> >
> > I totally understand that it was easier to add this code to the OMAP DSS
> > driver, but I believe we should refactor the existing drivers/media/v4l2-
> > core/v4l2-of.c and move it to a non V4L2-specific location (what about
> > drivers/media ?) sooner rather than later. That's on my to-do list for
> > Saturday.
>
> I agree. I just didn't want to go that way yet =).
>
> Have you thought of the API? You had one version in your CDF series, but
> I think that was a bit too limited (I don't remember right now how), so
> I wrote my own versions.
>
> What I tried to do here is to add simple ways for the drivers to iterate
> the ports and endpoints with omapdss_of_get_next_port and
> omapdss_of_get_next_endpoint.
>
> But I'm not sure what the use pattern would be. If in most of the cases
> the driver always goes through all the ports and all the endpoints, we
> could as well have a helper function that goes through all the endpoints
> in all the ports, and returns both the port and endpoint for each iteration.
My plan is to keep it simple. I'll take the V4L2 code and add helpers needed
by this patch series and by my Renesas KMS drivers. I'll then see whether
refactoring makes sense, and will post the result. We will then add new
helpers whenever needed on a case by case basis.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 11/26] OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Add the code to make DSS, DISPC, DPI, HDMI and VENC drivers work with
device tree on OMAP3 and OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 7 ++++++
drivers/video/omap2/dss/dpi.c | 50 +++++++++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dss.c | 10 +++++++++
drivers/video/omap2/dss/hdmi4.c | 6 +++++
drivers/video/omap2/dss/venc.c | 34 ++++++++++++++++++++++++++++
5 files changed, 107 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4ec59ca72e5d..b702369fc895 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3744,12 +3744,19 @@ static const struct dev_pm_ops dispc_pm_ops = {
.runtime_resume = dispc_runtime_resume,
};
+static const struct of_device_id dispc_of_match[] = {
+ { .compatible = "ti,omap3-dispc", },
+ { .compatible = "ti,omap4-dispc", },
+ {},
+};
+
static struct platform_driver omap_dispchw_driver = {
.remove = __exit_p(omap_dispchw_remove),
.driver = {
.name = "omapdss_dispc",
.owner = THIS_MODULE,
.pm = &dispc_pm_ops,
+ .of_match_table = dispc_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index bd48cde53561..247b1d524360 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -30,6 +30,7 @@
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/string.h>
+#include <linux/of.h>
#include <video/omapdss.h>
@@ -690,15 +691,57 @@ static void __exit dpi_uninit_output(struct platform_device *pdev)
omapdss_unregister_output(out);
}
+static int dpi_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *ep;
+ u32 datalines;
+ int r;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ r = of_property_read_u32(ep, "data-lines", &datalines);
+ if (r) {
+ DSSERR("failed to parse datalines\n");
+ goto err;
+ }
+
+ dpi.data_lines = datalines;
+
+ of_node_put(ep);
+
+ return 0;
+err:
+ of_node_put(ep);
+
+ return r;
+}
+
static int omap_dpi_probe(struct platform_device *pdev)
{
+ int r;
+
dpi.pdev = pdev;
mutex_init(&dpi.lock);
dpi_init_output(pdev);
+ if (pdev->dev.of_node) {
+ r = dpi_probe_of(pdev);
+ if (r) {
+ DSSERR("Invalid DT data\n");
+ goto err_probe_of;
+ }
+ }
+
return 0;
+
+err_probe_of:
+ dpi_uninit_output(pdev);
+ return r;
}
static int __exit omap_dpi_remove(struct platform_device *pdev)
@@ -708,12 +751,19 @@ static int __exit omap_dpi_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id dpi_of_match[] = {
+ { .compatible = "ti,omap3-dpi", },
+ { .compatible = "ti,omap4-dpi", },
+ {},
+};
+
static struct platform_driver omap_dpi_driver = {
.probe = omap_dpi_probe,
.remove = __exit_p(omap_dpi_remove),
.driver = {
.name = "omapdss_dpi",
.owner = THIS_MODULE,
+ .of_match_table = dpi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index bd01608e67e2..d0d61b11c01e 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -23,6 +23,7 @@
#define DSS_SUBSYS_NAME "DSS"
#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/io.h>
#include <linux/export.h>
#include <linux/err.h>
@@ -955,12 +956,21 @@ static const struct dev_pm_ops dss_pm_ops = {
.runtime_resume = dss_runtime_resume,
};
+static const struct of_device_id dss_of_match[] = {
+ { .compatible = "ti,omap3-dss", },
+ { .compatible = "ti,omap4-dss", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dss_of_match);
+
static struct platform_driver omap_dsshw_driver = {
.remove = __exit_p(omap_dsshw_remove),
.driver = {
.name = "omapdss_dss",
.owner = THIS_MODULE,
.pm = &dss_pm_ops,
+ .of_match_table = dss_of_match,
},
};
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index 16e598787522..97dd05f602f7 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -671,6 +671,11 @@ static const struct dev_pm_ops hdmi_pm_ops = {
.runtime_resume = hdmi_runtime_resume,
};
+static const struct of_device_id hdmi_of_match[] = {
+ { .compatible = "ti,omap4-hdmi", },
+ {},
+};
+
static struct platform_driver omapdss_hdmihw_driver = {
.probe = omapdss_hdmihw_probe,
.remove = __exit_p(omapdss_hdmihw_remove),
@@ -678,6 +683,7 @@ static struct platform_driver omapdss_hdmihw_driver = {
.name = "omapdss_hdmi",
.owner = THIS_MODULE,
.pm = &hdmi_pm_ops,
+ .of_match_table = hdmi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 5f88ac47b7fa..12185fb6da0e 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -34,6 +34,7 @@
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
#include <video/omapdss.h>
@@ -804,6 +805,22 @@ static void __exit venc_uninit_output(struct platform_device *pdev)
omapdss_unregister_output(out);
}
+static int venc_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *ep;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ venc.invert_polarity = of_property_read_bool(ep, "invert-polarity");
+
+ of_node_put(ep);
+
+ return 0;
+}
+
/* VENC HW IP initialisation */
static int omap_venchw_probe(struct platform_device *pdev)
{
@@ -845,12 +862,21 @@ static int omap_venchw_probe(struct platform_device *pdev)
venc_runtime_put();
+ if (pdev->dev.of_node) {
+ r = venc_probe_of(pdev);
+ if (r) {
+ DSSERR("Invalid DT data\n");
+ goto err_probe_of;
+ }
+ }
+
dss_debugfs_create_file("venc", venc_dump_regs);
venc_init_output(pdev);
return 0;
+err_probe_of:
err_runtime_get:
pm_runtime_disable(&pdev->dev);
return r;
@@ -894,6 +920,13 @@ static const struct dev_pm_ops venc_pm_ops = {
.runtime_resume = venc_runtime_resume,
};
+
+static const struct of_device_id venc_of_match[] = {
+ { .compatible = "ti,omap3-venc", },
+ { .compatible = "ti,omap4-venc", },
+ {},
+};
+
static struct platform_driver omap_venchw_driver = {
.probe = omap_venchw_probe,
.remove = __exit_p(omap_venchw_remove),
@@ -901,6 +934,7 @@ static struct platform_driver omap_venchw_driver = {
.name = "omapdss_venc",
.owner = THIS_MODULE,
.pm = &venc_pm_ops,
+ .of_match_table = venc_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 11/26] OMAPDSS: Add DT support to DSS, DISPC, DPI, HDMI, VENC
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Add the code to make DSS, DISPC, DPI, HDMI and VENC drivers work with
device tree on OMAP3 and OMAP4.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dispc.c | 7 ++++++
drivers/video/omap2/dss/dpi.c | 50 +++++++++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dss.c | 10 +++++++++
drivers/video/omap2/dss/hdmi4.c | 6 +++++
drivers/video/omap2/dss/venc.c | 34 ++++++++++++++++++++++++++++
5 files changed, 107 insertions(+)
diff --git a/drivers/video/omap2/dss/dispc.c b/drivers/video/omap2/dss/dispc.c
index 4ec59ca72e5d..b702369fc895 100644
--- a/drivers/video/omap2/dss/dispc.c
+++ b/drivers/video/omap2/dss/dispc.c
@@ -3744,12 +3744,19 @@ static const struct dev_pm_ops dispc_pm_ops = {
.runtime_resume = dispc_runtime_resume,
};
+static const struct of_device_id dispc_of_match[] = {
+ { .compatible = "ti,omap3-dispc", },
+ { .compatible = "ti,omap4-dispc", },
+ {},
+};
+
static struct platform_driver omap_dispchw_driver = {
.remove = __exit_p(omap_dispchw_remove),
.driver = {
.name = "omapdss_dispc",
.owner = THIS_MODULE,
.pm = &dispc_pm_ops,
+ .of_match_table = dispc_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dpi.c b/drivers/video/omap2/dss/dpi.c
index bd48cde53561..247b1d524360 100644
--- a/drivers/video/omap2/dss/dpi.c
+++ b/drivers/video/omap2/dss/dpi.c
@@ -30,6 +30,7 @@
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/string.h>
+#include <linux/of.h>
#include <video/omapdss.h>
@@ -690,15 +691,57 @@ static void __exit dpi_uninit_output(struct platform_device *pdev)
omapdss_unregister_output(out);
}
+static int dpi_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *ep;
+ u32 datalines;
+ int r;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ r = of_property_read_u32(ep, "data-lines", &datalines);
+ if (r) {
+ DSSERR("failed to parse datalines\n");
+ goto err;
+ }
+
+ dpi.data_lines = datalines;
+
+ of_node_put(ep);
+
+ return 0;
+err:
+ of_node_put(ep);
+
+ return r;
+}
+
static int omap_dpi_probe(struct platform_device *pdev)
{
+ int r;
+
dpi.pdev = pdev;
mutex_init(&dpi.lock);
dpi_init_output(pdev);
+ if (pdev->dev.of_node) {
+ r = dpi_probe_of(pdev);
+ if (r) {
+ DSSERR("Invalid DT data\n");
+ goto err_probe_of;
+ }
+ }
+
return 0;
+
+err_probe_of:
+ dpi_uninit_output(pdev);
+ return r;
}
static int __exit omap_dpi_remove(struct platform_device *pdev)
@@ -708,12 +751,19 @@ static int __exit omap_dpi_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id dpi_of_match[] = {
+ { .compatible = "ti,omap3-dpi", },
+ { .compatible = "ti,omap4-dpi", },
+ {},
+};
+
static struct platform_driver omap_dpi_driver = {
.probe = omap_dpi_probe,
.remove = __exit_p(omap_dpi_remove),
.driver = {
.name = "omapdss_dpi",
.owner = THIS_MODULE,
+ .of_match_table = dpi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/dss.c b/drivers/video/omap2/dss/dss.c
index bd01608e67e2..d0d61b11c01e 100644
--- a/drivers/video/omap2/dss/dss.c
+++ b/drivers/video/omap2/dss/dss.c
@@ -23,6 +23,7 @@
#define DSS_SUBSYS_NAME "DSS"
#include <linux/kernel.h>
+#include <linux/module.h>
#include <linux/io.h>
#include <linux/export.h>
#include <linux/err.h>
@@ -955,12 +956,21 @@ static const struct dev_pm_ops dss_pm_ops = {
.runtime_resume = dss_runtime_resume,
};
+static const struct of_device_id dss_of_match[] = {
+ { .compatible = "ti,omap3-dss", },
+ { .compatible = "ti,omap4-dss", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dss_of_match);
+
static struct platform_driver omap_dsshw_driver = {
.remove = __exit_p(omap_dsshw_remove),
.driver = {
.name = "omapdss_dss",
.owner = THIS_MODULE,
.pm = &dss_pm_ops,
+ .of_match_table = dss_of_match,
},
};
diff --git a/drivers/video/omap2/dss/hdmi4.c b/drivers/video/omap2/dss/hdmi4.c
index 16e598787522..97dd05f602f7 100644
--- a/drivers/video/omap2/dss/hdmi4.c
+++ b/drivers/video/omap2/dss/hdmi4.c
@@ -671,6 +671,11 @@ static const struct dev_pm_ops hdmi_pm_ops = {
.runtime_resume = hdmi_runtime_resume,
};
+static const struct of_device_id hdmi_of_match[] = {
+ { .compatible = "ti,omap4-hdmi", },
+ {},
+};
+
static struct platform_driver omapdss_hdmihw_driver = {
.probe = omapdss_hdmihw_probe,
.remove = __exit_p(omapdss_hdmihw_remove),
@@ -678,6 +683,7 @@ static struct platform_driver omapdss_hdmihw_driver = {
.name = "omapdss_hdmi",
.owner = THIS_MODULE,
.pm = &hdmi_pm_ops,
+ .of_match_table = hdmi_of_match,
},
};
diff --git a/drivers/video/omap2/dss/venc.c b/drivers/video/omap2/dss/venc.c
index 5f88ac47b7fa..12185fb6da0e 100644
--- a/drivers/video/omap2/dss/venc.c
+++ b/drivers/video/omap2/dss/venc.c
@@ -34,6 +34,7 @@
#include <linux/platform_device.h>
#include <linux/regulator/consumer.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
#include <video/omapdss.h>
@@ -804,6 +805,22 @@ static void __exit venc_uninit_output(struct platform_device *pdev)
omapdss_unregister_output(out);
}
+static int venc_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct device_node *ep;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ venc.invert_polarity = of_property_read_bool(ep, "invert-polarity");
+
+ of_node_put(ep);
+
+ return 0;
+}
+
/* VENC HW IP initialisation */
static int omap_venchw_probe(struct platform_device *pdev)
{
@@ -845,12 +862,21 @@ static int omap_venchw_probe(struct platform_device *pdev)
venc_runtime_put();
+ if (pdev->dev.of_node) {
+ r = venc_probe_of(pdev);
+ if (r) {
+ DSSERR("Invalid DT data\n");
+ goto err_probe_of;
+ }
+ }
+
dss_debugfs_create_file("venc", venc_dump_regs);
venc_init_output(pdev);
return 0;
+err_probe_of:
err_runtime_get:
pm_runtime_disable(&pdev->dev);
return r;
@@ -894,6 +920,13 @@ static const struct dev_pm_ops venc_pm_ops = {
.runtime_resume = venc_runtime_resume,
};
+
+static const struct of_device_id venc_of_match[] = {
+ { .compatible = "ti,omap3-venc", },
+ { .compatible = "ti,omap4-venc", },
+ {},
+};
+
static struct platform_driver omap_venchw_driver = {
.probe = omap_venchw_probe,
.remove = __exit_p(omap_venchw_remove),
@@ -901,6 +934,7 @@ static struct platform_driver omap_venchw_driver = {
.name = "omapdss_venc",
.owner = THIS_MODULE,
.pm = &venc_pm_ops,
+ .of_match_table = venc_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 12/26] OMAPDSS: Add DT support to DSI
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4.
A minor hack is needed at the moment in the DSI driver: the DSS driver
needs to know the ID number of a DSI device, as clocks are routed in
different ways to the DSI devices. At the moment we don't have any
proper way to manage this, so this patchs adds a simple lookup table
that is used to deduce the ID from the DSI device's base address.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 136 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 135 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 18b5e84165bb..46edec82c502 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -38,6 +38,8 @@
#include <linux/slab.h>
#include <linux/debugfs.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
#include <video/omapdss.h>
#include <video/mipi_display.h>
@@ -374,6 +376,13 @@ struct dsi_packet_sent_handler_data {
struct completion *completion;
};
+struct dsi_module_id_data {
+ u32 address;
+ int id;
+};
+
+static const struct of_device_id dsi_of_match[];
+
#ifdef DSI_PERF_MEASURE
static bool dsi_perf;
module_param(dsi_perf, bool, 0644);
@@ -5336,6 +5345,62 @@ static void dsi_uninit_output(struct platform_device *dsidev)
omapdss_unregister_output(out);
}
+static int dsi_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct dsi_data *dsi = dsi_get_dsidrv_data(pdev);
+ struct property *prop;
+ u32 lane_arr[10];
+ int len, num_pins;
+ int r, i;
+ struct device_node *ep;
+ struct omap_dsi_pin_config pin_cfg;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ prop = of_find_property(ep, "lanes", &len);
+ if (prop == NULL) {
+ dev_err(&pdev->dev, "failed to find lane data\n");
+ r = -EINVAL;
+ goto err;
+ }
+
+ num_pins = len / sizeof(u32);
+
+ if (num_pins < 4 || num_pins % 2 != 0
+ || num_pins > dsi->num_lanes_supported * 2) {
+ dev_err(&pdev->dev, "bad number of lanes\n");
+ r = -EINVAL;
+ goto err;
+ }
+
+ r = of_property_read_u32_array(ep, "lanes", lane_arr, num_pins);
+ if (r) {
+ dev_err(&pdev->dev, "failed to read lane data\n");
+ goto err;
+ }
+
+ pin_cfg.num_pins = num_pins;
+ for (i = 0; i < num_pins; ++i)
+ pin_cfg.pins[i] = (int)lane_arr[i];
+
+ r = dsi_configure_pins(&dsi->output, &pin_cfg);
+ if (r) {
+ dev_err(&pdev->dev, "failed to configure pins");
+ goto err;
+ }
+
+ of_node_put(ep);
+
+ return 0;
+
+err:
+ of_node_put(ep);
+ return r;
+}
+
/* DSI1 HW IP initialisation */
static int omap_dsihw_probe(struct platform_device *dsidev)
{
@@ -5348,7 +5413,6 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
if (!dsi)
return -ENOMEM;
- dsi->module_id = dsidev->id;
dsi->pdev = dsidev;
dev_set_drvdata(&dsidev->dev, dsi);
@@ -5398,6 +5462,31 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
return r;
}
+ if (dsidev->dev.of_node) {
+ const struct of_device_id *match;
+ const struct dsi_module_id_data *d;
+
+ match = of_match_node(dsi_of_match, dsidev->dev.of_node);
+ if (!match) {
+ DSSERR("unsupported DSI module\n");
+ return -ENODEV;
+ }
+
+ d = match->data;
+
+ while (d->address != 0 && d->address != dsi_mem->start)
+ d++;
+
+ if (d->address == 0) {
+ DSSERR("unsupported DSI module\n");
+ return -ENODEV;
+ }
+
+ dsi->module_id = d->id;
+ } else {
+ dsi->module_id = dsidev->id;
+ }
+
/* DSI VCs initialization */
for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
dsi->vc[i].source = DSI_VC_SOURCE_L4;
@@ -5433,6 +5522,19 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
dsi_init_output(dsidev);
+ if (dsidev->dev.of_node) {
+ r = dsi_probe_of(dsidev);
+ if (r) {
+ DSSERR("Invalid DSI DT data\n");
+ goto err_probe_of;
+ }
+
+ r = of_platform_populate(dsidev->dev.of_node, NULL, NULL,
+ &dsidev->dev);
+ if (r)
+ DSSERR("Failed to populate DSI child devices: %d\n", r);
+ }
+
dsi_runtime_put(dsidev);
if (dsi->module_id == 0)
@@ -5446,17 +5548,31 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
else if (dsi->module_id == 1)
dss_debugfs_create_file("dsi2_irqs", dsi2_dump_irqs);
#endif
+
return 0;
+err_probe_of:
+ dsi_uninit_output(dsidev);
+ dsi_runtime_put(dsidev);
+
err_runtime_get:
pm_runtime_disable(&dsidev->dev);
return r;
}
+static int dsi_unregister_child(struct device *dev, void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ platform_device_unregister(pdev);
+ return 0;
+}
+
static int __exit omap_dsihw_remove(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ device_for_each_child(&dsidev->dev, NULL, dsi_unregister_child);
+
WARN_ON(dsi->scp_clk_refcount > 0);
dsi_uninit_output(dsidev);
@@ -5494,6 +5610,23 @@ static const struct dev_pm_ops dsi_pm_ops = {
.runtime_resume = dsi_runtime_resume,
};
+static const struct dsi_module_id_data dsi_of_data_omap3[] = {
+ { .address = 0x4804fc00, .id = 0, },
+ { },
+};
+
+static const struct dsi_module_id_data dsi_of_data_omap4[] = {
+ { .address = 0x58004000, .id = 0, },
+ { .address = 0x58005000, .id = 1, },
+ { },
+};
+
+static const struct of_device_id dsi_of_match[] = {
+ { .compatible = "ti,omap3-dsi", .data = dsi_of_data_omap3, },
+ { .compatible = "ti,omap4-dsi", .data = dsi_of_data_omap4, },
+ {},
+};
+
static struct platform_driver omap_dsihw_driver = {
.probe = omap_dsihw_probe,
.remove = __exit_p(omap_dsihw_remove),
@@ -5501,6 +5634,7 @@ static struct platform_driver omap_dsihw_driver = {
.name = "omapdss_dsi",
.owner = THIS_MODULE,
.pm = &dsi_pm_ops,
+ .of_match_table = dsi_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 12/26] OMAPDSS: Add DT support to DSI
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4.
A minor hack is needed at the moment in the DSI driver: the DSS driver
needs to know the ID number of a DSI device, as clocks are routed in
different ways to the DSI devices. At the moment we don't have any
proper way to manage this, so this patchs adds a simple lookup table
that is used to deduce the ID from the DSI device's base address.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/dss/dsi.c | 136 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 135 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/dss/dsi.c b/drivers/video/omap2/dss/dsi.c
index 18b5e84165bb..46edec82c502 100644
--- a/drivers/video/omap2/dss/dsi.c
+++ b/drivers/video/omap2/dss/dsi.c
@@ -38,6 +38,8 @@
#include <linux/slab.h>
#include <linux/debugfs.h>
#include <linux/pm_runtime.h>
+#include <linux/of.h>
+#include <linux/of_platform.h>
#include <video/omapdss.h>
#include <video/mipi_display.h>
@@ -374,6 +376,13 @@ struct dsi_packet_sent_handler_data {
struct completion *completion;
};
+struct dsi_module_id_data {
+ u32 address;
+ int id;
+};
+
+static const struct of_device_id dsi_of_match[];
+
#ifdef DSI_PERF_MEASURE
static bool dsi_perf;
module_param(dsi_perf, bool, 0644);
@@ -5336,6 +5345,62 @@ static void dsi_uninit_output(struct platform_device *dsidev)
omapdss_unregister_output(out);
}
+static int dsi_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct dsi_data *dsi = dsi_get_dsidrv_data(pdev);
+ struct property *prop;
+ u32 lane_arr[10];
+ int len, num_pins;
+ int r, i;
+ struct device_node *ep;
+ struct omap_dsi_pin_config pin_cfg;
+
+ ep = omapdss_of_get_first_endpoint(node);
+ if (!ep)
+ return 0;
+
+ prop = of_find_property(ep, "lanes", &len);
+ if (prop = NULL) {
+ dev_err(&pdev->dev, "failed to find lane data\n");
+ r = -EINVAL;
+ goto err;
+ }
+
+ num_pins = len / sizeof(u32);
+
+ if (num_pins < 4 || num_pins % 2 != 0
+ || num_pins > dsi->num_lanes_supported * 2) {
+ dev_err(&pdev->dev, "bad number of lanes\n");
+ r = -EINVAL;
+ goto err;
+ }
+
+ r = of_property_read_u32_array(ep, "lanes", lane_arr, num_pins);
+ if (r) {
+ dev_err(&pdev->dev, "failed to read lane data\n");
+ goto err;
+ }
+
+ pin_cfg.num_pins = num_pins;
+ for (i = 0; i < num_pins; ++i)
+ pin_cfg.pins[i] = (int)lane_arr[i];
+
+ r = dsi_configure_pins(&dsi->output, &pin_cfg);
+ if (r) {
+ dev_err(&pdev->dev, "failed to configure pins");
+ goto err;
+ }
+
+ of_node_put(ep);
+
+ return 0;
+
+err:
+ of_node_put(ep);
+ return r;
+}
+
/* DSI1 HW IP initialisation */
static int omap_dsihw_probe(struct platform_device *dsidev)
{
@@ -5348,7 +5413,6 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
if (!dsi)
return -ENOMEM;
- dsi->module_id = dsidev->id;
dsi->pdev = dsidev;
dev_set_drvdata(&dsidev->dev, dsi);
@@ -5398,6 +5462,31 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
return r;
}
+ if (dsidev->dev.of_node) {
+ const struct of_device_id *match;
+ const struct dsi_module_id_data *d;
+
+ match = of_match_node(dsi_of_match, dsidev->dev.of_node);
+ if (!match) {
+ DSSERR("unsupported DSI module\n");
+ return -ENODEV;
+ }
+
+ d = match->data;
+
+ while (d->address != 0 && d->address != dsi_mem->start)
+ d++;
+
+ if (d->address = 0) {
+ DSSERR("unsupported DSI module\n");
+ return -ENODEV;
+ }
+
+ dsi->module_id = d->id;
+ } else {
+ dsi->module_id = dsidev->id;
+ }
+
/* DSI VCs initialization */
for (i = 0; i < ARRAY_SIZE(dsi->vc); i++) {
dsi->vc[i].source = DSI_VC_SOURCE_L4;
@@ -5433,6 +5522,19 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
dsi_init_output(dsidev);
+ if (dsidev->dev.of_node) {
+ r = dsi_probe_of(dsidev);
+ if (r) {
+ DSSERR("Invalid DSI DT data\n");
+ goto err_probe_of;
+ }
+
+ r = of_platform_populate(dsidev->dev.of_node, NULL, NULL,
+ &dsidev->dev);
+ if (r)
+ DSSERR("Failed to populate DSI child devices: %d\n", r);
+ }
+
dsi_runtime_put(dsidev);
if (dsi->module_id = 0)
@@ -5446,17 +5548,31 @@ static int omap_dsihw_probe(struct platform_device *dsidev)
else if (dsi->module_id = 1)
dss_debugfs_create_file("dsi2_irqs", dsi2_dump_irqs);
#endif
+
return 0;
+err_probe_of:
+ dsi_uninit_output(dsidev);
+ dsi_runtime_put(dsidev);
+
err_runtime_get:
pm_runtime_disable(&dsidev->dev);
return r;
}
+static int dsi_unregister_child(struct device *dev, void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ platform_device_unregister(pdev);
+ return 0;
+}
+
static int __exit omap_dsihw_remove(struct platform_device *dsidev)
{
struct dsi_data *dsi = dsi_get_dsidrv_data(dsidev);
+ device_for_each_child(&dsidev->dev, NULL, dsi_unregister_child);
+
WARN_ON(dsi->scp_clk_refcount > 0);
dsi_uninit_output(dsidev);
@@ -5494,6 +5610,23 @@ static const struct dev_pm_ops dsi_pm_ops = {
.runtime_resume = dsi_runtime_resume,
};
+static const struct dsi_module_id_data dsi_of_data_omap3[] = {
+ { .address = 0x4804fc00, .id = 0, },
+ { },
+};
+
+static const struct dsi_module_id_data dsi_of_data_omap4[] = {
+ { .address = 0x58004000, .id = 0, },
+ { .address = 0x58005000, .id = 1, },
+ { },
+};
+
+static const struct of_device_id dsi_of_match[] = {
+ { .compatible = "ti,omap3-dsi", .data = dsi_of_data_omap3, },
+ { .compatible = "ti,omap4-dsi", .data = dsi_of_data_omap4, },
+ {},
+};
+
static struct platform_driver omap_dsihw_driver = {
.probe = omap_dsihw_probe,
.remove = __exit_p(omap_dsihw_remove),
@@ -5501,6 +5634,7 @@ static struct platform_driver omap_dsihw_driver = {
.name = "omapdss_dsi",
.owner = THIS_MODULE,
.pm = &dsi_pm_ops,
+ .of_match_table = dsi_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f3a0c26ed0c2..6fc163201cbd 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -588,5 +588,48 @@
num-eps = <16>;
ram-bits = <12>;
};
+
+ dss@48050000 {
+ compatible = "ti,omap3-dss", "simple-bus";
+ reg = <0x48050000 0x200>;
+ ti,hwmods = "dss_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@48050400 {
+ compatible = "ti,omap3-dispc";
+ reg = <0x48050400 0x400>;
+ interrupts = <25>;
+ ti,hwmods = "dss_dispc";
+ };
+
+ dpi: encoder@0 {
+ compatible = "ti,omap3-dpi";
+ };
+
+ sdi: encoder@1 {
+ compatible = "ti,omap3-sdi";
+ };
+
+ dsi: encoder@4804fc00 {
+ compatible = "ti,omap3-dsi";
+ reg = <0x4804fc00 0x400>;
+ interrupts = <25>;
+ ti,hwmods = "dss_dsi1";
+ };
+
+ rfbi: encoder@48050800 {
+ compatible = "ti,omap3-rfbi";
+ reg = <0x48050800 0x100>;
+ ti,hwmods = "dss_rfbi";
+ };
+
+ venc: encoder@48050c00 {
+ compatible = "ti,omap3-venc";
+ reg = <0x48050c00 0x100>;
+ ti,hwmods = "dss_venc";
+ };
+ };
};
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
index f3a0c26ed0c2..6fc163201cbd 100644
--- a/arch/arm/boot/dts/omap3.dtsi
+++ b/arch/arm/boot/dts/omap3.dtsi
@@ -588,5 +588,48 @@
num-eps = <16>;
ram-bits = <12>;
};
+
+ dss@48050000 {
+ compatible = "ti,omap3-dss", "simple-bus";
+ reg = <0x48050000 0x200>;
+ ti,hwmods = "dss_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@48050400 {
+ compatible = "ti,omap3-dispc";
+ reg = <0x48050400 0x400>;
+ interrupts = <25>;
+ ti,hwmods = "dss_dispc";
+ };
+
+ dpi: encoder@0 {
+ compatible = "ti,omap3-dpi";
+ };
+
+ sdi: encoder@1 {
+ compatible = "ti,omap3-sdi";
+ };
+
+ dsi: encoder@4804fc00 {
+ compatible = "ti,omap3-dsi";
+ reg = <0x4804fc00 0x400>;
+ interrupts = <25>;
+ ti,hwmods = "dss_dsi1";
+ };
+
+ rfbi: encoder@48050800 {
+ compatible = "ti,omap3-rfbi";
+ reg = <0x48050800 0x100>;
+ ti,hwmods = "dss_rfbi";
+ };
+
+ venc: encoder@48050c00 {
+ compatible = "ti,omap3-venc";
+ reg = <0x48050c00 0x100>;
+ ti,hwmods = "dss_venc";
+ };
+ };
};
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-05 17:05 ` Tony Lindgren
-1 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-05 17:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja, Darren Etheridge
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
Description missing.. But other than that can you please check that
the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
the hwmod data from device" works with this?
The test to do is to remove the related reg, interrupt and dma entries
from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
from DT properly.
I don't know if it makes sense to have them as children of dss_core, they
really all seem to be completely independent devices?
BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
property and do the lookup based on the compatible property instead ;)
So from that point of view we need to get the device mapping right in
the .dtsi files, and don't want to start mixing up separate devices into
single .dtsi entry.
Regards,
Tony
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap3.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index f3a0c26ed0c2..6fc163201cbd 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -588,5 +588,48 @@
> num-eps = <16>;
> ram-bits = <12>;
> };
> +
> + dss@48050000 {
> + compatible = "ti,omap3-dss", "simple-bus";
> + reg = <0x48050000 0x200>;
> + ti,hwmods = "dss_core";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + dispc@48050400 {
> + compatible = "ti,omap3-dispc";
> + reg = <0x48050400 0x400>;
> + interrupts = <25>;
> + ti,hwmods = "dss_dispc";
> + };
> +
> + dpi: encoder@0 {
> + compatible = "ti,omap3-dpi";
> + };
> +
> + sdi: encoder@1 {
> + compatible = "ti,omap3-sdi";
> + };
> +
> + dsi: encoder@4804fc00 {
> + compatible = "ti,omap3-dsi";
> + reg = <0x4804fc00 0x400>;
> + interrupts = <25>;
> + ti,hwmods = "dss_dsi1";
> + };
> +
> + rfbi: encoder@48050800 {
> + compatible = "ti,omap3-rfbi";
> + reg = <0x48050800 0x100>;
> + ti,hwmods = "dss_rfbi";
> + };
> +
> + venc: encoder@48050c00 {
> + compatible = "ti,omap3-venc";
> + reg = <0x48050c00 0x100>;
> + ti,hwmods = "dss_venc";
> + };
> + };
> };
> };
> --
> 1.8.3.2
>
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-05 17:05 ` Tony Lindgren
0 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-05 17:05 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja, Darren Etheridge
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
Description missing.. But other than that can you please check that
the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
the hwmod data from device" works with this?
The test to do is to remove the related reg, interrupt and dma entries
from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
from DT properly.
I don't know if it makes sense to have them as children of dss_core, they
really all seem to be completely independent devices?
BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
property and do the lookup based on the compatible property instead ;)
So from that point of view we need to get the device mapping right in
the .dtsi files, and don't want to start mixing up separate devices into
single .dtsi entry.
Regards,
Tony
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap3.dtsi | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3.dtsi b/arch/arm/boot/dts/omap3.dtsi
> index f3a0c26ed0c2..6fc163201cbd 100644
> --- a/arch/arm/boot/dts/omap3.dtsi
> +++ b/arch/arm/boot/dts/omap3.dtsi
> @@ -588,5 +588,48 @@
> num-eps = <16>;
> ram-bits = <12>;
> };
> +
> + dss@48050000 {
> + compatible = "ti,omap3-dss", "simple-bus";
> + reg = <0x48050000 0x200>;
> + ti,hwmods = "dss_core";
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> +
> + dispc@48050400 {
> + compatible = "ti,omap3-dispc";
> + reg = <0x48050400 0x400>;
> + interrupts = <25>;
> + ti,hwmods = "dss_dispc";
> + };
> +
> + dpi: encoder@0 {
> + compatible = "ti,omap3-dpi";
> + };
> +
> + sdi: encoder@1 {
> + compatible = "ti,omap3-sdi";
> + };
> +
> + dsi: encoder@4804fc00 {
> + compatible = "ti,omap3-dsi";
> + reg = <0x4804fc00 0x400>;
> + interrupts = <25>;
> + ti,hwmods = "dss_dsi1";
> + };
> +
> + rfbi: encoder@48050800 {
> + compatible = "ti,omap3-rfbi";
> + reg = <0x48050800 0x100>;
> + ti,hwmods = "dss_rfbi";
> + };
> +
> + venc: encoder@48050c00 {
> + compatible = "ti,omap3-venc";
> + reg = <0x48050c00 0x100>;
> + ti,hwmods = "dss_venc";
> + };
> + };
> };
> };
> --
> 1.8.3.2
>
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-05 17:05 ` Tony Lindgren
@ 2013-12-09 12:45 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-09 12:45 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
On 2013-12-05 19:05, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
>
> Description missing.. But other than that can you please check that
> the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> the hwmod data from device" works with this?
>
> The test to do is to remove the related reg, interrupt and dma entries
> from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
> from DT properly.
I made a quick test with panda, by applying your patch and reverting
b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
the DISPC IRQ, but that worked fine.
> I don't know if it makes sense to have them as children of dss_core, they
> really all seem to be completely independent devices?
The DSS subdevices depend on the dss_core. dss_core has to be powered up
for any of the subdevices to work. This is done automatically by the
runtime PM when the subdevices are children of the dss_core.
> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> property and do the lookup based on the compatible property instead ;)
> So from that point of view we need to get the device mapping right in
> the .dtsi files, and don't want to start mixing up separate devices into
> single .dtsi entry.
Hmm, was that just a general comment, or something that affects the DSS
DT data I have in my patch? As far as I understand, the DSS nodes
reflect the current hwmods correctly.
With the exception that DPI and SDI do not have a matching hwmod, as
they are really part of dss_core/dispc. They are separate nodes as they
are "video outputs" the same way as the other subnodes.
I could perhaps remove the DPI and SDI nodes, and have them as direct
video ports from DISPC, but... That's easier said than done.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-09 12:45 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-09 12:45 UTC (permalink / raw)
To: Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 1858 bytes --]
On 2013-12-05 19:05, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
>
> Description missing.. But other than that can you please check that
> the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> the hwmod data from device" works with this?
>
> The test to do is to remove the related reg, interrupt and dma entries
> from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
> from DT properly.
I made a quick test with panda, by applying your patch and reverting
b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
the DISPC IRQ, but that worked fine.
> I don't know if it makes sense to have them as children of dss_core, they
> really all seem to be completely independent devices?
The DSS subdevices depend on the dss_core. dss_core has to be powered up
for any of the subdevices to work. This is done automatically by the
runtime PM when the subdevices are children of the dss_core.
> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> property and do the lookup based on the compatible property instead ;)
> So from that point of view we need to get the device mapping right in
> the .dtsi files, and don't want to start mixing up separate devices into
> single .dtsi entry.
Hmm, was that just a general comment, or something that affects the DSS
DT data I have in my patch? As far as I understand, the DSS nodes
reflect the current hwmods correctly.
With the exception that DPI and SDI do not have a matching hwmod, as
they are really part of dss_core/dispc. They are separate nodes as they
are "video outputs" the same way as the other subnodes.
I could perhaps remove the DPI and SDI nodes, and have them as direct
video ports from DISPC, but... That's easier said than done.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-09 12:45 ` Tomi Valkeinen
@ 2013-12-09 18:04 ` Tony Lindgren
-1 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-09 18:04 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja, Darren Etheridge
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131209 04:46]:
> On 2013-12-05 19:05, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
> >
> > Description missing.. But other than that can you please check that
> > the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> > the hwmod data from device" works with this?
> >
> > The test to do is to remove the related reg, interrupt and dma entries
> > from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
> > from DT properly.
>
> I made a quick test with panda, by applying your patch and reverting
> b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
> the DISPC IRQ, but that worked fine.
OK I've finally pushed a real branch for the mach-omap2 board-*.c file
removal patches at omap-for-v3.14/omap3-board-removal so you can use
that as a base for testing. I did not apply the dpi panel pdata-quirks.c
patch as we discussed earlier.
> > I don't know if it makes sense to have them as children of dss_core, they
> > really all seem to be completely independent devices?
>
> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> for any of the subdevices to work. This is done automatically by the
> runtime PM when the subdevices are children of the dss_core.
OK thanks. Care to also check that it plays along nicely with the comments
starting at line 3222 in omap_hwmod_3xxx_data.c? We should set up things
so we can eventually remove those kind of hwmod workarounds.
> > BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> > property and do the lookup based on the compatible property instead ;)
> > So from that point of view we need to get the device mapping right in
> > the .dtsi files, and don't want to start mixing up separate devices into
> > single .dtsi entry.
>
> Hmm, was that just a general comment, or something that affects the DSS
> DT data I have in my patch? As far as I understand, the DSS nodes
> reflect the current hwmods correctly.
Yes that's what we want if there is a dependency to the dss_core at the
hardware level and the children cannot be used independently. However,
if the children can be enabled and clocked independently, then they
should not be children of the dss_core.
> With the exception that DPI and SDI do not have a matching hwmod, as
> they are really part of dss_core/dispc. They are separate nodes as they
> are "video outputs" the same way as the other subnodes.
>
> I could perhaps remove the DPI and SDI nodes, and have them as direct
> video ports from DISPC, but... That's easier said than done.
If you need a dev entry created for those where the phandle of that dev
is used to select the output for a board, then it makes sense to have
them. I guess you could also set them as a pinctrl mux controller and
then the board specific .dts file could request those outputs. But there
may be more than just mux involved like regulators.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-09 18:04 ` Tony Lindgren
0 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-09 18:04 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja, Darren Etheridge
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131209 04:46]:
> On 2013-12-05 19:05, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
> >
> > Description missing.. But other than that can you please check that
> > the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> > the hwmod data from device" works with this?
> >
> > The test to do is to remove the related reg, interrupt and dma entries
> > from omap_hwmod_*_data.c, and make sure the related hwmod data is initialized
> > from DT properly.
>
> I made a quick test with panda, by applying your patch and reverting
> b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
> the DISPC IRQ, but that worked fine.
OK I've finally pushed a real branch for the mach-omap2 board-*.c file
removal patches at omap-for-v3.14/omap3-board-removal so you can use
that as a base for testing. I did not apply the dpi panel pdata-quirks.c
patch as we discussed earlier.
> > I don't know if it makes sense to have them as children of dss_core, they
> > really all seem to be completely independent devices?
>
> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> for any of the subdevices to work. This is done automatically by the
> runtime PM when the subdevices are children of the dss_core.
OK thanks. Care to also check that it plays along nicely with the comments
starting at line 3222 in omap_hwmod_3xxx_data.c? We should set up things
so we can eventually remove those kind of hwmod workarounds.
> > BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> > property and do the lookup based on the compatible property instead ;)
> > So from that point of view we need to get the device mapping right in
> > the .dtsi files, and don't want to start mixing up separate devices into
> > single .dtsi entry.
>
> Hmm, was that just a general comment, or something that affects the DSS
> DT data I have in my patch? As far as I understand, the DSS nodes
> reflect the current hwmods correctly.
Yes that's what we want if there is a dependency to the dss_core at the
hardware level and the children cannot be used independently. However,
if the children can be enabled and clocked independently, then they
should not be children of the dss_core.
> With the exception that DPI and SDI do not have a matching hwmod, as
> they are really part of dss_core/dispc. They are separate nodes as they
> are "video outputs" the same way as the other subnodes.
>
> I could perhaps remove the DPI and SDI nodes, and have them as direct
> video ports from DISPC, but... That's easier said than done.
If you need a dev entry created for those where the phandle of that dev
is used to select the output for a board, then it makes sense to have
them. I guess you could also set them as a pinctrl mux controller and
then the board specific .dts file could request those outputs. But there
may be more than just mux involved like regulators.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-09 12:45 ` Tomi Valkeinen
@ 2013-12-11 23:44 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:44 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]
Hi Tomi,
On Monday 09 December 2013 14:45:25 Tomi Valkeinen wrote:
> On 2013-12-05 19:05, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
> >
> > Description missing.. But other than that can you please check that
> > the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> > the hwmod data from device" works with this?
> >
> > The test to do is to remove the related reg, interrupt and dma entries
> > from omap_hwmod_*_data.c, and make sure the related hwmod data is
> > initialized from DT properly.
>
> I made a quick test with panda, by applying your patch and reverting
> b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
> the DISPC IRQ, but that worked fine.
>
> > I don't know if it makes sense to have them as children of dss_core, they
> > really all seem to be completely independent devices?
>
> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> for any of the subdevices to work. This is done automatically by the
> runtime PM when the subdevices are children of the dss_core.
I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is
organized in a seemingly similar way, with the hardware subdivided in high-
level more-or-less independent modules. However, from a system point of view,
the ISP submodules are not standalone: they're part of the same power domain
as the ISP core, with subclocks management and interrupts being handled by the
ISP core. For those reasons we've modeled the ISP as a single platform device.
Are the DSS submodules really independent, or are they organized similarly ?
For instance do they each have a clock handled by the OMAP core clock IP, or
are the clocks gated by the DSS core ? Do they have interrupts routed to the
GIC, or does the DSS core driver demux the interrupts ?
If the submodules are not independent, would it make sense to have a single DT
node that would be matched with the DSS core driver ? You could list
information about the submodules in subnodes, and possibly create platform
devices internally in the DSS core, but a single platform device would be
instantiated from DT, and the DSS core wouldn't need a "simple-bus" compatible
string. My gut feeling is that this would be a better representation of the
hardware, but I might not known enough about the DSS and be completely wrong.
> > BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> > property and do the lookup based on the compatible property instead ;)
> > So from that point of view we need to get the device mapping right in
> > the .dtsi files, and don't want to start mixing up separate devices into
> > single .dtsi entry.
>
> Hmm, was that just a general comment, or something that affects the DSS
> DT data I have in my patch? As far as I understand, the DSS nodes
> reflect the current hwmods correctly.
>
> With the exception that DPI and SDI do not have a matching hwmod, as
> they are really part of dss_core/dispc. They are separate nodes as they
> are "video outputs" the same way as the other subnodes.
>
> I could perhaps remove the DPI and SDI nodes, and have them as direct
> video ports from DISPC, but... That's easier said than done.
DPI and SDI indeed seem like ports to me, node devices. Have you given the
implementation a thought ? How difficult would it be ?
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-11 23:44 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-11 23:44 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 3409 bytes --]
Hi Tomi,
On Monday 09 December 2013 14:45:25 Tomi Valkeinen wrote:
> On 2013-12-05 19:05, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131204 04:31]:
> >
> > Description missing.. But other than that can you please check that
> > the latest patch I posted in thread "[PATCH] ARM: OMAP2+: Fix populating
> > the hwmod data from device" works with this?
> >
> > The test to do is to remove the related reg, interrupt and dma entries
> > from omap_hwmod_*_data.c, and make sure the related hwmod data is
> > initialized from DT properly.
>
> I made a quick test with panda, by applying your patch and reverting
> b38911f3472be89551bfca740adf0009562b9873. That only effectively tests
> the DISPC IRQ, but that worked fine.
>
> > I don't know if it makes sense to have them as children of dss_core, they
> > really all seem to be completely independent devices?
>
> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> for any of the subdevices to work. This is done automatically by the
> runtime PM when the subdevices are children of the dss_core.
I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is
organized in a seemingly similar way, with the hardware subdivided in high-
level more-or-less independent modules. However, from a system point of view,
the ISP submodules are not standalone: they're part of the same power domain
as the ISP core, with subclocks management and interrupts being handled by the
ISP core. For those reasons we've modeled the ISP as a single platform device.
Are the DSS submodules really independent, or are they organized similarly ?
For instance do they each have a clock handled by the OMAP core clock IP, or
are the clocks gated by the DSS core ? Do they have interrupts routed to the
GIC, or does the DSS core driver demux the interrupts ?
If the submodules are not independent, would it make sense to have a single DT
node that would be matched with the DSS core driver ? You could list
information about the submodules in subnodes, and possibly create platform
devices internally in the DSS core, but a single platform device would be
instantiated from DT, and the DSS core wouldn't need a "simple-bus" compatible
string. My gut feeling is that this would be a better representation of the
hardware, but I might not known enough about the DSS and be completely wrong.
> > BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> > property and do the lookup based on the compatible property instead ;)
> > So from that point of view we need to get the device mapping right in
> > the .dtsi files, and don't want to start mixing up separate devices into
> > single .dtsi entry.
>
> Hmm, was that just a general comment, or something that affects the DSS
> DT data I have in my patch? As far as I understand, the DSS nodes
> reflect the current hwmods correctly.
>
> With the exception that DPI and SDI do not have a matching hwmod, as
> they are really part of dss_core/dispc. They are separate nodes as they
> are "video outputs" the same way as the other subnodes.
>
> I could perhaps remove the DPI and SDI nodes, and have them as direct
> video ports from DISPC, but... That's easier said than done.
DPI and SDI indeed seem like ports to me, node devices. Have you given the
implementation a thought ? How difficult would it be ?
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-11 23:44 ` Laurent Pinchart
@ 2013-12-12 8:38 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 8:38 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 5929 bytes --]
On 2013-12-12 01:44, Laurent Pinchart wrote:
>> The DSS subdevices depend on the dss_core. dss_core has to be powered up
>> for any of the subdevices to work. This is done automatically by the
>> runtime PM when the subdevices are children of the dss_core.
>
> I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is
> organized in a seemingly similar way, with the hardware subdivided in high-
> level more-or-less independent modules. However, from a system point of view,
> the ISP submodules are not standalone: they're part of the same power domain
> as the ISP core, with subclocks management and interrupts being handled by the
> ISP core. For those reasons we've modeled the ISP as a single platform device.
>
> Are the DSS submodules really independent, or are they organized similarly ?
> For instance do they each have a clock handled by the OMAP core clock IP, or
> are the clocks gated by the DSS core ? Do they have interrupts routed to the
> GIC, or does the DSS core driver demux the interrupts ?
The DSS is "interesting". The TRM for various OMAP versions are the best
source of information, there's integration section in the very beginning
of the DSS chapter.
We have the main dss_core (just DSS in the TRM, but for clarity we use
dss_core) module, which is kind of a wrapper/glue for all the
submodules. dss_core contains things like controlling muxes for signals
between submodules, or clocks coming from outside. And there's the DSS
power domain, containing all the DSS modules.
Then we have DISPC, which reads the pixel data, manipulates it, and
outputs raw RGB data to encoder submodules.
Then we have DSI, HDMI, RFBI, VENC encoder submodules. They all have
separate address spaces, some have dedicated PLLs, PHYs, and interrupts.
Then DPI, which I think is mostly just level shifters. It's really just
a port, as you say.
SDI is a bit unclear to me. The registers for it are in the dss_core.
There's only a few registers, but it does have a PHY and a PLL. But I
guess it's also more of a port than a separate module.
As for the clocks, I'm not sure what the actual point is that you want
to clarify. DSS gets one "main" func clock from PRCM, which is used by
DISPC and in some cases other submodules. But then we have dedicated DSI
and HDMI PLLs, which, at least in DSI's case, can be used to fully
satisfy DSI's clock needs. The PLLs can also be used for DISPC, so the
PRCM clock is not needed in all cases.
The interrupts, then. In OMAP4, DISPC, DSI1, DSI2 and HDMI each have
their own interrupt line. In OMAP3, DISPC and DSI shared the same
interrupt line. But in both OMAP4 and OMAP3 DISPC and DSI interrupt
status/enable is handled via the respective IP.
The DSS submodules also are not really designed together. For example,
the HDMI IP is from one vendor, not TI. And the HDMI IP is different in
OMAP4 and OMAP5. Most of the DSS IPs are, I believe, from TI. But it's
not like all the IPs were designed to work together, that's why we have
wrappers/glue blocks (e.g. around HDMI).
So, are they independent? I don't know =). I think they lean on the
independent side. dss_core is always needed for the submodules to work,
but for example DSI could be used without DISPC, using system DMA to
transfer data from memory to DSI. Not a very useful thing to do, but
still, there are dedicated DMA channels for that.
> If the submodules are not independent, would it make sense to have a single DT
> node that would be matched with the DSS core driver ? You could list
> information about the submodules in subnodes, and possibly create platform
> devices internally in the DSS core, but a single platform device would be
> instantiated from DT, and the DSS core wouldn't need a "simple-bus" compatible
> string. My gut feeling is that this would be a better representation of the
> hardware, but I might not known enough about the DSS and be completely wrong.
I have been wondering about this for a long time. The DSS modules have
dependencies, and splitting them into separate devices/drivers brings
the issue of probe order. We side-step that by having the virtual
omapdss driver add the drivers for DSS modules in proper order.
But then, I feel that they are quite independent and probably should be
separate devices. And we've had omap hwmods, which I believe force us to
have separate devices (although afaik hwmods are going away).
>>> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
>>> property and do the lookup based on the compatible property instead ;)
>>> So from that point of view we need to get the device mapping right in
>>> the .dtsi files, and don't want to start mixing up separate devices into
>>> single .dtsi entry.
>>
>> Hmm, was that just a general comment, or something that affects the DSS
>> DT data I have in my patch? As far as I understand, the DSS nodes
>> reflect the current hwmods correctly.
>>
>> With the exception that DPI and SDI do not have a matching hwmod, as
>> they are really part of dss_core/dispc. They are separate nodes as they
>> are "video outputs" the same way as the other subnodes.
>>
>> I could perhaps remove the DPI and SDI nodes, and have them as direct
>> video ports from DISPC, but... That's easier said than done.
>
> DPI and SDI indeed seem like ports to me, node devices. Have you given the
> implementation a thought ? How difficult would it be ?
I have not though too much about the implementation. I'll spend some
time on that to see how it goes.
There's also the question where do the ports belong to. DISPC outputs
the pixels.
For DPI, I don't see dss_core really doing anything.
For SDI, the dss_core contains the control for the SDI PLL and PHY. But
SDI PLL and PHY are not parts of dss_core, just the control is done via
dss_core.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-12 8:38 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 8:38 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 5929 bytes --]
On 2013-12-12 01:44, Laurent Pinchart wrote:
>> The DSS subdevices depend on the dss_core. dss_core has to be powered up
>> for any of the subdevices to work. This is done automatically by the
>> runtime PM when the subdevices are children of the dss_core.
>
> I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is
> organized in a seemingly similar way, with the hardware subdivided in high-
> level more-or-less independent modules. However, from a system point of view,
> the ISP submodules are not standalone: they're part of the same power domain
> as the ISP core, with subclocks management and interrupts being handled by the
> ISP core. For those reasons we've modeled the ISP as a single platform device.
>
> Are the DSS submodules really independent, or are they organized similarly ?
> For instance do they each have a clock handled by the OMAP core clock IP, or
> are the clocks gated by the DSS core ? Do they have interrupts routed to the
> GIC, or does the DSS core driver demux the interrupts ?
The DSS is "interesting". The TRM for various OMAP versions are the best
source of information, there's integration section in the very beginning
of the DSS chapter.
We have the main dss_core (just DSS in the TRM, but for clarity we use
dss_core) module, which is kind of a wrapper/glue for all the
submodules. dss_core contains things like controlling muxes for signals
between submodules, or clocks coming from outside. And there's the DSS
power domain, containing all the DSS modules.
Then we have DISPC, which reads the pixel data, manipulates it, and
outputs raw RGB data to encoder submodules.
Then we have DSI, HDMI, RFBI, VENC encoder submodules. They all have
separate address spaces, some have dedicated PLLs, PHYs, and interrupts.
Then DPI, which I think is mostly just level shifters. It's really just
a port, as you say.
SDI is a bit unclear to me. The registers for it are in the dss_core.
There's only a few registers, but it does have a PHY and a PLL. But I
guess it's also more of a port than a separate module.
As for the clocks, I'm not sure what the actual point is that you want
to clarify. DSS gets one "main" func clock from PRCM, which is used by
DISPC and in some cases other submodules. But then we have dedicated DSI
and HDMI PLLs, which, at least in DSI's case, can be used to fully
satisfy DSI's clock needs. The PLLs can also be used for DISPC, so the
PRCM clock is not needed in all cases.
The interrupts, then. In OMAP4, DISPC, DSI1, DSI2 and HDMI each have
their own interrupt line. In OMAP3, DISPC and DSI shared the same
interrupt line. But in both OMAP4 and OMAP3 DISPC and DSI interrupt
status/enable is handled via the respective IP.
The DSS submodules also are not really designed together. For example,
the HDMI IP is from one vendor, not TI. And the HDMI IP is different in
OMAP4 and OMAP5. Most of the DSS IPs are, I believe, from TI. But it's
not like all the IPs were designed to work together, that's why we have
wrappers/glue blocks (e.g. around HDMI).
So, are they independent? I don't know =). I think they lean on the
independent side. dss_core is always needed for the submodules to work,
but for example DSI could be used without DISPC, using system DMA to
transfer data from memory to DSI. Not a very useful thing to do, but
still, there are dedicated DMA channels for that.
> If the submodules are not independent, would it make sense to have a single DT
> node that would be matched with the DSS core driver ? You could list
> information about the submodules in subnodes, and possibly create platform
> devices internally in the DSS core, but a single platform device would be
> instantiated from DT, and the DSS core wouldn't need a "simple-bus" compatible
> string. My gut feeling is that this would be a better representation of the
> hardware, but I might not known enough about the DSS and be completely wrong.
I have been wondering about this for a long time. The DSS modules have
dependencies, and splitting them into separate devices/drivers brings
the issue of probe order. We side-step that by having the virtual
omapdss driver add the drivers for DSS modules in proper order.
But then, I feel that they are quite independent and probably should be
separate devices. And we've had omap hwmods, which I believe force us to
have separate devices (although afaik hwmods are going away).
>>> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
>>> property and do the lookup based on the compatible property instead ;)
>>> So from that point of view we need to get the device mapping right in
>>> the .dtsi files, and don't want to start mixing up separate devices into
>>> single .dtsi entry.
>>
>> Hmm, was that just a general comment, or something that affects the DSS
>> DT data I have in my patch? As far as I understand, the DSS nodes
>> reflect the current hwmods correctly.
>>
>> With the exception that DPI and SDI do not have a matching hwmod, as
>> they are really part of dss_core/dispc. They are separate nodes as they
>> are "video outputs" the same way as the other subnodes.
>>
>> I could perhaps remove the DPI and SDI nodes, and have them as direct
>> video ports from DISPC, but... That's easier said than done.
>
> DPI and SDI indeed seem like ports to me, node devices. Have you given the
> implementation a thought ? How difficult would it be ?
I have not though too much about the implementation. I'll spend some
time on that to see how it goes.
There's also the question where do the ports belong to. DISPC outputs
the pixels.
For DPI, I don't see dss_core really doing anything.
For SDI, the dss_core contains the control for the SDI PLL and PHY. But
SDI PLL and PHY are not parts of dss_core, just the control is done via
dss_core.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-12 8:38 ` Tomi Valkeinen
(?)
@ 2013-12-12 21:59 ` Tony Lindgren
2013-12-13 3:27 ` Laurent Pinchart
-1 siblings, 1 reply; 183+ messages in thread
From: Tony Lindgren @ 2013-12-12 21:59 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, Tony Lindgren, linux-omap, linux-fbdev,
devicetree, Archit Taneja, Darren Etheridge
On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
> On 2013-12-12 01:44, Laurent Pinchart wrote:
>
> So, are they independent? I don't know =). I think they lean on the
> independent side. dss_core is always needed for the submodules to work,
> but for example DSI could be used without DISPC, using system DMA to
> transfer data from memory to DSI. Not a very useful thing to do, but
> still, there are dedicated DMA channels for that.
If they have separate hwmod entries, they should be considered separate
independent devices for sure.
To summarize, here are few reasons why they need to be treated as
separate devices:
1. The modules maybe clocked/powered/idled separately and can have their
own idle configuration so they can do the hardware based idling
separately.
2. Doing a readback after a write to one module will not flush the write
to the other modules on the (bus depending on the SoC version AFAIK).
That can lead to nasty bugs caused by the ordering.
3. If the devices are described in a different way in the .dts files
from the hwmod data, we will not have 1-to-1 mapping and will never
be able to replace ti,hwmods with just the compatible string.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-12 21:59 ` Tony Lindgren
@ 2013-12-13 3:27 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 3:27 UTC (permalink / raw)
To: Tony Lindgren
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
Hi Tony,
On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
> > On 2013-12-12 01:44, Laurent Pinchart wrote:
> >
> > So, are they independent? I don't know =). I think they lean on the
> > independent side. dss_core is always needed for the submodules to work,
> > but for example DSI could be used without DISPC, using system DMA to
> > transfer data from memory to DSI. Not a very useful thing to do, but
> > still, there are dedicated DMA channels for that.
>
> If they have separate hwmod entries, they should be considered separate
> independent devices for sure.
>
> To summarize, here are few reasons why they need to be treated as
> separate devices:
Are you talking generally here, or about the DSS modules in particular ?
> 1. The modules maybe clocked/powered/idled separately and can have their
> own idle configuration so they can do the hardware based idling
> separately.
I don't think this applies to the DSS modules.
> 2. Doing a readback after a write to one module will not flush the write
> to the other modules on the (bus depending on the SoC version AFAIK).
> That can lead to nasty bugs caused by the ordering.
How does separate devices solve this ?
> 3. If the devices are described in a different way in the .dts files
> from the hwmod data, we will not have 1-to-1 mapping and will never
> be able to replace ti,hwmods with just the compatible string.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-13 3:27 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 3:27 UTC (permalink / raw)
To: Tony Lindgren
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
Hi Tony,
On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
> > On 2013-12-12 01:44, Laurent Pinchart wrote:
> >
> > So, are they independent? I don't know =). I think they lean on the
> > independent side. dss_core is always needed for the submodules to work,
> > but for example DSI could be used without DISPC, using system DMA to
> > transfer data from memory to DSI. Not a very useful thing to do, but
> > still, there are dedicated DMA channels for that.
>
> If they have separate hwmod entries, they should be considered separate
> independent devices for sure.
>
> To summarize, here are few reasons why they need to be treated as
> separate devices:
Are you talking generally here, or about the DSS modules in particular ?
> 1. The modules maybe clocked/powered/idled separately and can have their
> own idle configuration so they can do the hardware based idling
> separately.
I don't think this applies to the DSS modules.
> 2. Doing a readback after a write to one module will not flush the write
> to the other modules on the (bus depending on the SoC version AFAIK).
> That can lead to nasty bugs caused by the ordering.
How does separate devices solve this ?
> 3. If the devices are described in a different way in the .dts files
> from the hwmod data, we will not have 1-to-1 mapping and will never
> be able to replace ti,hwmods with just the compatible string.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-13 3:27 ` Laurent Pinchart
@ 2013-12-13 10:18 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 10:18 UTC (permalink / raw)
To: Laurent Pinchart, Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On 2013-12-13 05:27, Laurent Pinchart wrote:
> Hi Tony,
>
> On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
>> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
>>> On 2013-12-12 01:44, Laurent Pinchart wrote:
>>>
>>> So, are they independent? I don't know =). I think they lean on the
>>> independent side. dss_core is always needed for the submodules to work,
>>> but for example DSI could be used without DISPC, using system DMA to
>>> transfer data from memory to DSI. Not a very useful thing to do, but
>>> still, there are dedicated DMA channels for that.
>>
>> If they have separate hwmod entries, they should be considered separate
>> independent devices for sure.
>>
>> To summarize, here are few reasons why they need to be treated as
>> separate devices:
>
> Are you talking generally here, or about the DSS modules in particular ?
>
>> 1. The modules maybe clocked/powered/idled separately and can have their
>> own idle configuration so they can do the hardware based idling
>> separately.
>
> I don't think this applies to the DSS modules.
The DSS submodules have their own SYSCONFIG register, and idle settings
can be set per module. So I think they idle separately, even if they are
in a common power domain.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-13 10:18 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 10:18 UTC (permalink / raw)
To: Laurent Pinchart, Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
On 2013-12-13 05:27, Laurent Pinchart wrote:
> Hi Tony,
>
> On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
>> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
>>> On 2013-12-12 01:44, Laurent Pinchart wrote:
>>>
>>> So, are they independent? I don't know =). I think they lean on the
>>> independent side. dss_core is always needed for the submodules to work,
>>> but for example DSI could be used without DISPC, using system DMA to
>>> transfer data from memory to DSI. Not a very useful thing to do, but
>>> still, there are dedicated DMA channels for that.
>>
>> If they have separate hwmod entries, they should be considered separate
>> independent devices for sure.
>>
>> To summarize, here are few reasons why they need to be treated as
>> separate devices:
>
> Are you talking generally here, or about the DSS modules in particular ?
>
>> 1. The modules maybe clocked/powered/idled separately and can have their
>> own idle configuration so they can do the hardware based idling
>> separately.
>
> I don't think this applies to the DSS modules.
The DSS submodules have their own SYSCONFIG register, and idle settings
can be set per module. So I think they idle separately, even if they are
in a common power domain.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
[parent not found: <52AADEF3.9040808-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
[not found] ` <52AADEF3.9040808-l0cyMroinI0@public.gmane.org>
@ 2013-12-13 17:10 ` Tony Lindgren
0 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-13 17:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge
* Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org> [131213 02:19]:
> On 2013-12-13 05:27, Laurent Pinchart wrote:
> > Hi Tony,
> >
> > On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
> >> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
> >>> On 2013-12-12 01:44, Laurent Pinchart wrote:
> >>>
> >>> So, are they independent? I don't know =). I think they lean on the
> >>> independent side. dss_core is always needed for the submodules to work,
> >>> but for example DSI could be used without DISPC, using system DMA to
> >>> transfer data from memory to DSI. Not a very useful thing to do, but
> >>> still, there are dedicated DMA channels for that.
> >>
> >> If they have separate hwmod entries, they should be considered separate
> >> independent devices for sure.
> >>
> >> To summarize, here are few reasons why they need to be treated as
> >> separate devices:
> >
> > Are you talking generally here, or about the DSS modules in particular ?
> >
> >> 1. The modules maybe clocked/powered/idled separately and can have their
> >> own idle configuration so they can do the hardware based idling
> >> separately.
> >
> > I don't think this applies to the DSS modules.
>
> The DSS submodules have their own SYSCONFIG register, and idle settings
> can be set per module. So I think they idle separately, even if they are
> in a common power domain.
Yes. Please see the current omap_hwmod_*_data.c files, if they are separate
entries there, that means we need to treat them as separate devices to
avoid the issues I listed.
We do have some entries still missing from omap_hwmod_*_data.c files, like
the SSI entries as they are undocumented. But for the existing ones there
please follow the same layout for the .dts entries.
Regards,
Tony
--
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
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-13 17:10 ` Tony Lindgren
0 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-13 17:10 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 02:19]:
> On 2013-12-13 05:27, Laurent Pinchart wrote:
> > Hi Tony,
> >
> > On Thursday 12 December 2013 21:59:13 Tony Lindgren wrote:
> >> On Thu, Dec 12, 2013 at 10:38:34AM +0200, Tomi Valkeinen wrote:
> >>> On 2013-12-12 01:44, Laurent Pinchart wrote:
> >>>
> >>> So, are they independent? I don't know =). I think they lean on the
> >>> independent side. dss_core is always needed for the submodules to work,
> >>> but for example DSI could be used without DISPC, using system DMA to
> >>> transfer data from memory to DSI. Not a very useful thing to do, but
> >>> still, there are dedicated DMA channels for that.
> >>
> >> If they have separate hwmod entries, they should be considered separate
> >> independent devices for sure.
> >>
> >> To summarize, here are few reasons why they need to be treated as
> >> separate devices:
> >
> > Are you talking generally here, or about the DSS modules in particular ?
> >
> >> 1. The modules maybe clocked/powered/idled separately and can have their
> >> own idle configuration so they can do the hardware based idling
> >> separately.
> >
> > I don't think this applies to the DSS modules.
>
> The DSS submodules have their own SYSCONFIG register, and idle settings
> can be set per module. So I think they idle separately, even if they are
> in a common power domain.
Yes. Please see the current omap_hwmod_*_data.c files, if they are separate
entries there, that means we need to treat them as separate devices to
avoid the issues I listed.
We do have some entries still missing from omap_hwmod_*_data.c files, like
the SSI entries as they are undocumented. But for the existing ones there
please follow the same layout for the .dts entries.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-12 8:38 ` Tomi Valkeinen
@ 2013-12-13 3:24 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 3:24 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 7493 bytes --]
Hi Tomi,
On Thursday 12 December 2013 10:38:34 Tomi Valkeinen wrote:
> On 2013-12-12 01:44, Laurent Pinchart wrote:
> >> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> >> for any of the subdevices to work. This is done automatically by the
> >> runtime PM when the subdevices are children of the dss_core.
> >
> > I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is
> > organized in a seemingly similar way, with the hardware subdivided in
> > high-level more-or-less independent modules. However, from a system point
> > of view, the ISP submodules are not standalone: they're part of the same
> > power domain as the ISP core, with subclocks management and interrupts
> > being handled by the ISP core. For those reasons we've modeled the ISP as
> > a single platform device.
> >
> > Are the DSS submodules really independent, or are they organized similarly
> > ? For instance do they each have a clock handled by the OMAP core clock
> > IP, or are the clocks gated by the DSS core ? Do they have interrupts
> > routed to the GIC, or does the DSS core driver demux the interrupts ?
>
> The DSS is "interesting". The TRM for various OMAP versions are the best
> source of information, there's integration section in the very beginning
> of the DSS chapter.
>
> We have the main dss_core (just DSS in the TRM, but for clarity we use
> dss_core) module, which is kind of a wrapper/glue for all the
> submodules. dss_core contains things like controlling muxes for signals
> between submodules, or clocks coming from outside. And there's the DSS
> power domain, containing all the DSS modules.
>
> Then we have DISPC, which reads the pixel data, manipulates it, and
> outputs raw RGB data to encoder submodules.
>
> Then we have DSI, HDMI, RFBI, VENC encoder submodules. They all have
> separate address spaces, some have dedicated PLLs, PHYs, and interrupts.
The separate address spaces are not by themselves a clear indication that the
submodules should be considered as separate devices, as the hardware might
just group registers related to submodules together.
The dedicated interrupts (for DSI and HDMI) and PRCM clocks (for VENC if I'm
not mistaken, and HDMI on the OMAP4) are a clearer sign.
> Then DPI, which I think is mostly just level shifters. It's really just
> a port, as you say.
>
> SDI is a bit unclear to me. The registers for it are in the dss_core.
> There's only a few registers, but it does have a PHY and a PLL. But I
> guess it's also more of a port than a separate module.
After a quick look at the documentation I would say so. I would be tempted to
consider RFBI as part of the DSS core, but that's less clear.
> As for the clocks, I'm not sure what the actual point is that you want
> to clarify. DSS gets one "main" func clock from PRCM, which is used by
> DISPC and in some cases other submodules. But then we have dedicated DSI
> and HDMI PLLs, which, at least in DSI's case, can be used to fully
> satisfy DSI's clock needs. The PLLs can also be used for DISPC, so the
> PRCM clock is not needed in all cases.
>
> The interrupts, then. In OMAP4, DISPC, DSI1, DSI2 and HDMI each have
> their own interrupt line. In OMAP3, DISPC and DSI shared the same
> interrupt line. But in both OMAP4 and OMAP3 DISPC and DSI interrupt
> status/enable is handled via the respective IP.
>
> The DSS submodules also are not really designed together. For example,
> the HDMI IP is from one vendor, not TI. And the HDMI IP is different in
> OMAP4 and OMAP5. Most of the DSS IPs are, I believe, from TI. But it's
> not like all the IPs were designed to work together, that's why we have
> wrappers/glue blocks (e.g. around HDMI).
>
> So, are they independent? I don't know =). I think they lean on the
> independent side.
I agree with that, except for DPI, SDI and possibly RFBI.
> dss_core is always needed for the submodules to work, but for example DSI
> could be used without DISPC, using system DMA to transfer data from memory
> to DSI. Not a very useful thing to do, but still, there are dedicated DMA
> channels for that.
Right. The real question is whether the DSI or HDMI IPs can be used in a
system without the DSS core. If not, it might make sense to just merge the
drivers into a single module (of course with a clear interface between the
different parts to avoid spaghetti code).
> > If the submodules are not independent, would it make sense to have a
> > single DT node that would be matched with the DSS core driver ? You could
> > list information about the submodules in subnodes, and possibly create
> > platform devices internally in the DSS core, but a single platform device
> > would be instantiated from DT, and the DSS core wouldn't need a
> > "simple-bus" compatible string. My gut feeling is that this would be a
> > better representation of the hardware, but I might not known enough about
> > the DSS and be completely wrong.
>
> I have been wondering about this for a long time. The DSS modules have
> dependencies, and splitting them into separate devices/drivers brings
> the issue of probe order. We side-step that by having the virtual
> omapdss driver
Given that the DSS core has a set of registers not dedicated to any of the
submodules I believe it should be represented by a device. The omapdss driver
thus doesn't look virtual to me, it supports a real piece of hardware.
> add the drivers for DSS modules in proper order.
>
> But then, I feel that they are quite independent and probably should be
> separate devices.
Even if they're separate devices they could be instantiated by DSS core based
on DT nodes. I'm not sure whether that's the best idea, but it might be worth
thinking about it.
> And we've had omap hwmods, which I believe force us to have separate devices
> (although afaik hwmods are going away).
>
> >>> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> >>> property and do the lookup based on the compatible property instead ;)
> >>> So from that point of view we need to get the device mapping right in
> >>> the .dtsi files, and don't want to start mixing up separate devices into
> >>> single .dtsi entry.
> >>
> >> Hmm, was that just a general comment, or something that affects the DSS
> >> DT data I have in my patch? As far as I understand, the DSS nodes
> >> reflect the current hwmods correctly.
> >>
> >> With the exception that DPI and SDI do not have a matching hwmod, as
> >> they are really part of dss_core/dispc. They are separate nodes as they
> >> are "video outputs" the same way as the other subnodes.
> >>
> >> I could perhaps remove the DPI and SDI nodes, and have them as direct
> >> video ports from DISPC, but... That's easier said than done.
> >
> > DPI and SDI indeed seem like ports to me, node devices. Have you given the
> > implementation a thought ? How difficult would it be ?
>
> I have not though too much about the implementation. I'll spend some time on
> that to see how it goes.
>
> There's also the question where do the ports belong to. DISPC outputs the
> pixels.
>
> For DPI, I don't see dss_core really doing anything.
>
> For SDI, the dss_core contains the control for the SDI PLL and PHY. But
> SDI PLL and PHY are not parts of dss_core, just the control is done via
> dss_core.
If the PLL and PHY are solely controlled through registers part of the DSS
core register space, they would seem like part of the DSS core to me.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-13 3:24 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 3:24 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 7493 bytes --]
Hi Tomi,
On Thursday 12 December 2013 10:38:34 Tomi Valkeinen wrote:
> On 2013-12-12 01:44, Laurent Pinchart wrote:
> >> The DSS subdevices depend on the dss_core. dss_core has to be powered up
> >> for any of the subdevices to work. This is done automatically by the
> >> runtime PM when the subdevices are children of the dss_core.
> >
> > I'd like to get a clearer picture of the hardware here. The OMAP3 ISP is
> > organized in a seemingly similar way, with the hardware subdivided in
> > high-level more-or-less independent modules. However, from a system point
> > of view, the ISP submodules are not standalone: they're part of the same
> > power domain as the ISP core, with subclocks management and interrupts
> > being handled by the ISP core. For those reasons we've modeled the ISP as
> > a single platform device.
> >
> > Are the DSS submodules really independent, or are they organized similarly
> > ? For instance do they each have a clock handled by the OMAP core clock
> > IP, or are the clocks gated by the DSS core ? Do they have interrupts
> > routed to the GIC, or does the DSS core driver demux the interrupts ?
>
> The DSS is "interesting". The TRM for various OMAP versions are the best
> source of information, there's integration section in the very beginning
> of the DSS chapter.
>
> We have the main dss_core (just DSS in the TRM, but for clarity we use
> dss_core) module, which is kind of a wrapper/glue for all the
> submodules. dss_core contains things like controlling muxes for signals
> between submodules, or clocks coming from outside. And there's the DSS
> power domain, containing all the DSS modules.
>
> Then we have DISPC, which reads the pixel data, manipulates it, and
> outputs raw RGB data to encoder submodules.
>
> Then we have DSI, HDMI, RFBI, VENC encoder submodules. They all have
> separate address spaces, some have dedicated PLLs, PHYs, and interrupts.
The separate address spaces are not by themselves a clear indication that the
submodules should be considered as separate devices, as the hardware might
just group registers related to submodules together.
The dedicated interrupts (for DSI and HDMI) and PRCM clocks (for VENC if I'm
not mistaken, and HDMI on the OMAP4) are a clearer sign.
> Then DPI, which I think is mostly just level shifters. It's really just
> a port, as you say.
>
> SDI is a bit unclear to me. The registers for it are in the dss_core.
> There's only a few registers, but it does have a PHY and a PLL. But I
> guess it's also more of a port than a separate module.
After a quick look at the documentation I would say so. I would be tempted to
consider RFBI as part of the DSS core, but that's less clear.
> As for the clocks, I'm not sure what the actual point is that you want
> to clarify. DSS gets one "main" func clock from PRCM, which is used by
> DISPC and in some cases other submodules. But then we have dedicated DSI
> and HDMI PLLs, which, at least in DSI's case, can be used to fully
> satisfy DSI's clock needs. The PLLs can also be used for DISPC, so the
> PRCM clock is not needed in all cases.
>
> The interrupts, then. In OMAP4, DISPC, DSI1, DSI2 and HDMI each have
> their own interrupt line. In OMAP3, DISPC and DSI shared the same
> interrupt line. But in both OMAP4 and OMAP3 DISPC and DSI interrupt
> status/enable is handled via the respective IP.
>
> The DSS submodules also are not really designed together. For example,
> the HDMI IP is from one vendor, not TI. And the HDMI IP is different in
> OMAP4 and OMAP5. Most of the DSS IPs are, I believe, from TI. But it's
> not like all the IPs were designed to work together, that's why we have
> wrappers/glue blocks (e.g. around HDMI).
>
> So, are they independent? I don't know =). I think they lean on the
> independent side.
I agree with that, except for DPI, SDI and possibly RFBI.
> dss_core is always needed for the submodules to work, but for example DSI
> could be used without DISPC, using system DMA to transfer data from memory
> to DSI. Not a very useful thing to do, but still, there are dedicated DMA
> channels for that.
Right. The real question is whether the DSI or HDMI IPs can be used in a
system without the DSS core. If not, it might make sense to just merge the
drivers into a single module (of course with a clear interface between the
different parts to avoid spaghetti code).
> > If the submodules are not independent, would it make sense to have a
> > single DT node that would be matched with the DSS core driver ? You could
> > list information about the submodules in subnodes, and possibly create
> > platform devices internally in the DSS core, but a single platform device
> > would be instantiated from DT, and the DSS core wouldn't need a
> > "simple-bus" compatible string. My gut feeling is that this would be a
> > better representation of the hardware, but I might not known enough about
> > the DSS and be completely wrong.
>
> I have been wondering about this for a long time. The DSS modules have
> dependencies, and splitting them into separate devices/drivers brings
> the issue of probe order. We side-step that by having the virtual
> omapdss driver
Given that the DSS core has a set of registers not dedicated to any of the
submodules I believe it should be represented by a device. The omapdss driver
thus doesn't look virtual to me, it supports a real piece of hardware.
> add the drivers for DSS modules in proper order.
>
> But then, I feel that they are quite independent and probably should be
> separate devices.
Even if they're separate devices they could be instantiated by DSS core based
on DT nodes. I'm not sure whether that's the best idea, but it might be worth
thinking about it.
> And we've had omap hwmods, which I believe force us to have separate devices
> (although afaik hwmods are going away).
>
> >>> BTW, for v3.15, I'm hoping to do patches where we deprecate ti,hwmods
> >>> property and do the lookup based on the compatible property instead ;)
> >>> So from that point of view we need to get the device mapping right in
> >>> the .dtsi files, and don't want to start mixing up separate devices into
> >>> single .dtsi entry.
> >>
> >> Hmm, was that just a general comment, or something that affects the DSS
> >> DT data I have in my patch? As far as I understand, the DSS nodes
> >> reflect the current hwmods correctly.
> >>
> >> With the exception that DPI and SDI do not have a matching hwmod, as
> >> they are really part of dss_core/dispc. They are separate nodes as they
> >> are "video outputs" the same way as the other subnodes.
> >>
> >> I could perhaps remove the DPI and SDI nodes, and have them as direct
> >> video ports from DISPC, but... That's easier said than done.
> >
> > DPI and SDI indeed seem like ports to me, node devices. Have you given the
> > implementation a thought ? How difficult would it be ?
>
> I have not though too much about the implementation. I'll spend some time on
> that to see how it goes.
>
> There's also the question where do the ports belong to. DISPC outputs the
> pixels.
>
> For DPI, I don't see dss_core really doing anything.
>
> For SDI, the dss_core contains the control for the SDI PLL and PHY. But
> SDI PLL and PHY are not parts of dss_core, just the control is done via
> dss_core.
If the PLL and PHY are solely controlled through registers part of the DSS
core register space, they would seem like part of the DSS core to me.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-13 3:24 ` Laurent Pinchart
@ 2013-12-13 9:29 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 9:29 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On 2013-12-13 05:24, Laurent Pinchart wrote:
> Right. The real question is whether the DSI or HDMI IPs can be used in a
> system without the DSS core. If not, it might make sense to just merge the
> drivers into a single module (of course with a clear interface between the
> different parts to avoid spaghetti code).
The drivers are already in single kernel module, omapdss.ko.
The HDMI IP is used on another SoC, without DSS. They have their own
display architecture. DSI IP might need some small modifications to work
without DSS, but not much. It doesn't have any strict DSS/DISPC
dependencies.
> Given that the DSS core has a set of registers not dedicated to any of the
> submodules I believe it should be represented by a device. The omapdss driver
> thus doesn't look virtual to me, it supports a real piece of hardware.
As noted in another mail, dss_core and omapdss devices are different
things. dss_core is not virtual, omapdss is.
>> But then, I feel that they are quite independent and probably should be
>> separate devices.
>
> Even if they're separate devices they could be instantiated by DSS core based
> on DT nodes. I'm not sure whether that's the best idea, but it might be worth
> thinking about it.
What would be the difference to the one in this series? In this series,
the submodules are instantiated automatically by the driver framework.
The only difference I see is that the submodule devices would
appear/disappear dynamically, but... what would be the benefit?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-13 9:29 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 9:29 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On 2013-12-13 05:24, Laurent Pinchart wrote:
> Right. The real question is whether the DSI or HDMI IPs can be used in a
> system without the DSS core. If not, it might make sense to just merge the
> drivers into a single module (of course with a clear interface between the
> different parts to avoid spaghetti code).
The drivers are already in single kernel module, omapdss.ko.
The HDMI IP is used on another SoC, without DSS. They have their own
display architecture. DSI IP might need some small modifications to work
without DSS, but not much. It doesn't have any strict DSS/DISPC
dependencies.
> Given that the DSS core has a set of registers not dedicated to any of the
> submodules I believe it should be represented by a device. The omapdss driver
> thus doesn't look virtual to me, it supports a real piece of hardware.
As noted in another mail, dss_core and omapdss devices are different
things. dss_core is not virtual, omapdss is.
>> But then, I feel that they are quite independent and probably should be
>> separate devices.
>
> Even if they're separate devices they could be instantiated by DSS core based
> on DT nodes. I'm not sure whether that's the best idea, but it might be worth
> thinking about it.
What would be the difference to the one in this series? In this series,
the submodules are instantiated automatically by the driver framework.
The only difference I see is that the submodule devices would
appear/disappear dynamically, but... what would be the benefit?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
2013-12-13 3:24 ` Laurent Pinchart
@ 2013-12-16 10:49 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-16 10:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]
On 2013-12-13 05:24, Laurent Pinchart wrote:
>> Then DPI, which I think is mostly just level shifters. It's really just
>> a port, as you say.
>>
>> SDI is a bit unclear to me. The registers for it are in the dss_core.
>> There's only a few registers, but it does have a PHY and a PLL. But I
>> guess it's also more of a port than a separate module.
>
> After a quick look at the documentation I would say so. I would be tempted to
> consider RFBI as part of the DSS core, but that's less clear.
I had a look at this, mainly the DPI side so far. There's one extra
complication, which actually affects all other outputs also (and CDF):
pinctrl.
In the current series, I just have pinctrl for each device, with
"default" name, which ends up being used by default without any code on
my part.
However, if DPI is no longer a device, it can't have pinctrl entry. But
this is a wider issue, as the pinctrl should really be per endpoint, not
per device. When an endpoint is selected to be used, a particular
pinmuxing should be taken into use.
I'm not sure what would be the cleanest solution to this. I currently
have this working:
&dss {
pinctrl-names = "default-0-0";
pinctrl-0 = <&dss_dpi_pins>;
port@0 {
dpi_out: endpoint {
remote-endpoint = <&tfp410_in>;
data-lines = <24>;
};
};
};
So here I have 'port@0' for DSS, which is the DPI output, and it has a
single endpoint. For DSS device, I have pinctrl data.
When the DPI endpoint is initialized, the code looks for pinctrl with
name "default-<portnum>-<endpointnum>". As the DPI is port 0, and just
one endpoint, the code looks for "default-0-0".
For omap3 board with both DPI and SDI as options (they can't be used at
the same time, though), I imagine it'd be like:
&dss {
vdds_dsi-supply = <&vpll2>;
vdds_sdi-supply = <&vpll2>;
pinctrl-names = "default-0-0", "default-1-0";
pinctrl-0 = <&dss_dpi_pins>;
pinctrl-1 = <&dss_sdi_pins>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dpi_out: endpoint {
};
};
port@1 {
reg = <1>;
sdi_out: endpoint {
};
};
};
};
Any thoughts?
Every time I work with ports/endpoints, I feel that this is needlessly
complex. But I have never come up with any cleaner or simpler way to
handle this.
I also think this multiple-peripherals-per-single-port is not really
display related, although, for some reason, it seems like display is the
most abused hardware. Maybe ports/endpoints or similar should be in the
common driver framework?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-16 10:49 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-16 10:49 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tony Lindgren, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 2606 bytes --]
On 2013-12-13 05:24, Laurent Pinchart wrote:
>> Then DPI, which I think is mostly just level shifters. It's really just
>> a port, as you say.
>>
>> SDI is a bit unclear to me. The registers for it are in the dss_core.
>> There's only a few registers, but it does have a PHY and a PLL. But I
>> guess it's also more of a port than a separate module.
>
> After a quick look at the documentation I would say so. I would be tempted to
> consider RFBI as part of the DSS core, but that's less clear.
I had a look at this, mainly the DPI side so far. There's one extra
complication, which actually affects all other outputs also (and CDF):
pinctrl.
In the current series, I just have pinctrl for each device, with
"default" name, which ends up being used by default without any code on
my part.
However, if DPI is no longer a device, it can't have pinctrl entry. But
this is a wider issue, as the pinctrl should really be per endpoint, not
per device. When an endpoint is selected to be used, a particular
pinmuxing should be taken into use.
I'm not sure what would be the cleanest solution to this. I currently
have this working:
&dss {
pinctrl-names = "default-0-0";
pinctrl-0 = <&dss_dpi_pins>;
port@0 {
dpi_out: endpoint {
remote-endpoint = <&tfp410_in>;
data-lines = <24>;
};
};
};
So here I have 'port@0' for DSS, which is the DPI output, and it has a
single endpoint. For DSS device, I have pinctrl data.
When the DPI endpoint is initialized, the code looks for pinctrl with
name "default-<portnum>-<endpointnum>". As the DPI is port 0, and just
one endpoint, the code looks for "default-0-0".
For omap3 board with both DPI and SDI as options (they can't be used at
the same time, though), I imagine it'd be like:
&dss {
vdds_dsi-supply = <&vpll2>;
vdds_sdi-supply = <&vpll2>;
pinctrl-names = "default-0-0", "default-1-0";
pinctrl-0 = <&dss_dpi_pins>;
pinctrl-1 = <&dss_sdi_pins>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
dpi_out: endpoint {
};
};
port@1 {
reg = <1>;
sdi_out: endpoint {
};
};
};
};
Any thoughts?
Every time I work with ports/endpoints, I feel that this is needlessly
complex. But I have never come up with any cleaner or simpler way to
handle this.
I also think this multiple-peripherals-per-single-port is not really
display related, although, for some reason, it seems like display is the
most abused hardware. Maybe ports/endpoints or similar should be in the
common driver framework?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread[parent not found: <52AEDA9F.2020609-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
[not found] ` <52AEDA9F.2020609-l0cyMroinI0@public.gmane.org>
@ 2013-12-16 13:55 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-16 13:55 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]
Hi Tomi,
On Monday 16 December 2013 12:49:03 Tomi Valkeinen wrote:
> On 2013-12-13 05:24, Laurent Pinchart wrote:
> >> Then DPI, which I think is mostly just level shifters. It's really just
> >> a port, as you say.
> >>
> >> SDI is a bit unclear to me. The registers for it are in the dss_core.
> >> There's only a few registers, but it does have a PHY and a PLL. But I
> >> guess it's also more of a port than a separate module.
> >
> > After a quick look at the documentation I would say so. I would be tempted
> > to consider RFBI as part of the DSS core, but that's less clear.
>
> I had a look at this, mainly the DPI side so far. There's one extra
> complication, which actually affects all other outputs also (and CDF):
> pinctrl.
>
> In the current series, I just have pinctrl for each device, with
> "default" name, which ends up being used by default without any code on
> my part.
>
> However, if DPI is no longer a device, it can't have pinctrl entry. But
> this is a wider issue, as the pinctrl should really be per endpoint, not
> per device. When an endpoint is selected to be used, a particular
> pinmuxing should be taken into use.
>
> I'm not sure what would be the cleanest solution to this. I currently
> have this working:
>
> &dss {
> pinctrl-names = "default-0-0";
> pinctrl-0 = <&dss_dpi_pins>;
>
> port@0 {
> dpi_out: endpoint {
> remote-endpoint = <&tfp410_in>;
> data-lines = <24>;
> };
> };
> };
>
> So here I have 'port@0' for DSS, which is the DPI output, and it has a
> single endpoint. For DSS device, I have pinctrl data.
>
> When the DPI endpoint is initialized, the code looks for pinctrl with
> name "default-<portnum>-<endpointnum>". As the DPI is port 0, and just
> one endpoint, the code looks for "default-0-0".
>
> For omap3 board with both DPI and SDI as options (they can't be used at
> the same time, though), I imagine it'd be like:
>
> &dss {
> vdds_dsi-supply = <&vpll2>;
> vdds_sdi-supply = <&vpll2>;
>
> pinctrl-names = "default-0-0", "default-1-0";
> pinctrl-0 = <&dss_dpi_pins>;
> pinctrl-1 = <&dss_sdi_pins>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> dpi_out: endpoint {
> };
> };
>
> port@1 {
> reg = <1>;
> sdi_out: endpoint {
> };
> };
> };
> };
>
> Any thoughts?
Would it be feasible to put the pinctrl properties in the port or endpoint
nodes ? That could require changes to the pinctrl core, most probably just
exporting a few internal functions (possibly requiring a bit of refactoring),
but it might make the result simpler.
> Every time I work with ports/endpoints, I feel that this is needlessly
> complex. But I have never come up with any cleaner or simpler way to
> handle this.
>
> I also think this multiple-peripherals-per-single-port is not really
> display related, although, for some reason, it seems like display is the
> most abused hardware. Maybe ports/endpoints or similar should be in the
> common driver framework?
Ports and endpoints is the way we have come up with to describe a graph in DT.
I wouldn't call it needlessly complex, as I believe it's both generic and
simple, but I agree it's a bit on the verbose side. Omitting the ports and
port nodes as a shortcut might be a good way to reduce the verbosity.
Regarding moving this to the device core, I'm not opposed to it, but I'd like
to see interest from other users first.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 13/26] ARM: omap3.dtsi: add omapdss information
@ 2013-12-16 13:55 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-16 13:55 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Tony Lindgren, linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge
[-- Attachment #1: Type: text/plain, Size: 3465 bytes --]
Hi Tomi,
On Monday 16 December 2013 12:49:03 Tomi Valkeinen wrote:
> On 2013-12-13 05:24, Laurent Pinchart wrote:
> >> Then DPI, which I think is mostly just level shifters. It's really just
> >> a port, as you say.
> >>
> >> SDI is a bit unclear to me. The registers for it are in the dss_core.
> >> There's only a few registers, but it does have a PHY and a PLL. But I
> >> guess it's also more of a port than a separate module.
> >
> > After a quick look at the documentation I would say so. I would be tempted
> > to consider RFBI as part of the DSS core, but that's less clear.
>
> I had a look at this, mainly the DPI side so far. There's one extra
> complication, which actually affects all other outputs also (and CDF):
> pinctrl.
>
> In the current series, I just have pinctrl for each device, with
> "default" name, which ends up being used by default without any code on
> my part.
>
> However, if DPI is no longer a device, it can't have pinctrl entry. But
> this is a wider issue, as the pinctrl should really be per endpoint, not
> per device. When an endpoint is selected to be used, a particular
> pinmuxing should be taken into use.
>
> I'm not sure what would be the cleanest solution to this. I currently
> have this working:
>
> &dss {
> pinctrl-names = "default-0-0";
> pinctrl-0 = <&dss_dpi_pins>;
>
> port@0 {
> dpi_out: endpoint {
> remote-endpoint = <&tfp410_in>;
> data-lines = <24>;
> };
> };
> };
>
> So here I have 'port@0' for DSS, which is the DPI output, and it has a
> single endpoint. For DSS device, I have pinctrl data.
>
> When the DPI endpoint is initialized, the code looks for pinctrl with
> name "default-<portnum>-<endpointnum>". As the DPI is port 0, and just
> one endpoint, the code looks for "default-0-0".
>
> For omap3 board with both DPI and SDI as options (they can't be used at
> the same time, though), I imagine it'd be like:
>
> &dss {
> vdds_dsi-supply = <&vpll2>;
> vdds_sdi-supply = <&vpll2>;
>
> pinctrl-names = "default-0-0", "default-1-0";
> pinctrl-0 = <&dss_dpi_pins>;
> pinctrl-1 = <&dss_sdi_pins>;
>
> ports {
> #address-cells = <1>;
> #size-cells = <0>;
>
> port@0 {
> reg = <0>;
> dpi_out: endpoint {
> };
> };
>
> port@1 {
> reg = <1>;
> sdi_out: endpoint {
> };
> };
> };
> };
>
> Any thoughts?
Would it be feasible to put the pinctrl properties in the port or endpoint
nodes ? That could require changes to the pinctrl core, most probably just
exporting a few internal functions (possibly requiring a bit of refactoring),
but it might make the result simpler.
> Every time I work with ports/endpoints, I feel that this is needlessly
> complex. But I have never come up with any cleaner or simpler way to
> handle this.
>
> I also think this multiple-peripherals-per-single-port is not really
> display related, although, for some reason, it seems like display is the
> most abused hardware. Maybe ports/endpoints or similar should be in the
> common driver framework?
Ports and endpoints is the way we have come up with to describe a graph in DT.
I wouldn't call it needlessly complex, as I believe it's both generic and
simple, but I agree it's a bit on the verbose side. Omitting the ports and
port nodes as a shortcut might be a good way to reduce the verbosity.
Regarding moving this to the device core, I'm not opposed to it, but I'd like
to see interest from other users first.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 14/26] ARM: omap4.dtsi: add omapdss information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 58 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e05853afcd..a9c0161d5368 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -705,5 +705,63 @@
dmas = <&sdma 117>, <&sdma 116>;
dma-names = "tx", "rx";
};
+
+ dss@58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ ti,hwmods = "dss_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <0 25 0x4>;
+ ti,hwmods = "dss_dispc";
+ };
+
+ dpi: encoder@0 {
+ compatible = "ti,omap4-dpi";
+ };
+
+ rfbi: encoder@58002000 {
+ compatible = "ti,omap4-rfbi";
+ reg = <0x58002000 0x1000>;
+ ti,hwmods = "dss_rfbi";
+ };
+
+ /*
+ * Accessing venc registers cause a crash on omap4, so
+ * this is disabled for now.
+ */
+ venc: encoder@58003000 {
+ compatible = "ti,omap4-venc";
+ reg = <0x58003000 0x1000>;
+ ti,hwmods = "dss_venc";
+ status = "disabled";
+ };
+
+ dsi1: encoder@58004000 {
+ compatible = "ti,omap4-dsi";
+ reg = <0x58004000 0x200>;
+ interrupts = <0 53 0x4>;
+ ti,hwmods = "dss_dsi1";
+ };
+
+ dsi2: encoder@58005000 {
+ compatible = "ti,omap4-dsi";
+ reg = <0x58005000 0x200>;
+ interrupts = <0 84 0x4>;
+ ti,hwmods = "dss_dsi2";
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x1000>;
+ interrupts = <0 101 0x4>;
+ ti,hwmods = "dss_hdmi";
+ };
+ };
};
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 14/26] ARM: omap4.dtsi: add omapdss information
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4.dtsi | 58 ++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 58 insertions(+)
diff --git a/arch/arm/boot/dts/omap4.dtsi b/arch/arm/boot/dts/omap4.dtsi
index a1e05853afcd..a9c0161d5368 100644
--- a/arch/arm/boot/dts/omap4.dtsi
+++ b/arch/arm/boot/dts/omap4.dtsi
@@ -705,5 +705,63 @@
dmas = <&sdma 117>, <&sdma 116>;
dma-names = "tx", "rx";
};
+
+ dss@58000000 {
+ compatible = "ti,omap4-dss", "simple-bus";
+ reg = <0x58000000 0x80>;
+ ti,hwmods = "dss_core";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ dispc@58001000 {
+ compatible = "ti,omap4-dispc";
+ reg = <0x58001000 0x1000>;
+ interrupts = <0 25 0x4>;
+ ti,hwmods = "dss_dispc";
+ };
+
+ dpi: encoder@0 {
+ compatible = "ti,omap4-dpi";
+ };
+
+ rfbi: encoder@58002000 {
+ compatible = "ti,omap4-rfbi";
+ reg = <0x58002000 0x1000>;
+ ti,hwmods = "dss_rfbi";
+ };
+
+ /*
+ * Accessing venc registers cause a crash on omap4, so
+ * this is disabled for now.
+ */
+ venc: encoder@58003000 {
+ compatible = "ti,omap4-venc";
+ reg = <0x58003000 0x1000>;
+ ti,hwmods = "dss_venc";
+ status = "disabled";
+ };
+
+ dsi1: encoder@58004000 {
+ compatible = "ti,omap4-dsi";
+ reg = <0x58004000 0x200>;
+ interrupts = <0 53 0x4>;
+ ti,hwmods = "dss_dsi1";
+ };
+
+ dsi2: encoder@58005000 {
+ compatible = "ti,omap4-dsi";
+ reg = <0x58005000 0x200>;
+ interrupts = <0 84 0x4>;
+ ti,hwmods = "dss_dsi2";
+ };
+
+ hdmi: encoder@58006000 {
+ compatible = "ti,omap4-hdmi";
+ reg = <0x58006000 0x1000>;
+ interrupts = <0 101 0x4>;
+ ti,hwmods = "dss_hdmi";
+ };
+ };
};
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 15/26] ARM: omap4-panda.dts: add display information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 102 ++++++++++++++++++++++++++++++
1 file changed, 102 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 298e85020e1b..51a79756e67e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -409,3 +409,105 @@
&usbhsehci {
phys = <&hsusb1_phy>;
};
+
+&dpi {
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&dsi1 {
+ vdds_dsi-supply = <&vcxio>;
+};
+
+&dsi2 {
+ vdds_dsi-supply = <&vcxio>;
+};
+
+&hdmi {
+ vdda_hdmi_dac-supply = <&vdac>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 0>; /* 0, power-down */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "ti,dvi-connector";
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
+ <&gpio2 9 0>, /* 41, LS OE */
+ <&gpio2 31 0>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@1 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@1 {
+ compatible = "ti,hdmi-connector";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 15/26] ARM: omap4-panda.dts: add display information
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 102 ++++++++++++++++++++++++++++++
1 file changed, 102 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
index 298e85020e1b..51a79756e67e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -409,3 +409,105 @@
&usbhsehci {
phys = <&hsusb1_phy>;
};
+
+&dpi {
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&dsi1 {
+ vdds_dsi-supply = <&vcxio>;
+};
+
+&dsi2 {
+ vdds_dsi-supply = <&vcxio>;
+};
+
+&hdmi {
+ vdda_hdmi_dac-supply = <&vdac>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &hdmi0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio1 0 0>; /* 0, power-down */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "ti,dvi-connector";
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tpd12s015: encoder@1 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
+ <&gpio2 9 0>, /* 41, LS OE */
+ <&gpio2 31 0>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@1 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@1 {
+ compatible = "ti,hdmi-connector";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-06 8:57 ` Javier Martinez Canillas
-1 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-06 8:57 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap4-panda-common.dtsi | 102 ++++++++++++++++++++++++++++++
> 1 file changed, 102 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 298e85020e1b..51a79756e67e 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -409,3 +409,105 @@
> &usbhsehci {
> phys = <&hsusb1_phy>;
> };
> +
> +&dpi {
> + dpi_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + data-lines = <24>;
> + };
> +};
> +
> +&dsi1 {
> + vdds_dsi-supply = <&vcxio>;
> +};
> +
> +&dsi2 {
> + vdds_dsi-supply = <&vcxio>;
> +};
> +
> +&hdmi {
> + vdda_hdmi_dac-supply = <&vdac>;
> +
> + hdmi_out: endpoint {
> + remote-endpoint = <&tpd12s015_in>;
> + };
> +};
> +
> +/ {
> + aliases {
> + display0 = &dvi0;
> + display1 = &hdmi0;
> + };
> +
> + tfp410: encoder@0 {
> + compatible = "ti,tfp410";
> + gpios = <&gpio1 0 0>; /* 0, power-down */
> +
Please use the constants from include/dt-bindings/ instead of magic
numbers, i.e:
gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint@0 {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint@1 {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + dvi0: connector@0 {
> + compatible = "ti,dvi-connector";
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> +
> + tpd12s015: encoder@1 {
> + compatible = "ti,tpd12s015";
> +
> + gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
> + <&gpio2 9 0>, /* 41, LS OE */
> + <&gpio2 31 0>; /* 63, HPD */
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tpd12s015_in: endpoint@0 {
> + remote-endpoint = <&hdmi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tpd12s015_out: endpoint@1 {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + hdmi0: connector@1 {
> + compatible = "ti,hdmi-connector";
> +
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tpd12s015_out>;
> + };
> + };
> +};
> --
> 1.8.3.2
>
Best regards,
Javier
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
@ 2013-12-06 8:57 ` Javier Martinez Canillas
0 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-06 8:57 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap4-panda-common.dtsi | 102 ++++++++++++++++++++++++++++++
> 1 file changed, 102 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi b/arch/arm/boot/dts/omap4-panda-common.dtsi
> index 298e85020e1b..51a79756e67e 100644
> --- a/arch/arm/boot/dts/omap4-panda-common.dtsi
> +++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
> @@ -409,3 +409,105 @@
> &usbhsehci {
> phys = <&hsusb1_phy>;
> };
> +
> +&dpi {
> + dpi_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + data-lines = <24>;
> + };
> +};
> +
> +&dsi1 {
> + vdds_dsi-supply = <&vcxio>;
> +};
> +
> +&dsi2 {
> + vdds_dsi-supply = <&vcxio>;
> +};
> +
> +&hdmi {
> + vdda_hdmi_dac-supply = <&vdac>;
> +
> + hdmi_out: endpoint {
> + remote-endpoint = <&tpd12s015_in>;
> + };
> +};
> +
> +/ {
> + aliases {
> + display0 = &dvi0;
> + display1 = &hdmi0;
> + };
> +
> + tfp410: encoder@0 {
> + compatible = "ti,tfp410";
> + gpios = <&gpio1 0 0>; /* 0, power-down */
> +
Please use the constants from include/dt-bindings/ instead of magic
numbers, i.e:
gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint@0 {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint@1 {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + dvi0: connector@0 {
> + compatible = "ti,dvi-connector";
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> +
> + tpd12s015: encoder@1 {
> + compatible = "ti,tpd12s015";
> +
> + gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
> + <&gpio2 9 0>, /* 41, LS OE */
> + <&gpio2 31 0>; /* 63, HPD */
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tpd12s015_in: endpoint@0 {
> + remote-endpoint = <&hdmi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tpd12s015_out: endpoint@1 {
> + remote-endpoint = <&hdmi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + hdmi0: connector@1 {
> + compatible = "ti,hdmi-connector";
> +
> + hdmi_connector_in: endpoint {
> + remote-endpoint = <&tpd12s015_out>;
> + };
> + };
> +};
> --
> 1.8.3.2
>
Best regards,
Javier
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
2013-12-06 8:57 ` Javier Martinez Canillas
@ 2013-12-09 12:56 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-09 12:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>> + tfp410: encoder@0 {
>> + compatible = "ti,tfp410";
>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>> +
>
> Please use the constants from include/dt-bindings/ instead of magic
> numbers, i.e:
>
> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
Thanks, fixed now (for all .dts files)
However... The TFP410 gpio is "power-down". I think we should actually
mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
@ 2013-12-09 12:56 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-09 12:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 563 bytes --]
On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>> + tfp410: encoder@0 {
>> + compatible = "ti,tfp410";
>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>> +
>
> Please use the constants from include/dt-bindings/ instead of magic
> numbers, i.e:
>
> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
Thanks, fixed now (for all .dts files)
However... The TFP410 gpio is "power-down". I think we should actually
mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
2013-12-09 12:56 ` Tomi Valkeinen
@ 2013-12-09 15:09 ` Javier Martinez Canillas
-1 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-09 15:09 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Enric Balletbo Serra
Hi Tomi,
On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>
>>> + tfp410: encoder@0 {
>>> + compatible = "ti,tfp410";
>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>> +
>>
>> Please use the constants from include/dt-bindings/ instead of magic
>> numbers, i.e:
>>
>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>
> Thanks, fixed now (for all .dts files)
>
> However... The TFP410 gpio is "power-down". I think we should actually
> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>
yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
GPIO_ACTIVE_HIGH as 0.
I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
the IGEPv2 DTS instad and is because the IGEP board uses a hardware
signal inverter but that is a special case. I don't know about the
Panda board since I haven't looked at its datasheet.
Thanks a lot and best regards,
Javier
[0]: http://www.ti.com/lit/ds/slds145b/slds145b.pdf
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
@ 2013-12-09 15:09 ` Javier Martinez Canillas
0 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-09 15:09 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Enric Balletbo Serra
Hi Tomi,
On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>
>>> + tfp410: encoder@0 {
>>> + compatible = "ti,tfp410";
>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>> +
>>
>> Please use the constants from include/dt-bindings/ instead of magic
>> numbers, i.e:
>>
>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>
> Thanks, fixed now (for all .dts files)
>
> However... The TFP410 gpio is "power-down". I think we should actually
> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>
yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
GPIO_ACTIVE_HIGH as 0.
I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
the IGEPv2 DTS instad and is because the IGEP board uses a hardware
signal inverter but that is a special case. I don't know about the
Panda board since I haven't looked at its datasheet.
Thanks a lot and best regards,
Javier
[0]: http://www.ti.com/lit/ds/slds145b/slds145b.pdf
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
2013-12-09 15:09 ` Javier Martinez Canillas
@ 2013-12-09 15:30 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-09 15:30 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Enric Balletbo Serra
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On 2013-12-09 17:09, Javier Martinez Canillas wrote:
> Hi Tomi,
>
> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>
>>>> + tfp410: encoder@0 {
>>>> + compatible = "ti,tfp410";
>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>> +
>>>
>>> Please use the constants from include/dt-bindings/ instead of magic
>>> numbers, i.e:
>>>
>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>
>> Thanks, fixed now (for all .dts files)
>>
>> However... The TFP410 gpio is "power-down". I think we should actually
>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>
>
> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
> GPIO_ACTIVE_HIGH as 0.
>
> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
> signal inverter but that is a special case. I don't know about the
> Panda board since I haven't looked at its datasheet.
Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
as it were active-low. The flag is ignored.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
@ 2013-12-09 15:30 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-09 15:30 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Enric Balletbo Serra
[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]
On 2013-12-09 17:09, Javier Martinez Canillas wrote:
> Hi Tomi,
>
> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>
>>>> + tfp410: encoder@0 {
>>>> + compatible = "ti,tfp410";
>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>> +
>>>
>>> Please use the constants from include/dt-bindings/ instead of magic
>>> numbers, i.e:
>>>
>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>
>> Thanks, fixed now (for all .dts files)
>>
>> However... The TFP410 gpio is "power-down". I think we should actually
>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>
>
> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
> GPIO_ACTIVE_HIGH as 0.
>
> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
> signal inverter but that is a special case. I don't know about the
> Panda board since I haven't looked at its datasheet.
Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
as it were active-low. The flag is ignored.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
2013-12-09 15:30 ` Tomi Valkeinen
@ 2013-12-09 16:53 ` Javier Martinez Canillas
-1 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-09 16:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Enric Balletbo Serra
Hi Tomi,
On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>> Hi Tomi,
>>
>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>
>>>>> + tfp410: encoder@0 {
>>>>> + compatible = "ti,tfp410";
>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>> +
>>>>
>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>> numbers, i.e:
>>>>
>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>
>>> Thanks, fixed now (for all .dts files)
>>>
>>> However... The TFP410 gpio is "power-down". I think we should actually
>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>
>>
>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>> GPIO_ACTIVE_HIGH as 0.
>>
>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>> signal inverter but that is a special case. I don't know about the
>> Panda board since I haven't looked at its datasheet.
>
> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
> as it were active-low. The flag is ignored.
>
How weird, it does work on the IGEPv2 but you are right I just looked
at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
that it indeed just does:
r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
GPIOF_OUT_INIT_LOW, "tfp410 PD");
So I don't know how it is working... I'm on the road and won't have
access to my IGEPv2 to dig further on this. Maybe Enric can shed more
light on this.
> Tomi
>
>
Thanks a lot and best regards,
Javier
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
@ 2013-12-09 16:53 ` Javier Martinez Canillas
0 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-09 16:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Enric Balletbo Serra
Hi Tomi,
On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>> Hi Tomi,
>>
>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>
>>>>> + tfp410: encoder@0 {
>>>>> + compatible = "ti,tfp410";
>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>> +
>>>>
>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>> numbers, i.e:
>>>>
>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>
>>> Thanks, fixed now (for all .dts files)
>>>
>>> However... The TFP410 gpio is "power-down". I think we should actually
>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>
>>
>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>> GPIO_ACTIVE_HIGH as 0.
>>
>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>> signal inverter but that is a special case. I don't know about the
>> Panda board since I haven't looked at its datasheet.
>
> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
> as it were active-low. The flag is ignored.
>
How weird, it does work on the IGEPv2 but you are right I just looked
at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
that it indeed just does:
r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
GPIOF_OUT_INIT_LOW, "tfp410 PD");
So I don't know how it is working... I'm on the road and won't have
access to my IGEPv2 to dig further on this. Maybe Enric can shed more
light on this.
> Tomi
>
>
Thanks a lot and best regards,
Javier
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
2013-12-09 16:53 ` Javier Martinez Canillas
@ 2013-12-10 10:56 ` Enric Balletbo Serra
-1 siblings, 0 replies; 183+ messages in thread
From: Enric Balletbo Serra @ 2013-12-10 10:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
Hi all,
2013/12/9 Javier Martinez Canillas <javier@dowhile0.org>:
> Hi Tomi,
>
> On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>>> Hi Tomi,
>>>
>>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>>
>>>>>> + tfp410: encoder@0 {
>>>>>> + compatible = "ti,tfp410";
>>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>>> +
>>>>>
>>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>>> numbers, i.e:
>>>>>
>>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>>
>>>> Thanks, fixed now (for all .dts files)
>>>>
>>>> However... The TFP410 gpio is "power-down". I think we should actually
>>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>>
>>>
>>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>>> GPIO_ACTIVE_HIGH as 0.
>>>
>>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>>> signal inverter but that is a special case. I don't know about the
>>> Panda board since I haven't looked at its datasheet.
>>
>> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
>> as it were active-low. The flag is ignored.
>>
>
> How weird, it does work on the IGEPv2 but you are right I just looked
> at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
> that it indeed just does:
>
> r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
> GPIOF_OUT_INIT_LOW, "tfp410 PD");
>
> So I don't know how it is working... I'm on the road and won't have
> access to my IGEPv2 to dig further on this. Maybe Enric can shed more
> light on this.
>
On IGEPv2 the GPIO that controls the power-down pin is connected
through a dual/buffer driver [1]. This driver is only a buffer, not
inverts the signal (I had told you wrong, sorry Javier ), so the pin
continues being active low.
As both of you pointed the driver ignores the flag to handle the PD
GPIO, so doesn't matter if in the device tree we put GPIO_ACTIVE_HIGH
or GPIO_ACTIVE_LOW, so simply it works. About the patch to support
display for IGEP, to be coherent, the gpio should be defined as
GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH. I have tested, and of course,
works.
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 2569d60..d185e06 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -233,7 +233,7 @@
tfp410: encoder@0 {
compatible = "ti,tfp410";
- gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
+ gpios = <&gpio6 10 GPIO_ACTIVE_LOW>; /* 170, power-down */
ports {
#address-cells = <1>;
[1] http://www.ti.com/product/sn74lvc2g07
Best regards,
Enric
>> Tomi
>>
>>
>
> Thanks a lot and best regards,
> Javier
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
@ 2013-12-10 10:56 ` Enric Balletbo Serra
0 siblings, 0 replies; 183+ messages in thread
From: Enric Balletbo Serra @ 2013-12-10 10:56 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Tony Lindgren
Hi all,
2013/12/9 Javier Martinez Canillas <javier@dowhile0.org>:
> Hi Tomi,
>
> On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>>> Hi Tomi,
>>>
>>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>>
>>>>>> + tfp410: encoder@0 {
>>>>>> + compatible = "ti,tfp410";
>>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>>> +
>>>>>
>>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>>> numbers, i.e:
>>>>>
>>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>>
>>>> Thanks, fixed now (for all .dts files)
>>>>
>>>> However... The TFP410 gpio is "power-down". I think we should actually
>>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>>
>>>
>>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>>> GPIO_ACTIVE_HIGH as 0.
>>>
>>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>>> signal inverter but that is a special case. I don't know about the
>>> Panda board since I haven't looked at its datasheet.
>>
>> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
>> as it were active-low. The flag is ignored.
>>
>
> How weird, it does work on the IGEPv2 but you are right I just looked
> at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
> that it indeed just does:
>
> r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
> GPIOF_OUT_INIT_LOW, "tfp410 PD");
>
> So I don't know how it is working... I'm on the road and won't have
> access to my IGEPv2 to dig further on this. Maybe Enric can shed more
> light on this.
>
On IGEPv2 the GPIO that controls the power-down pin is connected
through a dual/buffer driver [1]. This driver is only a buffer, not
inverts the signal (I had told you wrong, sorry Javier ), so the pin
continues being active low.
As both of you pointed the driver ignores the flag to handle the PD
GPIO, so doesn't matter if in the device tree we put GPIO_ACTIVE_HIGH
or GPIO_ACTIVE_LOW, so simply it works. About the patch to support
display for IGEP, to be coherent, the gpio should be defined as
GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH. I have tested, and of course,
works.
diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
b/arch/arm/boot/dts/omap3-igep0020.dts
index 2569d60..d185e06 100644
--- a/arch/arm/boot/dts/omap3-igep0020.dts
+++ b/arch/arm/boot/dts/omap3-igep0020.dts
@@ -233,7 +233,7 @@
tfp410: encoder@0 {
compatible = "ti,tfp410";
- gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
+ gpios = <&gpio6 10 GPIO_ACTIVE_LOW>; /* 170, power-down */
ports {
#address-cells = <1>;
[1] http://www.ti.com/product/sn74lvc2g07
Best regards,
Enric
>> Tomi
>>
>>
>
> Thanks a lot and best regards,
> Javier
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
2013-12-10 10:56 ` Enric Balletbo Serra
@ 2013-12-10 12:10 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-10 12:10 UTC (permalink / raw)
To: Enric Balletbo Serra, Javier Martinez Canillas
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]
On 2013-12-10 12:56, Enric Balletbo Serra wrote:
> Hi all,
>
> 2013/12/9 Javier Martinez Canillas <javier@dowhile0.org>:
>> Hi Tomi,
>>
>> On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>>>> Hi Tomi,
>>>>
>>>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>>>
>>>>>>> + tfp410: encoder@0 {
>>>>>>> + compatible = "ti,tfp410";
>>>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>>>> +
>>>>>>
>>>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>>>> numbers, i.e:
>>>>>>
>>>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>>>
>>>>> Thanks, fixed now (for all .dts files)
>>>>>
>>>>> However... The TFP410 gpio is "power-down". I think we should actually
>>>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>>>
>>>>
>>>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>>>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>>>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>>>> GPIO_ACTIVE_HIGH as 0.
>>>>
>>>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>>>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>>>> signal inverter but that is a special case. I don't know about the
>>>> Panda board since I haven't looked at its datasheet.
>>>
>>> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
>>> as it were active-low. The flag is ignored.
>>>
>>
>> How weird, it does work on the IGEPv2 but you are right I just looked
>> at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
>> that it indeed just does:
>>
>> r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
>> GPIOF_OUT_INIT_LOW, "tfp410 PD");
>>
>> So I don't know how it is working... I'm on the road and won't have
>> access to my IGEPv2 to dig further on this. Maybe Enric can shed more
>> light on this.
>>
>
> On IGEPv2 the GPIO that controls the power-down pin is connected
> through a dual/buffer driver [1]. This driver is only a buffer, not
> inverts the signal (I had told you wrong, sorry Javier ), so the pin
> continues being active low.
>
> As both of you pointed the driver ignores the flag to handle the PD
> GPIO, so doesn't matter if in the device tree we put GPIO_ACTIVE_HIGH
> or GPIO_ACTIVE_LOW, so simply it works. About the patch to support
> display for IGEP, to be coherent, the gpio should be defined as
> GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH. I have tested, and of course,
> works.
>
>
> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
> b/arch/arm/boot/dts/omap3-igep0020.dts
> index 2569d60..d185e06 100644
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -233,7 +233,7 @@
>
> tfp410: encoder@0 {
> compatible = "ti,tfp410";
> - gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
> + gpios = <&gpio6 10 GPIO_ACTIVE_LOW>; /* 170, power-down */
>
> ports {
> #address-cells = <1>;
>
>
> [1] http://www.ti.com/product/sn74lvc2g07
Ok, looks good. I have changed the TFP gpios to active-low in my series
for all .dts files, which includes the igep0020.dts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 15/26] ARM: omap4-panda.dts: add display information
@ 2013-12-10 12:10 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-10 12:10 UTC (permalink / raw)
To: Enric Balletbo Serra, Javier Martinez Canillas
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 3533 bytes --]
On 2013-12-10 12:56, Enric Balletbo Serra wrote:
> Hi all,
>
> 2013/12/9 Javier Martinez Canillas <javier@dowhile0.org>:
>> Hi Tomi,
>>
>> On Mon, Dec 9, 2013 at 4:30 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> On 2013-12-09 17:09, Javier Martinez Canillas wrote:
>>>> Hi Tomi,
>>>>
>>>> On Mon, Dec 9, 2013 at 1:56 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>>>> On 2013-12-06 10:57, Javier Martinez Canillas wrote:
>>>>>
>>>>>>> + tfp410: encoder@0 {
>>>>>>> + compatible = "ti,tfp410";
>>>>>>> + gpios = <&gpio1 0 0>; /* 0, power-down */
>>>>>>> +
>>>>>>
>>>>>> Please use the constants from include/dt-bindings/ instead of magic
>>>>>> numbers, i.e:
>>>>>>
>>>>>> gpios = <&gpio1 0 GPIO_ACTIVE_HIGH>; /* 0, power-down */
>>>>>
>>>>> Thanks, fixed now (for all .dts files)
>>>>>
>>>>> However... The TFP410 gpio is "power-down". I think we should actually
>>>>> mark it as GPIO_ACTIVE_LOW, as setting it to 0 powers down the device.
>>>>>
>>>>
>>>> yes, I looked at the TFP410 datasheet [0] and the Power Down pin is
>>>> indeed an active-low, I just replaced to GPIO_ACTIVE_HIGH since you
>>>> were using a constant 0 and include/dt-bindings/gpio/gpio.h defines
>>>> GPIO_ACTIVE_HIGH as 0.
>>>>
>>>> I just asked to Enric why we use GPIO_ACTIVE_HIGH for the PD pin on
>>>> the IGEPv2 DTS instad and is because the IGEP board uses a hardware
>>>> signal inverter but that is a special case. I don't know about the
>>>> Panda board since I haven't looked at its datasheet.
>>>
>>> Oh. Does it work on igep? The TFP410 driver always handles the PD GPIO
>>> as it were active-low. The flag is ignored.
>>>
>>
>> How weird, it does work on the IGEPv2 but you are right I just looked
>> at at drivers/video/omap2/displays-new/encoder-tfp410.c and I see
>> that it indeed just does:
>>
>> r = devm_gpio_request_one(&pdev->dev, ddata->pd_gpio,
>> GPIOF_OUT_INIT_LOW, "tfp410 PD");
>>
>> So I don't know how it is working... I'm on the road and won't have
>> access to my IGEPv2 to dig further on this. Maybe Enric can shed more
>> light on this.
>>
>
> On IGEPv2 the GPIO that controls the power-down pin is connected
> through a dual/buffer driver [1]. This driver is only a buffer, not
> inverts the signal (I had told you wrong, sorry Javier ), so the pin
> continues being active low.
>
> As both of you pointed the driver ignores the flag to handle the PD
> GPIO, so doesn't matter if in the device tree we put GPIO_ACTIVE_HIGH
> or GPIO_ACTIVE_LOW, so simply it works. About the patch to support
> display for IGEP, to be coherent, the gpio should be defined as
> GPIO_ACTIVE_LOW not GPIO_ACTIVE_HIGH. I have tested, and of course,
> works.
>
>
> diff --git a/arch/arm/boot/dts/omap3-igep0020.dts
> b/arch/arm/boot/dts/omap3-igep0020.dts
> index 2569d60..d185e06 100644
> --- a/arch/arm/boot/dts/omap3-igep0020.dts
> +++ b/arch/arm/boot/dts/omap3-igep0020.dts
> @@ -233,7 +233,7 @@
>
> tfp410: encoder@0 {
> compatible = "ti,tfp410";
> - gpios = <&gpio6 10 GPIO_ACTIVE_HIGH>; /* 170, power-down */
> + gpios = <&gpio6 10 GPIO_ACTIVE_LOW>; /* 170, power-down */
>
> ports {
> #address-cells = <1>;
>
>
> [1] http://www.ti.com/product/sn74lvc2g07
Ok, looks good. I have changed the TFP gpios to active-low in my series
for all .dts files, which includes the igep0020.dts.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 16/26] ARM: omap4-sdp.dts: add display information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 91 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 5fc3f43c5a81..e3048f849612 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -550,3 +550,94 @@
mode = <3>;
power = <50>;
};
+
+&dsi1 {
+ vdds_dsi-supply = <&vcxio>;
+
+ dsi1_out_ep: endpoint {
+ remote-endpoint = <&lcd0_in>;
+ lanes = <0 1 2 3 4 5>;
+ };
+
+ lcd0: display@0 {
+ compatible = "tpo,taal", "panel-dsi-cm";
+
+ gpios = <&gpio4 6 0>; /* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = <&dsi1_out_ep>;
+ };
+ };
+};
+
+&dsi2 {
+ vdds_dsi-supply = <&vcxio>;
+
+ dsi2_out_ep: endpoint {
+ remote-endpoint = <&lcd1_in>;
+ lanes = <0 1 2 3 4 5>;
+ };
+
+ lcd1: display@1 {
+ compatible = "tpo,taal", "panel-dsi-cm";
+
+ gpios = <&gpio4 8 0>; /* 104, reset */
+
+ lcd1_in: endpoint {
+ remote-endpoint = <&dsi2_out_ep>;
+ };
+ };
+};
+
+&hdmi {
+ vdda_hdmi_dac-supply = <&vdac>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ display1 = &lcd1;
+ display2 = &hdmi0;
+ };
+
+ tpd12s015: encoder@0 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
+ <&gpio2 9 0>, /* 41, LS OE */
+ <&gpio2 31 0>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@1 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = "ti,hdmi-connector";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 16/26] ARM: omap4-sdp.dts: add display information
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap4-sdp.dts | 91 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 91 insertions(+)
diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
index 5fc3f43c5a81..e3048f849612 100644
--- a/arch/arm/boot/dts/omap4-sdp.dts
+++ b/arch/arm/boot/dts/omap4-sdp.dts
@@ -550,3 +550,94 @@
mode = <3>;
power = <50>;
};
+
+&dsi1 {
+ vdds_dsi-supply = <&vcxio>;
+
+ dsi1_out_ep: endpoint {
+ remote-endpoint = <&lcd0_in>;
+ lanes = <0 1 2 3 4 5>;
+ };
+
+ lcd0: display@0 {
+ compatible = "tpo,taal", "panel-dsi-cm";
+
+ gpios = <&gpio4 6 0>; /* 102, reset */
+
+ lcd0_in: endpoint {
+ remote-endpoint = <&dsi1_out_ep>;
+ };
+ };
+};
+
+&dsi2 {
+ vdds_dsi-supply = <&vcxio>;
+
+ dsi2_out_ep: endpoint {
+ remote-endpoint = <&lcd1_in>;
+ lanes = <0 1 2 3 4 5>;
+ };
+
+ lcd1: display@1 {
+ compatible = "tpo,taal", "panel-dsi-cm";
+
+ gpios = <&gpio4 8 0>; /* 104, reset */
+
+ lcd1_in: endpoint {
+ remote-endpoint = <&dsi2_out_ep>;
+ };
+ };
+};
+
+&hdmi {
+ vdda_hdmi_dac-supply = <&vdac>;
+
+ hdmi_out: endpoint {
+ remote-endpoint = <&tpd12s015_in>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ display1 = &lcd1;
+ display2 = &hdmi0;
+ };
+
+ tpd12s015: encoder@0 {
+ compatible = "ti,tpd12s015";
+
+ gpios = <&gpio2 28 0>, /* 60, CT CP HPD */
+ <&gpio2 9 0>, /* 41, LS OE */
+ <&gpio2 31 0>; /* 63, HPD */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tpd12s015_in: endpoint@0 {
+ remote-endpoint = <&hdmi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tpd12s015_out: endpoint@1 {
+ remote-endpoint = <&hdmi_connector_in>;
+ };
+ };
+ };
+ };
+
+ hdmi0: connector@0 {
+ compatible = "ti,hdmi-connector";
+
+ hdmi_connector_in: endpoint {
+ remote-endpoint = <&tpd12s015_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-13 9:39 ` Archit Taneja
-1 siblings, 0 replies; 183+ messages in thread
From: Archit Taneja @ 2013-12-13 9:27 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap4-sdp.dts | 91 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 5fc3f43c5a81..e3048f849612 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -550,3 +550,94 @@
> mode = <3>;
> power = <50>;
> };
> +
> +&dsi1 {
> + vdds_dsi-supply = <&vcxio>;
> +
> + dsi1_out_ep: endpoint {
> + remote-endpoint = <&lcd0_in>;
> + lanes = <0 1 2 3 4 5>;
In the previous revision omapdss DT patchset, the lanes node was a
member of the panel DT node, and not the dsi DT node. Any reason to
change this? Does it make more sense this way?
I suppose it's more suitable for dsi to hold the property if 2 panels
are connected on the same bus. Say, one with 4 data lanes, and other
with 2. It would be tricky for the dsi driver to get lane params from 2
different places and merge them somehow.
> + };
> +
> + lcd0: display@0 {
> + compatible = "tpo,taal", "panel-dsi-cm";
> +
> + gpios = <&gpio4 6 0>; /* 102, reset */
> +
> + lcd0_in: endpoint {
> + remote-endpoint = <&dsi1_out_ep>;
> + };
> + };
Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
respectively? I don't see this for panels on other boards.
Archit
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
@ 2013-12-13 9:39 ` Archit Taneja
0 siblings, 0 replies; 183+ messages in thread
From: Archit Taneja @ 2013-12-13 9:39 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap4-sdp.dts | 91 +++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 91 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap4-sdp.dts b/arch/arm/boot/dts/omap4-sdp.dts
> index 5fc3f43c5a81..e3048f849612 100644
> --- a/arch/arm/boot/dts/omap4-sdp.dts
> +++ b/arch/arm/boot/dts/omap4-sdp.dts
> @@ -550,3 +550,94 @@
> mode = <3>;
> power = <50>;
> };
> +
> +&dsi1 {
> + vdds_dsi-supply = <&vcxio>;
> +
> + dsi1_out_ep: endpoint {
> + remote-endpoint = <&lcd0_in>;
> + lanes = <0 1 2 3 4 5>;
In the previous revision omapdss DT patchset, the lanes node was a
member of the panel DT node, and not the dsi DT node. Any reason to
change this? Does it make more sense this way?
I suppose it's more suitable for dsi to hold the property if 2 panels
are connected on the same bus. Say, one with 4 data lanes, and other
with 2. It would be tricky for the dsi driver to get lane params from 2
different places and merge them somehow.
> + };
> +
> + lcd0: display@0 {
> + compatible = "tpo,taal", "panel-dsi-cm";
> +
> + gpios = <&gpio4 6 0>; /* 102, reset */
> +
> + lcd0_in: endpoint {
> + remote-endpoint = <&dsi1_out_ep>;
> + };
> + };
Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
respectively? I don't see this for panels on other boards.
Archit
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
2013-12-13 9:39 ` Archit Taneja
@ 2013-12-13 9:39 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 9:39 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]
On 2013-12-13 11:27, Archit Taneja wrote:
> On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> arch/arm/boot/dts/omap4-sdp.dts | 91
>> +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 91 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>> b/arch/arm/boot/dts/omap4-sdp.dts
>> index 5fc3f43c5a81..e3048f849612 100644
>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>> @@ -550,3 +550,94 @@
>> mode = <3>;
>> power = <50>;
>> };
>> +
>> +&dsi1 {
>> + vdds_dsi-supply = <&vcxio>;
>> +
>> + dsi1_out_ep: endpoint {
>> + remote-endpoint = <&lcd0_in>;
>> + lanes = <0 1 2 3 4 5>;
>
> In the previous revision omapdss DT patchset, the lanes node was a
> member of the panel DT node, and not the dsi DT node. Any reason to
> change this? Does it make more sense this way?
Well, the lane configuration is programmed into the DSI HW. So DSI needs
to know them. Thus the lanes can be considered a property of the DSI.
In some cases, the external encoder or panel also needs to know about
the lanes. In that case, both DSI and the encoder/panel would contain
the same data.
My reasoning where a property belongs to:
If a property is clearly internal to a device, it belongs there. For
example, in this case vdds_dsi-supply is clearly a property of the DSI.
If a property is about the link between two devices, like "lanes" here,
it belongs to both devices. If a device does not need that data for
anything, it can be omitted.
> I suppose it's more suitable for dsi to hold the property if 2 panels
> are connected on the same bus. Say, one with 4 data lanes, and other
> with 2. It would be tricky for the dsi driver to get lane params from 2
> different places and merge them somehow.
It doesn't matter, both would work fine. If the lanes property is in the
DSI node, then the DSI driver finds out the lane config by finding out
which endpoint is used for the panel that's being enabled.
If the lanes property would be in the panel, the panel would pass the
lane config to the DSI when it's enabled.
But I think passing the lane config from panel to DSI (like we do
currently) is not so nice.
>> + };
>> +
>> + lcd0: display@0 {
>> + compatible = "tpo,taal", "panel-dsi-cm";
>> +
>> + gpios = <&gpio4 6 0>; /* 102, reset */
>> +
>> + lcd0_in: endpoint {
>> + remote-endpoint = <&dsi1_out_ep>;
>> + };
>> + };
>
> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
> respectively? I don't see this for panels on other boards.
Yes. The panels are _controlled_ with DSI. We model the child-parent
relationships in DT data based on the control. So an i2c peripheral is
controlled via i2c master, and is thus a child of the i2c master. Same
here. The ports/endpoints are used to define the data path, which is
separate thing from the control path.
DPI panels which don't have any way to control them (except basic things
like gpios) are platform devices without any parent.
If the DPI panel would be controlled with i2c, it'd be a child of an i2c
master.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
@ 2013-12-13 9:39 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 9:39 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]
On 2013-12-13 11:27, Archit Taneja wrote:
> On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> arch/arm/boot/dts/omap4-sdp.dts | 91
>> +++++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 91 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>> b/arch/arm/boot/dts/omap4-sdp.dts
>> index 5fc3f43c5a81..e3048f849612 100644
>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>> @@ -550,3 +550,94 @@
>> mode = <3>;
>> power = <50>;
>> };
>> +
>> +&dsi1 {
>> + vdds_dsi-supply = <&vcxio>;
>> +
>> + dsi1_out_ep: endpoint {
>> + remote-endpoint = <&lcd0_in>;
>> + lanes = <0 1 2 3 4 5>;
>
> In the previous revision omapdss DT patchset, the lanes node was a
> member of the panel DT node, and not the dsi DT node. Any reason to
> change this? Does it make more sense this way?
Well, the lane configuration is programmed into the DSI HW. So DSI needs
to know them. Thus the lanes can be considered a property of the DSI.
In some cases, the external encoder or panel also needs to know about
the lanes. In that case, both DSI and the encoder/panel would contain
the same data.
My reasoning where a property belongs to:
If a property is clearly internal to a device, it belongs there. For
example, in this case vdds_dsi-supply is clearly a property of the DSI.
If a property is about the link between two devices, like "lanes" here,
it belongs to both devices. If a device does not need that data for
anything, it can be omitted.
> I suppose it's more suitable for dsi to hold the property if 2 panels
> are connected on the same bus. Say, one with 4 data lanes, and other
> with 2. It would be tricky for the dsi driver to get lane params from 2
> different places and merge them somehow.
It doesn't matter, both would work fine. If the lanes property is in the
DSI node, then the DSI driver finds out the lane config by finding out
which endpoint is used for the panel that's being enabled.
If the lanes property would be in the panel, the panel would pass the
lane config to the DSI when it's enabled.
But I think passing the lane config from panel to DSI (like we do
currently) is not so nice.
>> + };
>> +
>> + lcd0: display@0 {
>> + compatible = "tpo,taal", "panel-dsi-cm";
>> +
>> + gpios = <&gpio4 6 0>; /* 102, reset */
>> +
>> + lcd0_in: endpoint {
>> + remote-endpoint = <&dsi1_out_ep>;
>> + };
>> + };
>
> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
> respectively? I don't see this for panels on other boards.
Yes. The panels are _controlled_ with DSI. We model the child-parent
relationships in DT data based on the control. So an i2c peripheral is
controlled via i2c master, and is thus a child of the i2c master. Same
here. The ports/endpoints are used to define the data path, which is
separate thing from the control path.
DPI panels which don't have any way to control them (except basic things
like gpios) are platform devices without any parent.
If the DPI panel would be controlled with i2c, it'd be a child of an i2c
master.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
2013-12-13 9:39 ` Tomi Valkeinen
@ 2013-12-13 9:58 ` Archit Taneja
-1 siblings, 0 replies; 183+ messages in thread
From: Archit Taneja @ 2013-12-13 9:58 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
On Friday 13 December 2013 03:09 PM, Tomi Valkeinen wrote:
> On 2013-12-13 11:27, Archit Taneja wrote:
>> On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap4-sdp.dts | 91
>>> +++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 91 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>>> b/arch/arm/boot/dts/omap4-sdp.dts
>>> index 5fc3f43c5a81..e3048f849612 100644
>>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>>> @@ -550,3 +550,94 @@
>>> mode = <3>;
>>> power = <50>;
>>> };
>>> +
>>> +&dsi1 {
>>> + vdds_dsi-supply = <&vcxio>;
>>> +
>>> + dsi1_out_ep: endpoint {
>>> + remote-endpoint = <&lcd0_in>;
>>> + lanes = <0 1 2 3 4 5>;
>>
>> In the previous revision omapdss DT patchset, the lanes node was a
>> member of the panel DT node, and not the dsi DT node. Any reason to
>> change this? Does it make more sense this way?
>
> Well, the lane configuration is programmed into the DSI HW. So DSI needs
> to know them. Thus the lanes can be considered a property of the DSI.
>
> In some cases, the external encoder or panel also needs to know about
> the lanes. In that case, both DSI and the encoder/panel would contain
> the same data.
>
> My reasoning where a property belongs to:
>
> If a property is clearly internal to a device, it belongs there. For
> example, in this case vdds_dsi-supply is clearly a property of the DSI.
>
> If a property is about the link between two devices, like "lanes" here,
> it belongs to both devices. If a device does not need that data for
> anything, it can be omitted.
>
>> I suppose it's more suitable for dsi to hold the property if 2 panels
>> are connected on the same bus. Say, one with 4 data lanes, and other
>> with 2. It would be tricky for the dsi driver to get lane params from 2
>> different places and merge them somehow.
>
> It doesn't matter, both would work fine. If the lanes property is in the
> DSI node, then the DSI driver finds out the lane config by finding out
> which endpoint is used for the panel that's being enabled.
>
> If the lanes property would be in the panel, the panel would pass the
> lane config to the DSI when it's enabled.
>
> But I think passing the lane config from panel to DSI (like we do
> currently) is not so nice.
Okay, that makes sense.
>
>>> + };
>>> +
>>> + lcd0: display@0 {
>>> + compatible = "tpo,taal", "panel-dsi-cm";
>>> +
>>> + gpios = <&gpio4 6 0>; /* 102, reset */
>>> +
>>> + lcd0_in: endpoint {
>>> + remote-endpoint = <&dsi1_out_ep>;
>>> + };
>>> + };
>>
>> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
>> respectively? I don't see this for panels on other boards.
>
> Yes. The panels are _controlled_ with DSI. We model the child-parent
> relationships in DT data based on the control. So an i2c peripheral is
> controlled via i2c master, and is thus a child of the i2c master. Same
> here. The ports/endpoints are used to define the data path, which is
> separate thing from the control path.
>
> DPI panels which don't have any way to control them (except basic things
> like gpios) are platform devices without any parent.
>
> If the DPI panel would be controlled with i2c, it'd be a child of an i2c
> master.
Ah, I thought the port/endpoint stuff had something to do with this. I
forgot about the parent-child relationship for the control path.
In that case, for the sake of accuracy, the dsi-cm panel could get the
"in" parameter via the parent node wherever it's used for control, like
setting a DCS command for sleep out. And via
omapdss_of_find_source_for_first_ep() when it's used to start data
transfer, even though both the "in's" are finally the same dsi device?
Archit
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
@ 2013-12-13 9:58 ` Archit Taneja
0 siblings, 0 replies; 183+ messages in thread
From: Archit Taneja @ 2013-12-13 9:58 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
On Friday 13 December 2013 03:09 PM, Tomi Valkeinen wrote:
> On 2013-12-13 11:27, Archit Taneja wrote:
>> On Wednesday 04 December 2013 05:58 PM, Tomi Valkeinen wrote:
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap4-sdp.dts | 91
>>> +++++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 91 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap4-sdp.dts
>>> b/arch/arm/boot/dts/omap4-sdp.dts
>>> index 5fc3f43c5a81..e3048f849612 100644
>>> --- a/arch/arm/boot/dts/omap4-sdp.dts
>>> +++ b/arch/arm/boot/dts/omap4-sdp.dts
>>> @@ -550,3 +550,94 @@
>>> mode = <3>;
>>> power = <50>;
>>> };
>>> +
>>> +&dsi1 {
>>> + vdds_dsi-supply = <&vcxio>;
>>> +
>>> + dsi1_out_ep: endpoint {
>>> + remote-endpoint = <&lcd0_in>;
>>> + lanes = <0 1 2 3 4 5>;
>>
>> In the previous revision omapdss DT patchset, the lanes node was a
>> member of the panel DT node, and not the dsi DT node. Any reason to
>> change this? Does it make more sense this way?
>
> Well, the lane configuration is programmed into the DSI HW. So DSI needs
> to know them. Thus the lanes can be considered a property of the DSI.
>
> In some cases, the external encoder or panel also needs to know about
> the lanes. In that case, both DSI and the encoder/panel would contain
> the same data.
>
> My reasoning where a property belongs to:
>
> If a property is clearly internal to a device, it belongs there. For
> example, in this case vdds_dsi-supply is clearly a property of the DSI.
>
> If a property is about the link between two devices, like "lanes" here,
> it belongs to both devices. If a device does not need that data for
> anything, it can be omitted.
>
>> I suppose it's more suitable for dsi to hold the property if 2 panels
>> are connected on the same bus. Say, one with 4 data lanes, and other
>> with 2. It would be tricky for the dsi driver to get lane params from 2
>> different places and merge them somehow.
>
> It doesn't matter, both would work fine. If the lanes property is in the
> DSI node, then the DSI driver finds out the lane config by finding out
> which endpoint is used for the panel that's being enabled.
>
> If the lanes property would be in the panel, the panel would pass the
> lane config to the DSI when it's enabled.
>
> But I think passing the lane config from panel to DSI (like we do
> currently) is not so nice.
Okay, that makes sense.
>
>>> + };
>>> +
>>> + lcd0: display@0 {
>>> + compatible = "tpo,taal", "panel-dsi-cm";
>>> +
>>> + gpios = <&gpio4 6 0>; /* 102, reset */
>>> +
>>> + lcd0_in: endpoint {
>>> + remote-endpoint = <&dsi1_out_ep>;
>>> + };
>>> + };
>>
>> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
>> respectively? I don't see this for panels on other boards.
>
> Yes. The panels are _controlled_ with DSI. We model the child-parent
> relationships in DT data based on the control. So an i2c peripheral is
> controlled via i2c master, and is thus a child of the i2c master. Same
> here. The ports/endpoints are used to define the data path, which is
> separate thing from the control path.
>
> DPI panels which don't have any way to control them (except basic things
> like gpios) are platform devices without any parent.
>
> If the DPI panel would be controlled with i2c, it'd be a child of an i2c
> master.
Ah, I thought the port/endpoint stuff had something to do with this. I
forgot about the parent-child relationship for the control path.
In that case, for the sake of accuracy, the dsi-cm panel could get the
"in" parameter via the parent node wherever it's used for control, like
setting a DCS command for sleep out. And via
omapdss_of_find_source_for_first_ep() when it's used to start data
transfer, even though both the "in's" are finally the same dsi device?
Archit
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
2013-12-13 9:58 ` Archit Taneja
@ 2013-12-13 10:15 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 10:15 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]
On 2013-12-13 11:58, Archit Taneja wrote:
>>>> + };
>>>> +
>>>> + lcd0: display@0 {
>>>> + compatible = "tpo,taal", "panel-dsi-cm";
>>>> +
>>>> + gpios = <&gpio4 6 0>; /* 102, reset */
>>>> +
>>>> + lcd0_in: endpoint {
>>>> + remote-endpoint = <&dsi1_out_ep>;
>>>> + };
>>>> + };
>>>
>>> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
>>> respectively? I don't see this for panels on other boards.
>>
>> Yes. The panels are _controlled_ with DSI. We model the child-parent
>> relationships in DT data based on the control. So an i2c peripheral is
>> controlled via i2c master, and is thus a child of the i2c master. Same
>> here. The ports/endpoints are used to define the data path, which is
>> separate thing from the control path.
>>
>> DPI panels which don't have any way to control them (except basic things
>> like gpios) are platform devices without any parent.
>>
>> If the DPI panel would be controlled with i2c, it'd be a child of an i2c
>> master.
>
> Ah, I thought the port/endpoint stuff had something to do with this. I
> forgot about the parent-child relationship for the control path.
>
> In that case, for the sake of accuracy, the dsi-cm panel could get the
> "in" parameter via the parent node wherever it's used for control, like
> setting a DCS command for sleep out. And via
> omapdss_of_find_source_for_first_ep() when it's used to start data
> transfer, even though both the "in's" are finally the same dsi device?
Don't mix the DT data and the current driver =). The current driver does
not handle things properly. The driver still uses the current model,
where we don't have separate control and data path handling. I.e. both
control and data are handled via the single API, using the "in" field.
The important thing with this DT data is that in the future we can
change the driver model, if we so want, to manage data and control
separately. Or maybe add a DSI bus, as has been proposed elsewhere.
It's true that we could change the driver as you describe, but I don't
think it helps anything, as the current model in the driver only has a
single control-data path.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 16/26] ARM: omap4-sdp.dts: add display information
@ 2013-12-13 10:15 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 10:15 UTC (permalink / raw)
To: Archit Taneja, linux-omap, linux-fbdev, devicetree
Cc: Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]
On 2013-12-13 11:58, Archit Taneja wrote:
>>>> + };
>>>> +
>>>> + lcd0: display@0 {
>>>> + compatible = "tpo,taal", "panel-dsi-cm";
>>>> +
>>>> + gpios = <&gpio4 6 0>; /* 102, reset */
>>>> +
>>>> + lcd0_in: endpoint {
>>>> + remote-endpoint = <&dsi1_out_ep>;
>>>> + };
>>>> + };
>>>
>>> Is there a reason why lcd0 and lcd1 are children nodes of dsi1 and dsi2
>>> respectively? I don't see this for panels on other boards.
>>
>> Yes. The panels are _controlled_ with DSI. We model the child-parent
>> relationships in DT data based on the control. So an i2c peripheral is
>> controlled via i2c master, and is thus a child of the i2c master. Same
>> here. The ports/endpoints are used to define the data path, which is
>> separate thing from the control path.
>>
>> DPI panels which don't have any way to control them (except basic things
>> like gpios) are platform devices without any parent.
>>
>> If the DPI panel would be controlled with i2c, it'd be a child of an i2c
>> master.
>
> Ah, I thought the port/endpoint stuff had something to do with this. I
> forgot about the parent-child relationship for the control path.
>
> In that case, for the sake of accuracy, the dsi-cm panel could get the
> "in" parameter via the parent node wherever it's used for control, like
> setting a DCS command for sleep out. And via
> omapdss_of_find_source_for_first_ep() when it's used to start data
> transfer, even though both the "in's" are finally the same dsi device?
Don't mix the DT data and the current driver =). The current driver does
not handle things properly. The driver still uses the current model,
where we don't have separate control and data path handling. I.e. both
control and data are handled via the single API, using the "in" field.
The important thing with this DT data is that in the future we can
change the driver model, if we so want, to manage data and control
separately. Or maybe add a DSI bus, as has been proposed elsewhere.
It's true that we could change the driver as you describe, but I don't
think it helps anything, as the current model in the driver only has a
single control-data path.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.
Not to be merged.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3-tobi.dts | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index 7e4ad2aec37a..49c6f3f17804 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -81,3 +81,43 @@
&mmc3 {
status = "disabled";
};
+
+&dpi {
+ vdds_dsi-supply = <&vpll2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <24>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ lcd0: display@0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+
+ panel-timing {
+ clock-frequency = <9200000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <8>;
+ hback-porch = <4>;
+ hsync-len = <41>;
+ vback-porch = <2>;
+ vfront-porch = <4>;
+ vsync-len = <10>;
+
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
it as a test.
Not to be merged.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3-tobi.dts | 40 ++++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-tobi.dts b/arch/arm/boot/dts/omap3-tobi.dts
index 7e4ad2aec37a..49c6f3f17804 100644
--- a/arch/arm/boot/dts/omap3-tobi.dts
+++ b/arch/arm/boot/dts/omap3-tobi.dts
@@ -81,3 +81,43 @@
&mmc3 {
status = "disabled";
};
+
+&dpi {
+ vdds_dsi-supply = <&vpll2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&lcd_in>;
+ data-lines = <24>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &lcd0;
+ };
+
+ lcd0: display@0 {
+ compatible = "samsung,lte430wq-f0c", "panel-dpi";
+
+ lcd_in: endpoint {
+ remote-endpoint = <&dpi_out>;
+ };
+
+ panel-timing {
+ clock-frequency = <9200000>;
+ hactive = <480>;
+ vactive = <272>;
+ hfront-porch = <8>;
+ hback-porch = <4>;
+ hsync-len = <41>;
+ vback-porch = <2>;
+ vfront-porch = <4>;
+ vsync-len = <10>;
+
+ hsync-active = <0>;
+ vsync-active = <0>;
+ de-active = <1>;
+ pixelclk-active = <1>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-06 10:18 ` Florian Vaussard
-1 siblings, 0 replies; 183+ messages in thread
From: Florian Vaussard @ 2013-12-06 10:18 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren
Hello Tomi,
On 12/04/2013 01:28 PM, Tomi Valkeinen wrote:
> This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
> doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
> it as a test.
>
Looking at the schematics, both seem pretty similar indeed. The main
difference seems to be the LCD on the palo43, and the HDMI on the Tobi
(TFP410, as in your patch 21).
I only have a Tobi on my desk, so this is the reason for not supporting
other boards... We could make a .dtsi with common stuff, then add the
LCD to the Palo43 and HDMI to the Tobi. I was going to add some more
support to these boards in the coming days, so I can add this too, at
least for testing purpose.
Cheers,
Florian
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
@ 2013-12-06 10:18 ` Florian Vaussard
0 siblings, 0 replies; 183+ messages in thread
From: Florian Vaussard @ 2013-12-06 10:18 UTC (permalink / raw)
To: Tomi Valkeinen, linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren
Hello Tomi,
On 12/04/2013 01:28 PM, Tomi Valkeinen wrote:
> This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
> doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
> it as a test.
>
Looking at the schematics, both seem pretty similar indeed. The main
difference seems to be the LCD on the palo43, and the HDMI on the Tobi
(TFP410, as in your patch 21).
I only have a Tobi on my desk, so this is the reason for not supporting
other boards... We could make a .dtsi with common stuff, then add the
LCD to the Palo43 and HDMI to the Tobi. I was going to add some more
support to these boards in the coming days, so I can add this too, at
least for testing purpose.
Cheers,
Florian
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
2013-12-06 10:18 ` Florian Vaussard
@ 2013-12-10 12:18 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-10 12:18 UTC (permalink / raw)
To: florian.vaussard, linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On 2013-12-06 12:18, Florian Vaussard wrote:
> Hello Tomi,
>
> On 12/04/2013 01:28 PM, Tomi Valkeinen wrote:
>> This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
>> doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
>> it as a test.
>>
>
> Looking at the schematics, both seem pretty similar indeed. The main
> difference seems to be the LCD on the palo43, and the HDMI on the Tobi
> (TFP410, as in your patch 21).
>
> I only have a Tobi on my desk, so this is the reason for not supporting
> other boards... We could make a .dtsi with common stuff, then add the
> LCD to the Palo43 and HDMI to the Tobi. I was going to add some more
> support to these boards in the coming days, so I can add this too, at
> least for testing purpose.
I think I'll just drop this patch, as I haven't been able to boot my
overo with nfs root for some time. I don't know if it's my pc or the
board or the kernel, but for some reason the usb gadget ethernet refuses
to work.
If you want to update the tobi.dts for the proper DT data, I'm happy to
include the patch to my series.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 17/26] ARM: omap3-tobi.dts: add lcd (TEST)
@ 2013-12-10 12:18 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-10 12:18 UTC (permalink / raw)
To: florian.vaussard, linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 1141 bytes --]
On 2013-12-06 12:18, Florian Vaussard wrote:
> Hello Tomi,
>
> On 12/04/2013 01:28 PM, Tomi Valkeinen wrote:
>> This is a test for Overo with Palo43 expansion, _not_ Tobi. Palo43
>> doesn't have a dts, but seems to work ok with omap3-tobi.dts, so I used
>> it as a test.
>>
>
> Looking at the schematics, both seem pretty similar indeed. The main
> difference seems to be the LCD on the palo43, and the HDMI on the Tobi
> (TFP410, as in your patch 21).
>
> I only have a Tobi on my desk, so this is the reason for not supporting
> other boards... We could make a .dtsi with common stuff, then add the
> LCD to the Palo43 and HDMI to the Tobi. I was going to add some more
> support to these boards in the coming days, so I can add this too, at
> least for testing purpose.
I think I'll just drop this patch, as I haven't been able to boot my
overo with nfs root for some time. I don't know if it's my pc or the
board or the kernel, but for some reason the usb gadget ethernet refuses
to work.
If you want to update the tobi.dts for the proper DT data, I'm happy to
include the patch to my series.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 18/26] ARM: omap3-beagle.dts: add display information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index fa532aaacc68..1ca1932d02aa 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -178,3 +178,70 @@
mode = <3>;
power = <50>;
};
+
+&dpi {
+ vdds_dsi-supply = <&vpll2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&venc {
+ vdda_dac-supply = <&vdac>;
+
+ venc_out: endpoint {
+ remote-endpoint = <&tv_connector_in>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio5 10 0>; /* 170, power-down */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "ti,dvi_connector";
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tv0: connector@1 {
+ compatible = "ti,svideo_connector";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 18/26] ARM: omap3-beagle.dts: add display information
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
index fa532aaacc68..1ca1932d02aa 100644
--- a/arch/arm/boot/dts/omap3-beagle.dts
+++ b/arch/arm/boot/dts/omap3-beagle.dts
@@ -178,3 +178,70 @@
mode = <3>;
power = <50>;
};
+
+&dpi {
+ vdds_dsi-supply = <&vpll2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&venc {
+ vdda_dac-supply = <&vdac>;
+
+ venc_out: endpoint {
+ remote-endpoint = <&tv_connector_in>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&gpio5 10 0>; /* 170, power-down */
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "ti,dvi_connector";
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tv0: connector@1 {
+ compatible = "ti,svideo_connector";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-06 8:41 ` Javier Martinez Canillas
-1 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-06 8:41 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index fa532aaacc68..1ca1932d02aa 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -178,3 +178,70 @@
> mode = <3>;
> power = <50>;
> };
> +
> +&dpi {
> + vdds_dsi-supply = <&vpll2>;
> +
> + dpi_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + data-lines = <24>;
> + };
> +};
> +
> +&venc {
> + vdda_dac-supply = <&vdac>;
> +
> + venc_out: endpoint {
> + remote-endpoint = <&tv_connector_in>;
> + };
> +};
> +
> +/ {
> + aliases {
> + display0 = &dvi0;
> + display1 = &tv0;
> + };
> +
> + tfp410: encoder@0 {
> + compatible = "ti,tfp410";
> + gpios = <&gpio5 10 0>; /* 170, power-down */
> +
Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
from 1 so gpio5 + 10 is GPIO 138.
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint@0 {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint@1 {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + dvi0: connector@0 {
> + compatible = "ti,dvi_connector";
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> +
> + tv0: connector@1 {
> + compatible = "ti,svideo_connector";
> +
> + tv_connector_in: endpoint {
> + remote-endpoint = <&venc_out>;
> + };
> + };
> +};
> --
> 1.8.3.2
>
Also I don't see the DSS pinmux set for this board. I guess you need
something like the following on top:
0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
Best regards,
Javier
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
@ 2013-12-06 8:41 ` Javier Martinez Canillas
0 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-06 8:41 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
> ---
> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
> 1 file changed, 67 insertions(+)
>
> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
> index fa532aaacc68..1ca1932d02aa 100644
> --- a/arch/arm/boot/dts/omap3-beagle.dts
> +++ b/arch/arm/boot/dts/omap3-beagle.dts
> @@ -178,3 +178,70 @@
> mode = <3>;
> power = <50>;
> };
> +
> +&dpi {
> + vdds_dsi-supply = <&vpll2>;
> +
> + dpi_out: endpoint {
> + remote-endpoint = <&tfp410_in>;
> + data-lines = <24>;
> + };
> +};
> +
> +&venc {
> + vdda_dac-supply = <&vdac>;
> +
> + venc_out: endpoint {
> + remote-endpoint = <&tv_connector_in>;
> + };
> +};
> +
> +/ {
> + aliases {
> + display0 = &dvi0;
> + display1 = &tv0;
> + };
> +
> + tfp410: encoder@0 {
> + compatible = "ti,tfp410";
> + gpios = <&gpio5 10 0>; /* 170, power-down */
> +
Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
from 1 so gpio5 + 10 is GPIO 138.
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> +
> + tfp410_in: endpoint@0 {
> + remote-endpoint = <&dpi_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> +
> + tfp410_out: endpoint@1 {
> + remote-endpoint = <&dvi_connector_in>;
> + };
> + };
> + };
> + };
> +
> + dvi0: connector@0 {
> + compatible = "ti,dvi_connector";
> + i2c-bus = <&i2c3>;
> +
> + dvi_connector_in: endpoint {
> + remote-endpoint = <&tfp410_out>;
> + };
> + };
> +
> + tv0: connector@1 {
> + compatible = "ti,svideo_connector";
> +
> + tv_connector_in: endpoint {
> + remote-endpoint = <&venc_out>;
> + };
> + };
> +};
> --
> 1.8.3.2
>
Also I don't see the DSS pinmux set for this board. I guess you need
something like the following on top:
0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
Best regards,
Javier
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
2013-12-06 8:41 ` Javier Martinez Canillas
@ 2013-12-09 12:06 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-09 12:06 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 4875 bytes --]
On 2013-12-06 10:41, Javier Martinez Canillas wrote:
> Hi Tomi,
>
> On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
>> index fa532aaacc68..1ca1932d02aa 100644
>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>> @@ -178,3 +178,70 @@
>> mode = <3>;
>> power = <50>;
>> };
>> +
>> +&dpi {
>> + vdds_dsi-supply = <&vpll2>;
>> +
>> + dpi_out: endpoint {
>> + remote-endpoint = <&tfp410_in>;
>> + data-lines = <24>;
>> + };
>> +};
>> +
>> +&venc {
>> + vdda_dac-supply = <&vdac>;
>> +
>> + venc_out: endpoint {
>> + remote-endpoint = <&tv_connector_in>;
>> + };
>> +};
>> +
>> +/ {
>> + aliases {
>> + display0 = &dvi0;
>> + display1 = &tv0;
>> + };
>> +
>> + tfp410: encoder@0 {
>> + compatible = "ti,tfp410";
>> + gpios = <&gpio5 10 0>; /* 170, power-down */
>> +
>
> Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
> from 1 so gpio5 + 10 is GPIO 138.
Yes, you're right. Good catch.
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + tfp410_in: endpoint@0 {
>> + remote-endpoint = <&dpi_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + tfp410_out: endpoint@1 {
>> + remote-endpoint = <&dvi_connector_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + dvi0: connector@0 {
>> + compatible = "ti,dvi_connector";
>> + i2c-bus = <&i2c3>;
>> +
>> + dvi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> + };
>> +
>> + tv0: connector@1 {
>> + compatible = "ti,svideo_connector";
>> +
>> + tv_connector_in: endpoint {
>> + remote-endpoint = <&venc_out>;
>> + };
>> + };
>> +};
>> --
>> 1.8.3.2
>>
>
> Also I don't see the DSS pinmux set for this board. I guess you need
> something like the following on top:
>
> 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
> 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
> 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
> 0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
> 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
> 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
> 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
> 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
> 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
> 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
> 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
> 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
> 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
> 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
> 0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
> 0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
> 0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
> 0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
> 0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
> 0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
> 0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
> 0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
> 0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
> 0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
> 0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
> 0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
> 0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
> 0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
True. I need to add something like this to all the dts files.
You didn't have muxing in the omap3-igep0020 patch you gave. Is the
muxing already set in some other patch?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
@ 2013-12-09 12:06 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-09 12:06 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
[-- Attachment #1: Type: text/plain, Size: 4875 bytes --]
On 2013-12-06 10:41, Javier Martinez Canillas wrote:
> Hi Tomi,
>
> On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>> ---
>> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
>> 1 file changed, 67 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
>> index fa532aaacc68..1ca1932d02aa 100644
>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>> @@ -178,3 +178,70 @@
>> mode = <3>;
>> power = <50>;
>> };
>> +
>> +&dpi {
>> + vdds_dsi-supply = <&vpll2>;
>> +
>> + dpi_out: endpoint {
>> + remote-endpoint = <&tfp410_in>;
>> + data-lines = <24>;
>> + };
>> +};
>> +
>> +&venc {
>> + vdda_dac-supply = <&vdac>;
>> +
>> + venc_out: endpoint {
>> + remote-endpoint = <&tv_connector_in>;
>> + };
>> +};
>> +
>> +/ {
>> + aliases {
>> + display0 = &dvi0;
>> + display1 = &tv0;
>> + };
>> +
>> + tfp410: encoder@0 {
>> + compatible = "ti,tfp410";
>> + gpios = <&gpio5 10 0>; /* 170, power-down */
>> +
>
> Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
> from 1 so gpio5 + 10 is GPIO 138.
Yes, you're right. Good catch.
>> + ports {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> +
>> + port@0 {
>> + reg = <0>;
>> +
>> + tfp410_in: endpoint@0 {
>> + remote-endpoint = <&dpi_out>;
>> + };
>> + };
>> +
>> + port@1 {
>> + reg = <1>;
>> +
>> + tfp410_out: endpoint@1 {
>> + remote-endpoint = <&dvi_connector_in>;
>> + };
>> + };
>> + };
>> + };
>> +
>> + dvi0: connector@0 {
>> + compatible = "ti,dvi_connector";
>> + i2c-bus = <&i2c3>;
>> +
>> + dvi_connector_in: endpoint {
>> + remote-endpoint = <&tfp410_out>;
>> + };
>> + };
>> +
>> + tv0: connector@1 {
>> + compatible = "ti,svideo_connector";
>> +
>> + tv_connector_in: endpoint {
>> + remote-endpoint = <&venc_out>;
>> + };
>> + };
>> +};
>> --
>> 1.8.3.2
>>
>
> Also I don't see the DSS pinmux set for this board. I guess you need
> something like the following on top:
>
> 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
> 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
> 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
> 0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
> 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
> 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
> 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
> 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
> 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
> 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
> 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
> 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
> 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
> 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
> 0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
> 0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
> 0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
> 0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
> 0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
> 0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
> 0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
> 0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
> 0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
> 0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
> 0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
> 0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
> 0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
> 0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
True. I need to add something like this to all the dts files.
You didn't have muxing in the omap3-igep0020 patch you gave. Is the
muxing already set in some other patch?
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
2013-12-09 12:06 ` Tomi Valkeinen
@ 2013-12-09 12:16 ` Javier Martinez Canillas
-1 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-09 12:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Mon, Dec 9, 2013 at 1:06 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-06 10:41, Javier Martinez Canillas wrote:
>> Hi Tomi,
>>
>> On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 67 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
>>> index fa532aaacc68..1ca1932d02aa 100644
>>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>>> @@ -178,3 +178,70 @@
>>> mode = <3>;
>>> power = <50>;
>>> };
>>> +
>>> +&dpi {
>>> + vdds_dsi-supply = <&vpll2>;
>>> +
>>> + dpi_out: endpoint {
>>> + remote-endpoint = <&tfp410_in>;
>>> + data-lines = <24>;
>>> + };
>>> +};
>>> +
>>> +&venc {
>>> + vdda_dac-supply = <&vdac>;
>>> +
>>> + venc_out: endpoint {
>>> + remote-endpoint = <&tv_connector_in>;
>>> + };
>>> +};
>>> +
>>> +/ {
>>> + aliases {
>>> + display0 = &dvi0;
>>> + display1 = &tv0;
>>> + };
>>> +
>>> + tfp410: encoder@0 {
>>> + compatible = "ti,tfp410";
>>> + gpios = <&gpio5 10 0>; /* 170, power-down */
>>> +
>>
>> Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
>> from 1 so gpio5 + 10 is GPIO 138.
>
> Yes, you're right. Good catch.
>
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> +
>>> + tfp410_in: endpoint@0 {
>>> + remote-endpoint = <&dpi_out>;
>>> + };
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> +
>>> + tfp410_out: endpoint@1 {
>>> + remote-endpoint = <&dvi_connector_in>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + dvi0: connector@0 {
>>> + compatible = "ti,dvi_connector";
>>> + i2c-bus = <&i2c3>;
>>> +
>>> + dvi_connector_in: endpoint {
>>> + remote-endpoint = <&tfp410_out>;
>>> + };
>>> + };
>>> +
>>> + tv0: connector@1 {
>>> + compatible = "ti,svideo_connector";
>>> +
>>> + tv_connector_in: endpoint {
>>> + remote-endpoint = <&venc_out>;
>>> + };
>>> + };
>>> +};
>>> --
>>> 1.8.3.2
>>>
>>
>> Also I don't see the DSS pinmux set for this board. I guess you need
>> something like the following on top:
>>
>> 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
>> 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
>> 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
>> 0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
>> 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
>> 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
>> 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
>> 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
>> 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
>> 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
>> 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
>> 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
>> 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
>> 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
>> 0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
>> 0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
>> 0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
>> 0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
>> 0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
>> 0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
>> 0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
>> 0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
>> 0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
>> 0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
>> 0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
>> 0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
>> 0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
>> 0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
>
> True. I need to add something like this to all the dts files.
>
> You didn't have muxing in the omap3-igep0020 patch you gave. Is the
> muxing already set in some other patch?
>
Your patch-set is based on v3.13-rc1 but I sent a patch-set [0] to fix
a few regressions for IGEPv2 when we moved to DT-only boot. One of
these patches added the needed DSS pinmuxing and these were included
in v3.13-rc2.
So to test your branch I cherry-picked:
d526daeb ("ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices")
50592dc3 ("ARM: dts: omap3-igep0020: Add pinmuxing for DVI output")
Also, for 3.13 I added a DT hack to make dpi_init_regulator() succeed
and find the VDDS_DSI regulator. That patch is mainline comit
2f2befd82 ("ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as vdds_dsi")
Now that I think about it, you may want to add a revert for that patch
on your series too since this hack is not needed anymore with your DSS
bindings.
> Tomi
>
Thanks a lot and best regards,
Javier
>
[0]: http://www.spinics.net/lists/linux-omap/msg99970.html
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 18/26] ARM: omap3-beagle.dts: add display information
@ 2013-12-09 12:16 ` Javier Martinez Canillas
0 siblings, 0 replies; 183+ messages in thread
From: Javier Martinez Canillas @ 2013-12-09 12:16 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren
Hi Tomi,
On Mon, Dec 9, 2013 at 1:06 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
> On 2013-12-06 10:41, Javier Martinez Canillas wrote:
>> Hi Tomi,
>>
>> On Wed, Dec 4, 2013 at 1:28 PM, Tomi Valkeinen <tomi.valkeinen@ti.com> wrote:
>>> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
>>> ---
>>> arch/arm/boot/dts/omap3-beagle.dts | 67 ++++++++++++++++++++++++++++++++++++++
>>> 1 file changed, 67 insertions(+)
>>>
>>> diff --git a/arch/arm/boot/dts/omap3-beagle.dts b/arch/arm/boot/dts/omap3-beagle.dts
>>> index fa532aaacc68..1ca1932d02aa 100644
>>> --- a/arch/arm/boot/dts/omap3-beagle.dts
>>> +++ b/arch/arm/boot/dts/omap3-beagle.dts
>>> @@ -178,3 +178,70 @@
>>> mode = <3>;
>>> power = <50>;
>>> };
>>> +
>>> +&dpi {
>>> + vdds_dsi-supply = <&vpll2>;
>>> +
>>> + dpi_out: endpoint {
>>> + remote-endpoint = <&tfp410_in>;
>>> + data-lines = <24>;
>>> + };
>>> +};
>>> +
>>> +&venc {
>>> + vdda_dac-supply = <&vdac>;
>>> +
>>> + venc_out: endpoint {
>>> + remote-endpoint = <&tv_connector_in>;
>>> + };
>>> +};
>>> +
>>> +/ {
>>> + aliases {
>>> + display0 = &dvi0;
>>> + display1 = &tv0;
>>> + };
>>> +
>>> + tfp410: encoder@0 {
>>> + compatible = "ti,tfp410";
>>> + gpios = <&gpio5 10 0>; /* 170, power-down */
>>> +
>>
>> Shouldn't this be gpio6 instead since OMAP GPIO banks start counting
>> from 1 so gpio5 + 10 is GPIO 138.
>
> Yes, you're right. Good catch.
>
>>> + ports {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> +
>>> + port@0 {
>>> + reg = <0>;
>>> +
>>> + tfp410_in: endpoint@0 {
>>> + remote-endpoint = <&dpi_out>;
>>> + };
>>> + };
>>> +
>>> + port@1 {
>>> + reg = <1>;
>>> +
>>> + tfp410_out: endpoint@1 {
>>> + remote-endpoint = <&dvi_connector_in>;
>>> + };
>>> + };
>>> + };
>>> + };
>>> +
>>> + dvi0: connector@0 {
>>> + compatible = "ti,dvi_connector";
>>> + i2c-bus = <&i2c3>;
>>> +
>>> + dvi_connector_in: endpoint {
>>> + remote-endpoint = <&tfp410_out>;
>>> + };
>>> + };
>>> +
>>> + tv0: connector@1 {
>>> + compatible = "ti,svideo_connector";
>>> +
>>> + tv_connector_in: endpoint {
>>> + remote-endpoint = <&venc_out>;
>>> + };
>>> + };
>>> +};
>>> --
>>> 1.8.3.2
>>>
>>
>> Also I don't see the DSS pinmux set for this board. I guess you need
>> something like the following on top:
>>
>> 0x0a4 (PIN_OUTPUT | MUX_MODE0) /* dss_pclk.dss_pclk */
>> 0x0a6 (PIN_OUTPUT | MUX_MODE0) /* dss_hsync.dss_hsync */
>> 0x0a8 (PIN_OUTPUT | MUX_MODE0) /* dss_vsync.dss_vsync */
>> 0x0aa (PIN_OUTPUT | MUX_MODE0) /* dss_acbias.dss_acbias */
>> 0x0ac (PIN_OUTPUT | MUX_MODE0) /* dss_data0.dss_data0 */
>> 0x0ae (PIN_OUTPUT | MUX_MODE0) /* dss_data1.dss_data1 */
>> 0x0b0 (PIN_OUTPUT | MUX_MODE0) /* dss_data2.dss_data2 */
>> 0x0b2 (PIN_OUTPUT | MUX_MODE0) /* dss_data3.dss_data3 */
>> 0x0b4 (PIN_OUTPUT | MUX_MODE0) /* dss_data4.dss_data4 */
>> 0x0b6 (PIN_OUTPUT | MUX_MODE0) /* dss_data5.dss_data5 */
>> 0x0b8 (PIN_OUTPUT | MUX_MODE0) /* dss_data6.dss_data6 */
>> 0x0ba (PIN_OUTPUT | MUX_MODE0) /* dss_data7.dss_data7 */
>> 0x0bc (PIN_OUTPUT | MUX_MODE0) /* dss_data8.dss_data8 */
>> 0x0be (PIN_OUTPUT | MUX_MODE0) /* dss_data9.dss_data9 */
>> 0x0c0 (PIN_OUTPUT | MUX_MODE0) /* dss_data10.dss_data10 */
>> 0x0c2 (PIN_OUTPUT | MUX_MODE0) /* dss_data11.dss_data11 */
>> 0x0c4 (PIN_OUTPUT | MUX_MODE0) /* dss_data12.dss_data12 */
>> 0x0c6 (PIN_OUTPUT | MUX_MODE0) /* dss_data13.dss_data13 */
>> 0x0c8 (PIN_OUTPUT | MUX_MODE0) /* dss_data14.dss_data14 */
>> 0x0ca (PIN_OUTPUT | MUX_MODE0) /* dss_data15.dss_data15 */
>> 0x0cc (PIN_OUTPUT | MUX_MODE0) /* dss_data16.dss_data16 */
>> 0x0ce (PIN_OUTPUT | MUX_MODE0) /* dss_data17.dss_data17 */
>> 0x0d0 (PIN_OUTPUT | MUX_MODE0) /* dss_data18.dss_data18 */
>> 0x0d2 (PIN_OUTPUT | MUX_MODE0) /* dss_data19.dss_data19 */
>> 0x0d4 (PIN_OUTPUT | MUX_MODE0) /* dss_data20.dss_data20 */
>> 0x0d6 (PIN_OUTPUT | MUX_MODE0) /* dss_data21.dss_data21 */
>> 0x0d8 (PIN_OUTPUT | MUX_MODE0) /* dss_data22.dss_data22 */
>> 0x0da (PIN_OUTPUT | MUX_MODE0) /* dss_data23.dss_data23 */
>
> True. I need to add something like this to all the dts files.
>
> You didn't have muxing in the omap3-igep0020 patch you gave. Is the
> muxing already set in some other patch?
>
Your patch-set is based on v3.13-rc1 but I sent a patch-set [0] to fix
a few regressions for IGEPv2 when we moved to DT-only boot. One of
these patches added the needed DSS pinmuxing and these were included
in v3.13-rc2.
So to test your branch I cherry-picked:
d526daeb ("ARM: dts: omap3-igep0020: Add pinmux setup for i2c devices")
50592dc3 ("ARM: dts: omap3-igep0020: Add pinmuxing for DVI output")
Also, for 3.13 I added a DT hack to make dpi_init_regulator() succeed
and find the VDDS_DSI regulator. That patch is mainline comit
2f2befd82 ("ARM: dts: omap3-igep0020: name twl4030 VPLL2 regulator as vdds_dsi")
Now that I think about it, you may want to add a revert for that patch
on your series too since this hack is not needed anymore with your DSS
bindings.
> Tomi
>
Thanks a lot and best regards,
Javier
>
[0]: http://www.spinics.net/lists/linux-omap/msg99970.html
^ permalink raw reply [flat|nested] 183+ messages in thread
* [PATCH 19/26] ARM: omap3-beagle-xm.dts: add display information
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 67 +++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 31a632f7effb..baec842f4fb5 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -215,3 +215,70 @@
&usbhsehci {
phys = <0 &hsusb2_phy>;
};
+
+&dpi {
+ vdds_dsi-supply = <&vpll2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&venc {
+ vdda_dac-supply = <&vdac>;
+
+ venc_out: endpoint {
+ remote-endpoint = <&tv_connector_in>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&twl_gpio 2 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "ti,dvi-connector";
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tv0: connector@1 {
+ compatible = "ti,svideo-connector";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 19/26] ARM: omap3-beagle-xm.dts: add display information
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 67 +++++++++++++++++++++++++++++++++++
1 file changed, 67 insertions(+)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts b/arch/arm/boot/dts/omap3-beagle-xm.dts
index 31a632f7effb..baec842f4fb5 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -215,3 +215,70 @@
&usbhsehci {
phys = <0 &hsusb2_phy>;
};
+
+&dpi {
+ vdds_dsi-supply = <&vpll2>;
+
+ dpi_out: endpoint {
+ remote-endpoint = <&tfp410_in>;
+ data-lines = <24>;
+ };
+};
+
+&venc {
+ vdda_dac-supply = <&vdac>;
+
+ venc_out: endpoint {
+ remote-endpoint = <&tv_connector_in>;
+ };
+};
+
+/ {
+ aliases {
+ display0 = &dvi0;
+ display1 = &tv0;
+ };
+
+ tfp410: encoder@0 {
+ compatible = "ti,tfp410";
+ gpios = <&twl_gpio 2 GPIO_ACTIVE_HIGH>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ tfp410_in: endpoint@0 {
+ remote-endpoint = <&dpi_out>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+
+ tfp410_out: endpoint@1 {
+ remote-endpoint = <&dvi_connector_in>;
+ };
+ };
+ };
+ };
+
+ dvi0: connector@0 {
+ compatible = "ti,dvi-connector";
+ i2c-bus = <&i2c3>;
+
+ dvi_connector_in: endpoint {
+ remote-endpoint = <&tfp410_out>;
+ };
+ };
+
+ tv0: connector@1 {
+ compatible = "ti,svideo-connector";
+
+ tv_connector_in: endpoint {
+ remote-endpoint = <&venc_out>;
+ };
+ };
+};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 20/26] OMAPDSS: panel-dsi-cm: Add DT support
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
XXX ULPS and backlight missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/panel-dsi-cm.c | 65 +++++++++++++++++++++++--
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/displays-new/panel-dsi-cm.c b/drivers/video/omap2/displays-new/panel-dsi-cm.c
index b7baafe83aa3..fda7728bdfaa 100644
--- a/drivers/video/omap2/displays-new/panel-dsi-cm.c
+++ b/drivers/video/omap2/displays-new/panel-dsi-cm.c
@@ -22,6 +22,8 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/workqueue.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -595,10 +597,13 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
.lp_clk_max = 10000000,
};
- r = in->ops.dsi->configure_pins(in, &ddata->pin_config);
- if (r) {
- dev_err(&ddata->pdev->dev, "failed to configure DSI pins\n");
- goto err0;
+ if (ddata->pin_config.num_pins > 0) {
+ r = in->ops.dsi->configure_pins(in, &ddata->pin_config);
+ if (r) {
+ dev_err(&ddata->pdev->dev,
+ "failed to configure DSI pins\n");
+ goto err0;
+ }
}
r = in->ops.dsi->set_config(in, &dsi_config);
@@ -1156,6 +1161,46 @@ static int dsicm_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int dsicm_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_gpio(node, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(&pdev->dev, "failed to parse reset gpio\n");
+ return gpio;
+ }
+ ddata->reset_gpio = gpio;
+
+ if (of_gpio_count(node) > 1) {
+ gpio = of_get_gpio(node, 1);
+
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata->ext_te_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse TE gpio\n");
+ return gpio;
+ }
+ } else {
+ ddata->ext_te_gpio = -1;
+ }
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ /* TODO: ulps, backlight */
+
+ return 0;
+}
+
static int dsicm_probe(struct platform_device *pdev)
{
struct backlight_properties props;
@@ -1178,6 +1223,10 @@ static int dsicm_probe(struct platform_device *pdev)
r = dsicm_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = dsicm_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -1320,12 +1369,20 @@ static int __exit dsicm_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id dsicm_of_match[] = {
+ { .compatible = "panel-dsi-cm", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dsicm_of_match);
+
static struct platform_driver dsicm_driver = {
.probe = dsicm_probe,
.remove = __exit_p(dsicm_remove),
.driver = {
.name = "panel-dsi-cm",
.owner = THIS_MODULE,
+ .of_match_table = dsicm_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 20/26] OMAPDSS: panel-dsi-cm: Add DT support
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
XXX ULPS and backlight missing.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/panel-dsi-cm.c | 65 +++++++++++++++++++++++--
1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/video/omap2/displays-new/panel-dsi-cm.c b/drivers/video/omap2/displays-new/panel-dsi-cm.c
index b7baafe83aa3..fda7728bdfaa 100644
--- a/drivers/video/omap2/displays-new/panel-dsi-cm.c
+++ b/drivers/video/omap2/displays-new/panel-dsi-cm.c
@@ -22,6 +22,8 @@
#include <linux/sched.h>
#include <linux/slab.h>
#include <linux/workqueue.h>
+#include <linux/of_device.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -595,10 +597,13 @@ static int dsicm_power_on(struct panel_drv_data *ddata)
.lp_clk_max = 10000000,
};
- r = in->ops.dsi->configure_pins(in, &ddata->pin_config);
- if (r) {
- dev_err(&ddata->pdev->dev, "failed to configure DSI pins\n");
- goto err0;
+ if (ddata->pin_config.num_pins > 0) {
+ r = in->ops.dsi->configure_pins(in, &ddata->pin_config);
+ if (r) {
+ dev_err(&ddata->pdev->dev,
+ "failed to configure DSI pins\n");
+ goto err0;
+ }
}
r = in->ops.dsi->set_config(in, &dsi_config);
@@ -1156,6 +1161,46 @@ static int dsicm_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int dsicm_probe_of(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct omap_dss_device *in;
+ int gpio;
+
+ gpio = of_get_gpio(node, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(&pdev->dev, "failed to parse reset gpio\n");
+ return gpio;
+ }
+ ddata->reset_gpio = gpio;
+
+ if (of_gpio_count(node) > 1) {
+ gpio = of_get_gpio(node, 1);
+
+ if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+ ddata->ext_te_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse TE gpio\n");
+ return gpio;
+ }
+ } else {
+ ddata->ext_te_gpio = -1;
+ }
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ /* TODO: ulps, backlight */
+
+ return 0;
+}
+
static int dsicm_probe(struct platform_device *pdev)
{
struct backlight_properties props;
@@ -1178,6 +1223,10 @@ static int dsicm_probe(struct platform_device *pdev)
r = dsicm_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = dsicm_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -1320,12 +1369,20 @@ static int __exit dsicm_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id dsicm_of_match[] = {
+ { .compatible = "panel-dsi-cm", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dsicm_of_match);
+
static struct platform_driver dsicm_driver = {
.probe = dsicm_probe,
.remove = __exit_p(dsicm_remove),
.driver = {
.name = "panel-dsi-cm",
.owner = THIS_MODULE,
+ .of_match_table = dsicm_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 21/26] OMAPDSS: encoder-tfp410: Add DT support
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/encoder-tfp410.c | 43 ++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/encoder-tfp410.c b/drivers/video/omap2/displays-new/encoder-tfp410.c
index 4a291e756be9..427f6880885e 100644
--- a/drivers/video/omap2/displays-new/encoder-tfp410.c
+++ b/drivers/video/omap2/displays-new/encoder-tfp410.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -82,7 +83,8 @@ static int tfp410_enable(struct omap_dss_device *dssdev)
return 0;
in->ops.dpi->set_timings(in, &ddata->timings);
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
r = in->ops.dpi->enable(in);
if (r)
@@ -179,6 +181,33 @@ static int tfp410_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tfp410_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ int gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata->pd_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse PD gpio\n");
+ return gpio;
+ }
+
+ return 0;
+}
+
static int tfp410_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -195,6 +224,10 @@ static int tfp410_probe(struct platform_device *pdev)
r = tfp410_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = tfp410_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -251,12 +284,20 @@ static int __exit tfp410_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id tfp410_of_match[] = {
+ { .compatible = "ti,tfp410", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tfp410_of_match);
+
static struct platform_driver tfp410_driver = {
.probe = tfp410_probe,
.remove = __exit_p(tfp410_remove),
.driver = {
.name = "tfp410",
.owner = THIS_MODULE,
+ .of_match_table = tfp410_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 21/26] OMAPDSS: encoder-tfp410: Add DT support
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/encoder-tfp410.c | 43 ++++++++++++++++++++++-
1 file changed, 42 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/encoder-tfp410.c b/drivers/video/omap2/displays-new/encoder-tfp410.c
index 4a291e756be9..427f6880885e 100644
--- a/drivers/video/omap2/displays-new/encoder-tfp410.c
+++ b/drivers/video/omap2/displays-new/encoder-tfp410.c
@@ -13,6 +13,7 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -82,7 +83,8 @@ static int tfp410_enable(struct omap_dss_device *dssdev)
return 0;
in->ops.dpi->set_timings(in, &ddata->timings);
- in->ops.dpi->set_data_lines(in, ddata->data_lines);
+ if (ddata->data_lines)
+ in->ops.dpi->set_data_lines(in, ddata->data_lines);
r = in->ops.dpi->enable(in);
if (r)
@@ -179,6 +181,33 @@ static int tfp410_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tfp410_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ int gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ gpio = of_get_gpio(node, 0);
+
+ if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+ ddata->pd_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse PD gpio\n");
+ return gpio;
+ }
+
+ return 0;
+}
+
static int tfp410_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -195,6 +224,10 @@ static int tfp410_probe(struct platform_device *pdev)
r = tfp410_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = tfp410_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -251,12 +284,20 @@ static int __exit tfp410_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id tfp410_of_match[] = {
+ { .compatible = "ti,tfp410", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tfp410_of_match);
+
static struct platform_driver tfp410_driver = {
.probe = tfp410_probe,
.remove = __exit_p(tfp410_remove),
.driver = {
.name = "tfp410",
.owner = THIS_MODULE,
+ .of_match_table = tfp410_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 22/26] OMAPDSS: connector-dvi: Add DT support
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/connector-dvi.c | 43 ++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c b/drivers/video/omap2/displays-new/connector-dvi.c
index b6c50904038e..8f7e576769cd 100644
--- a/drivers/video/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/omap2/displays-new/connector-dvi.c
@@ -277,6 +277,37 @@ static int dvic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int dvic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *adapter_node;
+ struct i2c_adapter *adapter;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ adapter_node = of_parse_phandle(node, "i2c-bus", 0);
+ if (adapter_node) {
+ adapter = of_find_i2c_adapter_by_node(adapter_node);
+ if (adapter == NULL) {
+ dev_err(&pdev->dev, "failed to parse i2c-bus\n");
+ omap_dss_put_device(ddata->in);
+ return -EINVAL;
+ }
+
+ ddata->i2c_adapter = adapter;
+ }
+
+ return 0;
+}
+
static int dvic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -293,6 +324,10 @@ static int dvic_probe(struct platform_device *pdev)
r = dvic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = dvic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -342,12 +377,20 @@ static int __exit dvic_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id dvic_of_match[] = {
+ { .compatible = "ti,dvi-connector", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dvic_of_match);
+
static struct platform_driver dvi_connector_driver = {
.probe = dvic_probe,
.remove = __exit_p(dvic_remove),
.driver = {
.name = "connector-dvi",
.owner = THIS_MODULE,
+ .of_match_table = dvic_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 22/26] OMAPDSS: connector-dvi: Add DT support
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/connector-dvi.c | 43 ++++++++++++++++++++++++
1 file changed, 43 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-dvi.c b/drivers/video/omap2/displays-new/connector-dvi.c
index b6c50904038e..8f7e576769cd 100644
--- a/drivers/video/omap2/displays-new/connector-dvi.c
+++ b/drivers/video/omap2/displays-new/connector-dvi.c
@@ -277,6 +277,37 @@ static int dvic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int dvic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ struct device_node *adapter_node;
+ struct i2c_adapter *adapter;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ adapter_node = of_parse_phandle(node, "i2c-bus", 0);
+ if (adapter_node) {
+ adapter = of_find_i2c_adapter_by_node(adapter_node);
+ if (adapter = NULL) {
+ dev_err(&pdev->dev, "failed to parse i2c-bus\n");
+ omap_dss_put_device(ddata->in);
+ return -EINVAL;
+ }
+
+ ddata->i2c_adapter = adapter;
+ }
+
+ return 0;
+}
+
static int dvic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -293,6 +324,10 @@ static int dvic_probe(struct platform_device *pdev)
r = dvic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = dvic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -342,12 +377,20 @@ static int __exit dvic_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id dvic_of_match[] = {
+ { .compatible = "ti,dvi-connector", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, dvic_of_match);
+
static struct platform_driver dvi_connector_driver = {
.probe = dvic_probe,
.remove = __exit_p(dvic_remove),
.driver = {
.name = "connector-dvi",
.owner = THIS_MODULE,
+ .of_match_table = dvic_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 23/26] OMAPDSS: encoder-tpd12s015: Add DT support
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../video/omap2/displays-new/encoder-tpd12s015.c | 56 ++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/drivers/video/omap2/displays-new/encoder-tpd12s015.c b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
index d5c936cb217f..6529a4ff50ca 100644
--- a/drivers/video/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
@@ -15,6 +15,7 @@
#include <linux/slab.h>
#include <linux/gpio.h>
#include <linux/platform_device.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -289,6 +290,49 @@ static int tpd_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tpd_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ int gpio;
+
+ /* CT CP HPD GPIO */
+ gpio = of_get_gpio(node, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(&pdev->dev, "failed to parse CT CP HPD gpio\n");
+ return gpio;
+ }
+ ddata->ct_cp_hpd_gpio = gpio;
+
+ /* LS OE GPIO */
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata->ls_oe_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse LS OE gpio\n");
+ return gpio;
+ }
+
+ /* HPD GPIO */
+ gpio = of_get_gpio(node, 2);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(&pdev->dev, "failed to parse HPD gpio\n");
+ return gpio;
+ }
+ ddata->hpd_gpio = gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int tpd_probe(struct platform_device *pdev)
{
struct omap_dss_device *in, *dssdev;
@@ -307,6 +351,10 @@ static int tpd_probe(struct platform_device *pdev)
r = tpd_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = tpd_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -379,12 +427,20 @@ static int __exit tpd_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id tpd_of_match[] = {
+ { .compatible = "ti,tpd12s015", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tpd_of_match);
+
static struct platform_driver tpd_driver = {
.probe = tpd_probe,
.remove = __exit_p(tpd_remove),
.driver = {
.name = "tpd12s015",
.owner = THIS_MODULE,
+ .of_match_table = tpd_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 23/26] OMAPDSS: encoder-tpd12s015: Add DT support
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../video/omap2/displays-new/encoder-tpd12s015.c | 56 ++++++++++++++++++++++
1 file changed, 56 insertions(+)
diff --git a/drivers/video/omap2/displays-new/encoder-tpd12s015.c b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
index d5c936cb217f..6529a4ff50ca 100644
--- a/drivers/video/omap2/displays-new/encoder-tpd12s015.c
+++ b/drivers/video/omap2/displays-new/encoder-tpd12s015.c
@@ -15,6 +15,7 @@
#include <linux/slab.h>
#include <linux/gpio.h>
#include <linux/platform_device.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -289,6 +290,49 @@ static int tpd_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tpd_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ int gpio;
+
+ /* CT CP HPD GPIO */
+ gpio = of_get_gpio(node, 0);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(&pdev->dev, "failed to parse CT CP HPD gpio\n");
+ return gpio;
+ }
+ ddata->ct_cp_hpd_gpio = gpio;
+
+ /* LS OE GPIO */
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+ ddata->ls_oe_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse LS OE gpio\n");
+ return gpio;
+ }
+
+ /* HPD GPIO */
+ gpio = of_get_gpio(node, 2);
+ if (!gpio_is_valid(gpio)) {
+ dev_err(&pdev->dev, "failed to parse HPD gpio\n");
+ return gpio;
+ }
+ ddata->hpd_gpio = gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int tpd_probe(struct platform_device *pdev)
{
struct omap_dss_device *in, *dssdev;
@@ -307,6 +351,10 @@ static int tpd_probe(struct platform_device *pdev)
r = tpd_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = tpd_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -379,12 +427,20 @@ static int __exit tpd_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id tpd_of_match[] = {
+ { .compatible = "ti,tpd12s015", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, tpd_of_match);
+
static struct platform_driver tpd_driver = {
.probe = tpd_probe,
.remove = __exit_p(tpd_remove),
.driver = {
.name = "tpd12s015",
.owner = THIS_MODULE,
+ .of_match_table = tpd_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 24/26] OMAPDSS: hdmi-connector: Add DT support
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c b/drivers/video/omap2/displays-new/connector-hdmi.c
index 9abe2c039ae9..3919acd7028f 100644
--- a/drivers/video/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/omap2/displays-new/connector-hdmi.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <drm/drm_edid.h>
@@ -301,6 +302,23 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int hdmic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int hdmic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -318,6 +336,10 @@ static int hdmic_probe(struct platform_device *pdev)
r = hdmic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = hdmic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -359,12 +381,20 @@ static int __exit hdmic_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id hdmic_of_match[] = {
+ { .compatible = "ti,hdmi-connector", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, hdmic_of_match);
+
static struct platform_driver hdmi_connector_driver = {
.probe = hdmic_probe,
.remove = __exit_p(hdmic_remove),
.driver = {
.name = "connector-hdmi",
.owner = THIS_MODULE,
+ .of_match_table = hdmic_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 24/26] OMAPDSS: hdmi-connector: Add DT support
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/connector-hdmi.c | 30 +++++++++++++++++++++++
1 file changed, 30 insertions(+)
diff --git a/drivers/video/omap2/displays-new/connector-hdmi.c b/drivers/video/omap2/displays-new/connector-hdmi.c
index 9abe2c039ae9..3919acd7028f 100644
--- a/drivers/video/omap2/displays-new/connector-hdmi.c
+++ b/drivers/video/omap2/displays-new/connector-hdmi.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <drm/drm_edid.h>
@@ -301,6 +302,23 @@ static int hdmic_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int hdmic_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ return 0;
+}
+
static int hdmic_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -318,6 +336,10 @@ static int hdmic_probe(struct platform_device *pdev)
r = hdmic_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = hdmic_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -359,12 +381,20 @@ static int __exit hdmic_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id hdmic_of_match[] = {
+ { .compatible = "ti,hdmi-connector", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, hdmic_of_match);
+
static struct platform_driver hdmi_connector_driver = {
.probe = hdmic_probe,
.remove = __exit_p(hdmic_remove),
.driver = {
.name = "connector-hdmi",
.owner = THIS_MODULE,
+ .of_match_table = hdmic_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 25/26] OMAPDSS: panel-dpi: Add DT support
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/panel-dpi.c | 64 +++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/panel-dpi.c b/drivers/video/omap2/displays-new/panel-dpi.c
index 5f8f7e7c81ef..28275a288442 100644
--- a/drivers/video/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/omap2/displays-new/panel-dpi.c
@@ -13,9 +13,12 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
+#include <video/of_display_timing.h>
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -70,7 +73,8 @@ static int panel_dpi_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);
@@ -182,6 +186,52 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int panel_dpi_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ int r;
+ struct display_timing timing;
+ struct videomode vm;
+ int gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ gpio = of_get_gpio(node, 0);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata->enable_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse enable gpio\n");
+ return gpio;
+ }
+
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio == -ENOENT) {
+ ddata->backlight_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse backlight gpio\n");
+ return gpio;
+ }
+
+ r = of_get_display_timing(node, "panel-timing", &timing);
+ if (r) {
+ dev_err(&pdev->dev, "failed to get video timing\n");
+ return r;
+ }
+
+ videomode_from_timing(&timing, &vm);
+ videomode_to_omap_video_timings(&vm, &ddata->videomode);
+
+ return 0;
+}
+
static int panel_dpi_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -198,6 +248,10 @@ static int panel_dpi_probe(struct platform_device *pdev)
r = panel_dpi_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = panel_dpi_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -254,12 +308,20 @@ static int __exit panel_dpi_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id panel_dpi_of_match[] = {
+ { .compatible = "panel-dpi", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, panel_dpi_of_match);
+
static struct platform_driver panel_dpi_driver = {
.probe = panel_dpi_probe,
.remove = __exit_p(panel_dpi_remove),
.driver = {
.name = "panel-dpi",
.owner = THIS_MODULE,
+ .of_match_table = panel_dpi_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 25/26] OMAPDSS: panel-dpi: Add DT support
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
drivers/video/omap2/displays-new/panel-dpi.c | 64 +++++++++++++++++++++++++++-
1 file changed, 63 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/panel-dpi.c b/drivers/video/omap2/displays-new/panel-dpi.c
index 5f8f7e7c81ef..28275a288442 100644
--- a/drivers/video/omap2/displays-new/panel-dpi.c
+++ b/drivers/video/omap2/displays-new/panel-dpi.c
@@ -13,9 +13,12 @@
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/slab.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
+#include <video/of_display_timing.h>
struct panel_drv_data {
struct omap_dss_device dssdev;
@@ -70,7 +73,8 @@ static int panel_dpi_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);
@@ -182,6 +186,52 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int panel_dpi_probe_of(struct platform_device *pdev)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+ int r;
+ struct display_timing timing;
+ struct videomode vm;
+ int gpio;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ gpio = of_get_gpio(node, 0);
+ if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+ ddata->enable_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse enable gpio\n");
+ return gpio;
+ }
+
+ gpio = of_get_gpio(node, 1);
+ if (gpio_is_valid(gpio) || gpio = -ENOENT) {
+ ddata->backlight_gpio = gpio;
+ } else {
+ dev_err(&pdev->dev, "failed to parse backlight gpio\n");
+ return gpio;
+ }
+
+ r = of_get_display_timing(node, "panel-timing", &timing);
+ if (r) {
+ dev_err(&pdev->dev, "failed to get video timing\n");
+ return r;
+ }
+
+ videomode_from_timing(&timing, &vm);
+ videomode_to_omap_video_timings(&vm, &ddata->videomode);
+
+ return 0;
+}
+
static int panel_dpi_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -198,6 +248,10 @@ static int panel_dpi_probe(struct platform_device *pdev)
r = panel_dpi_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ r = panel_dpi_probe_of(pdev);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -254,12 +308,20 @@ static int __exit panel_dpi_remove(struct platform_device *pdev)
return 0;
}
+static const struct of_device_id panel_dpi_of_match[] = {
+ { .compatible = "panel-dpi", },
+ {},
+};
+
+MODULE_DEVICE_TABLE(of, panel_dpi_of_match);
+
static struct platform_driver panel_dpi_driver = {
.probe = panel_dpi_probe,
.remove = __exit_p(panel_dpi_remove),
.driver = {
.name = "panel-dpi",
.owner = THIS_MODULE,
+ .of_match_table = panel_dpi_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
* [PATCH 26/26] OMAPDSS: connector-analog-tv: Add DT support
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-04 12:28 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../video/omap2/displays-new/connector-analog-tv.c | 66 +++++++++++++++++++++-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c b/drivers/video/omap2/displays-new/connector-analog-tv.c
index ccd9073f706f..30598c26e354 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -42,6 +43,12 @@ static const struct omap_video_timings tvc_pal_timings = {
.interlace = true,
};
+static const struct of_device_id tvc_of_match[];
+
+struct tvc_of_data {
+ enum omap_dss_venc_type connector_type;
+};
+
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
static int tvc_connect(struct omap_dss_device *dssdev)
@@ -92,7 +99,10 @@ static int tvc_enable(struct omap_dss_device *dssdev)
in->ops.atv->set_timings(in, &ddata->timings);
in->ops.atv->set_type(in, ddata->connector_type);
- in->ops.atv->invert_vid_out_polarity(in, ddata->invert_polarity);
+
+ if (!ddata->dev->of_node)
+ in->ops.atv->invert_vid_out_polarity(in,
+ ddata->invert_polarity);
r = in->ops.atv->enable(in);
if (r)
@@ -205,6 +215,27 @@ static int tvc_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tvc_probe_of(struct platform_device *pdev,
+ const struct tvc_of_data *data)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ ddata->connector_type = data->connector_type;
+
+ return 0;
+}
+
+
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -222,6 +253,18 @@ static int tvc_probe(struct platform_device *pdev)
r = tvc_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+
+ match = of_match_node(tvc_of_match, pdev->dev.of_node);
+ if (!match) {
+ dev_err(&pdev->dev, "unsupported device\n");
+ return -ENODEV;
+ }
+
+ r = tvc_probe_of(pdev, match->data);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -263,12 +306,33 @@ static int __exit tvc_remove(struct platform_device *pdev)
return 0;
}
+static const struct tvc_of_data tv_svideo_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static const struct tvc_of_data tv_composite_video_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+};
+
+static const struct of_device_id tvc_of_match[] = {
+ {
+ .compatible = "ti,svideo-connector",
+ .data = &tv_svideo_data,
+ },
+ {
+ .compatible = "ti,composite-video-connector",
+ .data = &tv_composite_video_data,
+ },
+ {},
+};
+
static struct platform_driver tvc_connector_driver = {
.probe = tvc_probe,
.remove = __exit_p(tvc_remove),
.driver = {
.name = "connector-analog-tv",
.owner = THIS_MODULE,
+ .of_match_table = tvc_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread* [PATCH 26/26] OMAPDSS: connector-analog-tv: Add DT support
@ 2013-12-04 12:28 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-04 12:28 UTC (permalink / raw)
To: linux-omap, linux-fbdev, devicetree
Cc: Archit Taneja, Darren Etheridge, Tony Lindgren, Tomi Valkeinen
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
.../video/omap2/displays-new/connector-analog-tv.c | 66 +++++++++++++++++++++-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/drivers/video/omap2/displays-new/connector-analog-tv.c b/drivers/video/omap2/displays-new/connector-analog-tv.c
index ccd9073f706f..30598c26e354 100644
--- a/drivers/video/omap2/displays-new/connector-analog-tv.c
+++ b/drivers/video/omap2/displays-new/connector-analog-tv.c
@@ -12,6 +12,7 @@
#include <linux/slab.h>
#include <linux/module.h>
#include <linux/platform_device.h>
+#include <linux/of.h>
#include <video/omapdss.h>
#include <video/omap-panel-data.h>
@@ -42,6 +43,12 @@ static const struct omap_video_timings tvc_pal_timings = {
.interlace = true,
};
+static const struct of_device_id tvc_of_match[];
+
+struct tvc_of_data {
+ enum omap_dss_venc_type connector_type;
+};
+
#define to_panel_data(x) container_of(x, struct panel_drv_data, dssdev)
static int tvc_connect(struct omap_dss_device *dssdev)
@@ -92,7 +99,10 @@ static int tvc_enable(struct omap_dss_device *dssdev)
in->ops.atv->set_timings(in, &ddata->timings);
in->ops.atv->set_type(in, ddata->connector_type);
- in->ops.atv->invert_vid_out_polarity(in, ddata->invert_polarity);
+
+ if (!ddata->dev->of_node)
+ in->ops.atv->invert_vid_out_polarity(in,
+ ddata->invert_polarity);
r = in->ops.atv->enable(in);
if (r)
@@ -205,6 +215,27 @@ static int tvc_probe_pdata(struct platform_device *pdev)
return 0;
}
+static int tvc_probe_of(struct platform_device *pdev,
+ const struct tvc_of_data *data)
+{
+ struct panel_drv_data *ddata = platform_get_drvdata(pdev);
+ struct device_node *node = pdev->dev.of_node;
+ struct omap_dss_device *in;
+
+ in = omapdss_of_find_source_for_first_ep(node);
+ if (IS_ERR(in)) {
+ dev_err(&pdev->dev, "failed to find video source\n");
+ return PTR_ERR(in);
+ }
+
+ ddata->in = in;
+
+ ddata->connector_type = data->connector_type;
+
+ return 0;
+}
+
+
static int tvc_probe(struct platform_device *pdev)
{
struct panel_drv_data *ddata;
@@ -222,6 +253,18 @@ static int tvc_probe(struct platform_device *pdev)
r = tvc_probe_pdata(pdev);
if (r)
return r;
+ } else if (pdev->dev.of_node) {
+ const struct of_device_id *match;
+
+ match = of_match_node(tvc_of_match, pdev->dev.of_node);
+ if (!match) {
+ dev_err(&pdev->dev, "unsupported device\n");
+ return -ENODEV;
+ }
+
+ r = tvc_probe_of(pdev, match->data);
+ if (r)
+ return r;
} else {
return -ENODEV;
}
@@ -263,12 +306,33 @@ static int __exit tvc_remove(struct platform_device *pdev)
return 0;
}
+static const struct tvc_of_data tv_svideo_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_SVIDEO,
+};
+
+static const struct tvc_of_data tv_composite_video_data = {
+ .connector_type = OMAP_DSS_VENC_TYPE_COMPOSITE,
+};
+
+static const struct of_device_id tvc_of_match[] = {
+ {
+ .compatible = "ti,svideo-connector",
+ .data = &tv_svideo_data,
+ },
+ {
+ .compatible = "ti,composite-video-connector",
+ .data = &tv_composite_video_data,
+ },
+ {},
+};
+
static struct platform_driver tvc_connector_driver = {
.probe = tvc_probe,
.remove = __exit_p(tvc_remove),
.driver = {
.name = "connector-analog-tv",
.owner = THIS_MODULE,
+ .of_match_table = tvc_of_match,
},
};
--
1.8.3.2
^ permalink raw reply related [flat|nested] 183+ messages in thread
[parent not found: <1386160133-24026-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>]
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
[not found] ` <1386160133-24026-1-git-send-email-tomi.valkeinen-l0cyMroinI0@public.gmane.org>
@ 2013-12-04 16:01 ` Sebastian Reichel
0 siblings, 0 replies; 183+ messages in thread
From: Sebastian Reichel @ 2013-12-04 16:01 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge, Tony Lindgren, Laurent Pinchart, Stefan Roese,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
Hi,
On Wed, Dec 04, 2013 at 02:28:27PM +0200, Tomi Valkeinen wrote:
> Here's a new version for DT support to OMAP Display Subsystem. See
> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the
> previous version, which contains thoughts about the related problems.
>
> The major change in this version is the use of V4L2 and CDF style port/endpoint
> style in the DT data. However, note that even if the DT data contains proper
> port & endpoint data, the drivers only use the first endpoint. This is to
> simplify the patches, as adding full support for the ports and endpoints to the
> drivers will be a big task. This approach still works with more or less all the
> boards, as the only cases where the simpler model is an issue are the boards
> with multiple display devices connected to a single output.
>
> Laurent, I'd appreciate if you could have a look at the .dts changes, to see if
> there's anything that's clearly not CDF compatible.
>
> The patches can also be found from:
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
Will this be ready for 3.14? Depending on that I would handle
omapdss support for the N900 differently. If this code gets merged
into 3.14 I will update the N900 patches [0] accordingly. Otherwise
I would suggest to take the N900 patches as is for 3.14 and I will
take care of adding the omapdss DT support to the panel (and the
N900.dts) separately.
> [...]
> - No binding documentation. I will add them for the next version, if there are
> no major changes needed. Hopefully the bindings are quite self-explanatory
> for people with understanding of the hardware in question.
It is :)
[0] http://marc.info/?l=linux-omap&m=138524030509240&w=2
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-04 16:01 ` Sebastian Reichel
0 siblings, 0 replies; 183+ messages in thread
From: Sebastian Reichel @ 2013-12-04 16:01 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge, Tony Lindgren, Laurent Pinchart, Stefan Roese,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
Hi,
On Wed, Dec 04, 2013 at 02:28:27PM +0200, Tomi Valkeinen wrote:
> Here's a new version for DT support to OMAP Display Subsystem. See
> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the
> previous version, which contains thoughts about the related problems.
>
> The major change in this version is the use of V4L2 and CDF style port/endpoint
> style in the DT data. However, note that even if the DT data contains proper
> port & endpoint data, the drivers only use the first endpoint. This is to
> simplify the patches, as adding full support for the ports and endpoints to the
> drivers will be a big task. This approach still works with more or less all the
> boards, as the only cases where the simpler model is an issue are the boards
> with multiple display devices connected to a single output.
>
> Laurent, I'd appreciate if you could have a look at the .dts changes, to see if
> there's anything that's clearly not CDF compatible.
>
> The patches can also be found from:
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
Will this be ready for 3.14? Depending on that I would handle
omapdss support for the N900 differently. If this code gets merged
into 3.14 I will update the N900 patches [0] accordingly. Otherwise
I would suggest to take the N900 patches as is for 3.14 and I will
take care of adding the omapdss DT support to the panel (and the
N900.dts) separately.
> [...]
> - No binding documentation. I will add them for the next version, if there are
> no major changes needed. Hopefully the bindings are quite self-explanatory
> for people with understanding of the hardware in question.
It is :)
[0] http://marc.info/?l=linux-omap&m=138524030509240&w=2
-- Sebastian
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-04 16:01 ` Sebastian Reichel
@ 2013-12-05 9:41 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-05 9:41 UTC (permalink / raw)
To: Tony Lindgren, Sebastian Reichel
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Laurent Pinchart, Stefan Roese, Robert Nelson,
Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]
On 2013-12-04 18:01, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Dec 04, 2013 at 02:28:27PM +0200, Tomi Valkeinen wrote:
>> Here's a new version for DT support to OMAP Display Subsystem. See
>> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the
>> previous version, which contains thoughts about the related problems.
>>
>> The major change in this version is the use of V4L2 and CDF style port/endpoint
>> style in the DT data. However, note that even if the DT data contains proper
>> port & endpoint data, the drivers only use the first endpoint. This is to
>> simplify the patches, as adding full support for the ports and endpoints to the
>> drivers will be a big task. This approach still works with more or less all the
>> boards, as the only cases where the simpler model is an issue are the boards
>> with multiple display devices connected to a single output.
>>
>> Laurent, I'd appreciate if you could have a look at the .dts changes, to see if
>> there's anything that's clearly not CDF compatible.
>>
>> The patches can also be found from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
>
> Will this be ready for 3.14? Depending on that I would handle
That is my hope. We have been missing DSS DT bindings for too long, and
maintaining and adding new mixed DT/non-DT panels, as done for omap4
now, is just a big headache.
The bindings in my series are probably not perfect, but I believe they
should be fine enough. I didn't get any NACKs for the previous versions
of this series, and the only reason I haven't been pushing these to
mainline is that I haven't been satisfied with the bindings.
Laurent promised to have a look at the bindings to see if he notices
anything that would conflict with Common Display Framework bindings. If
he's ok with the bindings, I think we can decide next week if these will
be merged for 3.14.
> omapdss support for the N900 differently. If this code gets merged
> into 3.14 I will update the N900 patches [0] accordingly. Otherwise
> I would suggest to take the N900 patches as is for 3.14 and I will
> take care of adding the omapdss DT support to the panel (and the
> N900.dts) separately.
I really would not like to add any more hacks for DSS.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-05 9:41 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-05 9:41 UTC (permalink / raw)
To: Tony Lindgren, Sebastian Reichel
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Laurent Pinchart, Stefan Roese, Robert Nelson,
Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 2319 bytes --]
On 2013-12-04 18:01, Sebastian Reichel wrote:
> Hi,
>
> On Wed, Dec 04, 2013 at 02:28:27PM +0200, Tomi Valkeinen wrote:
>> Here's a new version for DT support to OMAP Display Subsystem. See
>> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of the
>> previous version, which contains thoughts about the related problems.
>>
>> The major change in this version is the use of V4L2 and CDF style port/endpoint
>> style in the DT data. However, note that even if the DT data contains proper
>> port & endpoint data, the drivers only use the first endpoint. This is to
>> simplify the patches, as adding full support for the ports and endpoints to the
>> drivers will be a big task. This approach still works with more or less all the
>> boards, as the only cases where the simpler model is an issue are the boards
>> with multiple display devices connected to a single output.
>>
>> Laurent, I'd appreciate if you could have a look at the .dts changes, to see if
>> there's anything that's clearly not CDF compatible.
>>
>> The patches can also be found from:
>> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
>
> Will this be ready for 3.14? Depending on that I would handle
That is my hope. We have been missing DSS DT bindings for too long, and
maintaining and adding new mixed DT/non-DT panels, as done for omap4
now, is just a big headache.
The bindings in my series are probably not perfect, but I believe they
should be fine enough. I didn't get any NACKs for the previous versions
of this series, and the only reason I haven't been pushing these to
mainline is that I haven't been satisfied with the bindings.
Laurent promised to have a look at the bindings to see if he notices
anything that would conflict with Common Display Framework bindings. If
he's ok with the bindings, I think we can decide next week if these will
be merged for 3.14.
> omapdss support for the N900 differently. If this code gets merged
> into 3.14 I will update the N900 patches [0] accordingly. Otherwise
> I would suggest to take the N900 patches as is for 3.14 and I will
> take care of adding the omapdss DT support to the panel (and the
> N900.dts) separately.
I really would not like to add any more hacks for DSS.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-04 12:28 ` Tomi Valkeinen
@ 2013-12-12 0:39 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-12 0:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
Hi Tomi,
On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
> Hi,
>
> Here's a new version for DT support to OMAP Display Subsystem. See
> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
> the previous version, which contains thoughts about the related problems.
>
> The major change in this version is the use of V4L2 and CDF style
> port/endpoint style in the DT data.
That's great, and I fully support that. This also calls for refactoring the
V4L2 DT bindings and support code to share them with display devices. A
bikeshedding question is where to put the common code.
> However, note that even if the DT data contains proper port & endpoint data,
> the drivers only use the first endpoint. This is to simplify the patches, as
> adding full support for the ports and endpoints to the drivers will be a big
> task.
That's perfectly fine, there's no need to implement unused features just for
the sake of it, as long as the bindings are forward-compatible in that
respect.
> This approach still works with more or less all the boards, as the only
> cases where the simpler model is an issue are the boards with multiple
> display devices connected to a single output.
>
> Laurent, I'd appreciate if you could have a look at the .dts changes, to see
> if there's anything that's clearly not CDF compatible.
I've quickly reviewed the patch set, concentrating on the .dts changes.
Overall it looks good to me, but I suspect that we will need quite some time
to finalize standard bindings as there's lots of small details that need to be
taken care of.
The major point that bothers we, as explained in my reply to one of the
patches, is that I feel like the multi-device model (virtual DSS core + DSS
modules) might not accurately represent the hardware. Departing from it
probably sounds scary but might not be such a large change.
> The patches can also be found from:
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
>
> A few notes:
>
> - The DT data are added separately in the end of .dts files for clarity. In
> the final version I will move them to appropriate places in the .dts
> files.
>
> - No binding documentation. I will add them for the next version, if there
> are no major changes needed. Hopefully the bindings are quite self-
> explanatory for people with understanding of the hardware in question.
My plan is to split the connection information from the V4L2 bindings and make
that a separate document. If all goes well I should be able to spend Saturday
on this.
> - The connectors' compatible strings are "ti,xxx". As there's nothing TI
> specific there, I think I will rename them to be without "ti".
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-12 0:39 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-12 0:39 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
Hi Tomi,
On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
> Hi,
>
> Here's a new version for DT support to OMAP Display Subsystem. See
> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
> the previous version, which contains thoughts about the related problems.
>
> The major change in this version is the use of V4L2 and CDF style
> port/endpoint style in the DT data.
That's great, and I fully support that. This also calls for refactoring the
V4L2 DT bindings and support code to share them with display devices. A
bikeshedding question is where to put the common code.
> However, note that even if the DT data contains proper port & endpoint data,
> the drivers only use the first endpoint. This is to simplify the patches, as
> adding full support for the ports and endpoints to the drivers will be a big
> task.
That's perfectly fine, there's no need to implement unused features just for
the sake of it, as long as the bindings are forward-compatible in that
respect.
> This approach still works with more or less all the boards, as the only
> cases where the simpler model is an issue are the boards with multiple
> display devices connected to a single output.
>
> Laurent, I'd appreciate if you could have a look at the .dts changes, to see
> if there's anything that's clearly not CDF compatible.
I've quickly reviewed the patch set, concentrating on the .dts changes.
Overall it looks good to me, but I suspect that we will need quite some time
to finalize standard bindings as there's lots of small details that need to be
taken care of.
The major point that bothers we, as explained in my reply to one of the
patches, is that I feel like the multi-device model (virtual DSS core + DSS
modules) might not accurately represent the hardware. Departing from it
probably sounds scary but might not be such a large change.
> The patches can also be found from:
> git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt
>
> A few notes:
>
> - The DT data are added separately in the end of .dts files for clarity. In
> the final version I will move them to appropriate places in the .dts
> files.
>
> - No binding documentation. I will add them for the next version, if there
> are no major changes needed. Hopefully the bindings are quite self-
> explanatory for people with understanding of the hardware in question.
My plan is to split the connection information from the V4L2 bindings and make
that a separate document. If all goes well I should be able to spend Saturday
on this.
> - The connectors' compatible strings are "ti,xxx". As there's nothing TI
> specific there, I think I will rename them to be without "ti".
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-12 0:39 ` Laurent Pinchart
@ 2013-12-12 8:54 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 8:54 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 4132 bytes --]
Hi,
On 2013-12-12 02:39, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
>> Hi,
>>
>> Here's a new version for DT support to OMAP Display Subsystem. See
>> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
>> the previous version, which contains thoughts about the related problems.
>>
>> The major change in this version is the use of V4L2 and CDF style
>> port/endpoint style in the DT data.
>
> That's great, and I fully support that. This also calls for refactoring the
> V4L2 DT bindings and support code to share them with display devices. A
> bikeshedding question is where to put the common code.
Thanks very much for review!
I know drivers/video is in practice "fbdev", but drivers/video (the
words) sound like the best place for things related to video.
We should establish a committee to ponder this important question.
Btw, I don't know if you noticed (or did I mention it somewhere): I use
a bit shortened form of the V4L2 bindings. If there's just one endpoint,
I omit the port node. I think that's always unambiguous (compared to
also omitting the endpoint node, and having the properties in the main
node, as was mentioned in some other thread).
I also don't supply the same data for both endpoints, when the data is
about the link. E.g. I think the V4L2 binding doc suggests to supply
things like bus-width for both endpoints. I only supply the data for the
endpoint that uses that data. With some encoders/panels the same data
could be needed on both ends, but not in these patches.
>> However, note that even if the DT data contains proper port & endpoint data,
>> the drivers only use the first endpoint. This is to simplify the patches, as
>> adding full support for the ports and endpoints to the drivers will be a big
>> task.
>
> That's perfectly fine, there's no need to implement unused features just for
> the sake of it, as long as the bindings are forward-compatible in that
> respect.
>
>> This approach still works with more or less all the boards, as the only
>> cases where the simpler model is an issue are the boards with multiple
>> display devices connected to a single output.
>>
>> Laurent, I'd appreciate if you could have a look at the .dts changes, to see
>> if there's anything that's clearly not CDF compatible.
>
> I've quickly reviewed the patch set, concentrating on the .dts changes.
> Overall it looks good to me, but I suspect that we will need quite some time
> to finalize standard bindings as there's lots of small details that need to be
> taken care of.
Yes. I want to get this forward as it's becoming too much pain to manage
things without DSS DT support, when the rest of the OMAP platform code
is using DT.
The most important thing in the DSS DT bindings for now is that they
should contain enough information so that any future DT bindings changes
can be handled with a boot-time conversion code.
Actually, even the endpoint/port stuff is extra, as that could be
deduced even from the "video-source" method I used in earlier DT versions.
> The major point that bothers we, as explained in my reply to one of the
> patches, is that I feel like the multi-device model (virtual DSS core + DSS
> modules) might not accurately represent the hardware. Departing from it
> probably sounds scary but might not be such a large change.
There are actually two separate things here. One is the multi-device
model, having separate device for each DSS submodule. The other is
having the 'omapdss' "virtual" platform device.
Note that the "dss_core" device is a real HW block, and depicted as the
"dss" node in DT data, whereas "omapdss" device is not present in the DT
data, and is created dynamically at boot time.
The omapdss device is a legacy thing, but nowadays it is mainly used to
pass platform data. Removing omapdss device is not easy, but the only
questions around that is how to implement the required platform-data
functionalities, and it doesn't affect the DT data.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-12 8:54 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-12 8:54 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 4132 bytes --]
Hi,
On 2013-12-12 02:39, Laurent Pinchart wrote:
> Hi Tomi,
>
> On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
>> Hi,
>>
>> Here's a new version for DT support to OMAP Display Subsystem. See
>> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro of
>> the previous version, which contains thoughts about the related problems.
>>
>> The major change in this version is the use of V4L2 and CDF style
>> port/endpoint style in the DT data.
>
> That's great, and I fully support that. This also calls for refactoring the
> V4L2 DT bindings and support code to share them with display devices. A
> bikeshedding question is where to put the common code.
Thanks very much for review!
I know drivers/video is in practice "fbdev", but drivers/video (the
words) sound like the best place for things related to video.
We should establish a committee to ponder this important question.
Btw, I don't know if you noticed (or did I mention it somewhere): I use
a bit shortened form of the V4L2 bindings. If there's just one endpoint,
I omit the port node. I think that's always unambiguous (compared to
also omitting the endpoint node, and having the properties in the main
node, as was mentioned in some other thread).
I also don't supply the same data for both endpoints, when the data is
about the link. E.g. I think the V4L2 binding doc suggests to supply
things like bus-width for both endpoints. I only supply the data for the
endpoint that uses that data. With some encoders/panels the same data
could be needed on both ends, but not in these patches.
>> However, note that even if the DT data contains proper port & endpoint data,
>> the drivers only use the first endpoint. This is to simplify the patches, as
>> adding full support for the ports and endpoints to the drivers will be a big
>> task.
>
> That's perfectly fine, there's no need to implement unused features just for
> the sake of it, as long as the bindings are forward-compatible in that
> respect.
>
>> This approach still works with more or less all the boards, as the only
>> cases where the simpler model is an issue are the boards with multiple
>> display devices connected to a single output.
>>
>> Laurent, I'd appreciate if you could have a look at the .dts changes, to see
>> if there's anything that's clearly not CDF compatible.
>
> I've quickly reviewed the patch set, concentrating on the .dts changes.
> Overall it looks good to me, but I suspect that we will need quite some time
> to finalize standard bindings as there's lots of small details that need to be
> taken care of.
Yes. I want to get this forward as it's becoming too much pain to manage
things without DSS DT support, when the rest of the OMAP platform code
is using DT.
The most important thing in the DSS DT bindings for now is that they
should contain enough information so that any future DT bindings changes
can be handled with a boot-time conversion code.
Actually, even the endpoint/port stuff is extra, as that could be
deduced even from the "video-source" method I used in earlier DT versions.
> The major point that bothers we, as explained in my reply to one of the
> patches, is that I feel like the multi-device model (virtual DSS core + DSS
> modules) might not accurately represent the hardware. Departing from it
> probably sounds scary but might not be such a large change.
There are actually two separate things here. One is the multi-device
model, having separate device for each DSS submodule. The other is
having the 'omapdss' "virtual" platform device.
Note that the "dss_core" device is a real HW block, and depicted as the
"dss" node in DT data, whereas "omapdss" device is not present in the DT
data, and is created dynamically at boot time.
The omapdss device is a legacy thing, but nowadays it is mainly used to
pass platform data. Removing omapdss device is not easy, but the only
questions around that is how to implement the required platform-data
functionalities, and it doesn't affect the DT data.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-12 8:54 ` Tomi Valkeinen
@ 2013-12-13 3:45 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 3:45 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 5743 bytes --]
Hi Tomi,
On Thursday 12 December 2013 10:54:48 Tomi Valkeinen wrote:
> On 2013-12-12 02:39, Laurent Pinchart wrote:
> > On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> Here's a new version for DT support to OMAP Display Subsystem. See
> >> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro
> >> of the previous version, which contains thoughts about the related
> >> problems.
> >>
> >> The major change in this version is the use of V4L2 and CDF style
> >> port/endpoint style in the DT data.
> >
> > That's great, and I fully support that. This also calls for refactoring
> > the V4L2 DT bindings and support code to share them with display devices.
> > A bikeshedding question is where to put the common code.
>
> Thanks very much for review!
>
> I know drivers/video is in practice "fbdev", but drivers/video (the
> words) sound like the best place for things related to video.
That's an option as well, but I'm not sure I like the idea of mixing fbdev and
generic video in a single directory. We could use a subdirectory of
drivers/video.
> We should establish a committee to ponder this important question.
>
> Btw, I don't know if you noticed (or did I mention it somewhere): I use
> a bit shortened form of the V4L2 bindings. If there's just one endpoint,
> I omit the port node. I think that's always unambiguous (compared to
> also omitting the endpoint node, and having the properties in the main
> node, as was mentioned in some other thread).
Yes, I've seen that. I need to analyze this in detail, that's planned for when
I'll work on sharing the DT parsing code.
> I also don't supply the same data for both endpoints, when the data is about
> the link. E.g. I think the V4L2 binding doc suggests to supply things like
> bus-width for both endpoints. I only supply the data for the endpoint that
> uses that data. With some encoders/panels the same data could be needed on
> both ends, but not in these patches.
How do you handle the situation where the two drivers (for each end of the
link) need to know the bus width for instance ?
> >> However, note that even if the DT data contains proper port & endpoint
> >> data, the drivers only use the first endpoint. This is to simplify the
> >> patches, as adding full support for the ports and endpoints to the
> >> drivers will be a big task.
> >
> > That's perfectly fine, there's no need to implement unused features just
> > for the sake of it, as long as the bindings are forward-compatible in
> > that respect.
> >
> >> This approach still works with more or less all the boards, as the only
> >> cases where the simpler model is an issue are the boards with multiple
> >> display devices connected to a single output.
> >>
> >> Laurent, I'd appreciate if you could have a look at the .dts changes, to
> >> see if there's anything that's clearly not CDF compatible.
> >
> > I've quickly reviewed the patch set, concentrating on the .dts changes.
> > Overall it looks good to me, but I suspect that we will need quite some
> > time to finalize standard bindings as there's lots of small details that
> > need to be taken care of.
>
> Yes. I want to get this forward as it's becoming too much pain to manage
> things without DSS DT support, when the rest of the OMAP platform code is
> using DT.
>
> The most important thing in the DSS DT bindings for now is that they should
> contain enough information so that any future DT bindings changes can be
> handled with a boot-time conversion code.
I'm afraid I can't give you any guarantee here. The bindings will be unstable
for some time, and we'll have to deal with that somehow.
> Actually, even the endpoint/port stuff is extra, as that could be deduced
> even from the "video-source" method I used in earlier DT versions.
>
> > The major point that bothers we, as explained in my reply to one of the
> > patches, is that I feel like the multi-device model (virtual DSS core +
> > DSS modules) might not accurately represent the hardware. Departing from
> > it probably sounds scary but might not be such a large change.
>
> There are actually two separate things here. One is the multi-device model,
> having separate device for each DSS submodule. The other is having the
> 'omapdss' "virtual" platform device.
>
> Note that the "dss_core" device is a real HW block, and depicted as the
> "dss" node in DT data, whereas "omapdss" device is not present in the DT
> data, and is created dynamically at boot time.
That's a distinction I've missed.
> The omapdss device is a legacy thing, but nowadays it is mainly used to pass
> platform data. Removing omapdss device is not easy, but the only questions
> around that is how to implement the required platform-data functionalities,
> and it doesn't affect the DT data.
The omapdss platform data structure contains the following fields
- get_context_loss_count: What is that used for ?
- num_devices, devices, default_device: What are those used for ?
- default_display_name: This should be easy to move to DT.
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline.
What's their purpose, and how are they implemented on platforms that make use
of them ? Is the pinmux API an option ?
- set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a generic
solution is needed here.
- version: Given that we detect the DSS revision based on the SoC revision,
I'm tempted to either explicitly encode the DSS revision in the compatible
string, or let the DSS driver query the SoC revision somehow. The later is
considered as a layering violation, but let's face it, I can't see the DSS
being used on a non-OMAP platform.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-13 3:45 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 3:45 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 5743 bytes --]
Hi Tomi,
On Thursday 12 December 2013 10:54:48 Tomi Valkeinen wrote:
> On 2013-12-12 02:39, Laurent Pinchart wrote:
> > On Wednesday 04 December 2013 14:28:27 Tomi Valkeinen wrote:
> >> Hi,
> >>
> >> Here's a new version for DT support to OMAP Display Subsystem. See
> >> http://article.gmane.org/gmane.linux.ports.arm.omap/102689 for the intro
> >> of the previous version, which contains thoughts about the related
> >> problems.
> >>
> >> The major change in this version is the use of V4L2 and CDF style
> >> port/endpoint style in the DT data.
> >
> > That's great, and I fully support that. This also calls for refactoring
> > the V4L2 DT bindings and support code to share them with display devices.
> > A bikeshedding question is where to put the common code.
>
> Thanks very much for review!
>
> I know drivers/video is in practice "fbdev", but drivers/video (the
> words) sound like the best place for things related to video.
That's an option as well, but I'm not sure I like the idea of mixing fbdev and
generic video in a single directory. We could use a subdirectory of
drivers/video.
> We should establish a committee to ponder this important question.
>
> Btw, I don't know if you noticed (or did I mention it somewhere): I use
> a bit shortened form of the V4L2 bindings. If there's just one endpoint,
> I omit the port node. I think that's always unambiguous (compared to
> also omitting the endpoint node, and having the properties in the main
> node, as was mentioned in some other thread).
Yes, I've seen that. I need to analyze this in detail, that's planned for when
I'll work on sharing the DT parsing code.
> I also don't supply the same data for both endpoints, when the data is about
> the link. E.g. I think the V4L2 binding doc suggests to supply things like
> bus-width for both endpoints. I only supply the data for the endpoint that
> uses that data. With some encoders/panels the same data could be needed on
> both ends, but not in these patches.
How do you handle the situation where the two drivers (for each end of the
link) need to know the bus width for instance ?
> >> However, note that even if the DT data contains proper port & endpoint
> >> data, the drivers only use the first endpoint. This is to simplify the
> >> patches, as adding full support for the ports and endpoints to the
> >> drivers will be a big task.
> >
> > That's perfectly fine, there's no need to implement unused features just
> > for the sake of it, as long as the bindings are forward-compatible in
> > that respect.
> >
> >> This approach still works with more or less all the boards, as the only
> >> cases where the simpler model is an issue are the boards with multiple
> >> display devices connected to a single output.
> >>
> >> Laurent, I'd appreciate if you could have a look at the .dts changes, to
> >> see if there's anything that's clearly not CDF compatible.
> >
> > I've quickly reviewed the patch set, concentrating on the .dts changes.
> > Overall it looks good to me, but I suspect that we will need quite some
> > time to finalize standard bindings as there's lots of small details that
> > need to be taken care of.
>
> Yes. I want to get this forward as it's becoming too much pain to manage
> things without DSS DT support, when the rest of the OMAP platform code is
> using DT.
>
> The most important thing in the DSS DT bindings for now is that they should
> contain enough information so that any future DT bindings changes can be
> handled with a boot-time conversion code.
I'm afraid I can't give you any guarantee here. The bindings will be unstable
for some time, and we'll have to deal with that somehow.
> Actually, even the endpoint/port stuff is extra, as that could be deduced
> even from the "video-source" method I used in earlier DT versions.
>
> > The major point that bothers we, as explained in my reply to one of the
> > patches, is that I feel like the multi-device model (virtual DSS core +
> > DSS modules) might not accurately represent the hardware. Departing from
> > it probably sounds scary but might not be such a large change.
>
> There are actually two separate things here. One is the multi-device model,
> having separate device for each DSS submodule. The other is having the
> 'omapdss' "virtual" platform device.
>
> Note that the "dss_core" device is a real HW block, and depicted as the
> "dss" node in DT data, whereas "omapdss" device is not present in the DT
> data, and is created dynamically at boot time.
That's a distinction I've missed.
> The omapdss device is a legacy thing, but nowadays it is mainly used to pass
> platform data. Removing omapdss device is not easy, but the only questions
> around that is how to implement the required platform-data functionalities,
> and it doesn't affect the DT data.
The omapdss platform data structure contains the following fields
- get_context_loss_count: What is that used for ?
- num_devices, devices, default_device: What are those used for ?
- default_display_name: This should be easy to move to DT.
- dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline.
What's their purpose, and how are they implemented on platforms that make use
of them ? Is the pinmux API an option ?
- set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a generic
solution is needed here.
- version: Given that we detect the DSS revision based on the SoC revision,
I'm tempted to either explicitly encode the DSS revision in the compatible
string, or let the DSS driver query the SoC revision somehow. The later is
considered as a layering violation, but let's face it, I can't see the DSS
being used on a non-OMAP platform.
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-13 3:45 ` Laurent Pinchart
@ 2013-12-13 8:16 ` Geert Uytterhoeven
-1 siblings, 0 replies; 183+ messages in thread
From: Geert Uytterhoeven @ 2013-12-13 8:16 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tomi Valkeinen, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Linux Fbdev development list, devicetree-u79uwXL29TY76Z2rM5mHXA,
Archit Taneja, Darren Etheridge, Tony Lindgren, Stefan Roese,
Sebastian Reichel, Robert Nelson, Dr . H . Nikolaus Schaller,
Marek Belisko
On Fri, Dec 13, 2013 at 4:45 AM, Laurent Pinchart
<laurent.pinchart-ryLnwIuWjnjg/C1BVhZhaw@public.gmane.org> wrote:
>> > That's great, and I fully support that. This also calls for refactoring
>> > the V4L2 DT bindings and support code to share them with display devices.
>> > A bikeshedding question is where to put the common code.
>>
>> Thanks very much for review!
>>
>> I know drivers/video is in practice "fbdev", but drivers/video (the
>> words) sound like the best place for things related to video.
>
> That's an option as well, but I'm not sure I like the idea of mixing fbdev and
> generic video in a single directory. We could use a subdirectory of
> drivers/video.
Or reshuffle the various graphics/video/fb/console directories (more
bikeshedding). With git it's not that painful.
Frame buffer devices ended up in drivers/video because at that time, graphics
cards were called video cards. Moving video only entered the picture later.
drivers/fb/ (currently most of drivers/video/)
drivers/console/ (currently drivers/video/console/)
...
Or should fb be under gpu?
What about drivers/media? Video and audio are multi-media, too...
Baah, bad idea... too much bikeshedding ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
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
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-13 8:16 ` Geert Uytterhoeven
0 siblings, 0 replies; 183+ messages in thread
From: Geert Uytterhoeven @ 2013-12-13 8:16 UTC (permalink / raw)
To: Laurent Pinchart
Cc: Tomi Valkeinen, linux-omap-u79uwXL29TY76Z2rM5mHXA,
Linux Fbdev development list, devicetree-u79uwXL29TY76Z2rM5mHXA,
Archit Taneja, Darren Etheridge, Tony Lindgren, Stefan Roese,
Sebastian Reichel, Robert Nelson, Dr . H . Nikolaus Schaller,
Marek Belisko
On Fri, Dec 13, 2013 at 4:45 AM, Laurent Pinchart
<laurent.pinchart@ideasonboard.com> wrote:
>> > That's great, and I fully support that. This also calls for refactoring
>> > the V4L2 DT bindings and support code to share them with display devices.
>> > A bikeshedding question is where to put the common code.
>>
>> Thanks very much for review!
>>
>> I know drivers/video is in practice "fbdev", but drivers/video (the
>> words) sound like the best place for things related to video.
>
> That's an option as well, but I'm not sure I like the idea of mixing fbdev and
> generic video in a single directory. We could use a subdirectory of
> drivers/video.
Or reshuffle the various graphics/video/fb/console directories (more
bikeshedding). With git it's not that painful.
Frame buffer devices ended up in drivers/video because at that time, graphics
cards were called video cards. Moving video only entered the picture later.
drivers/fb/ (currently most of drivers/video/)
drivers/console/ (currently drivers/video/console/)
...
Or should fb be under gpu?
What about drivers/media? Video and audio are multi-media, too...
Baah, bad idea... too much bikeshedding ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-13 3:45 ` Laurent Pinchart
@ 2013-12-13 10:05 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 10:05 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 4702 bytes --]
On 2013-12-13 05:45, Laurent Pinchart wrote:
>> I know drivers/video is in practice "fbdev", but drivers/video (the
>> words) sound like the best place for things related to video.
>
> That's an option as well, but I'm not sure I like the idea of mixing fbdev and
> generic video in a single directory. We could use a subdirectory of
> drivers/video.
Right, that's what I meant.
>> I also don't supply the same data for both endpoints, when the data is about
>> the link. E.g. I think the V4L2 binding doc suggests to supply things like
>> bus-width for both endpoints. I only supply the data for the endpoint that
>> uses that data. With some encoders/panels the same data could be needed on
>> both ends, but not in these patches.
>
> How do you handle the situation where the two drivers (for each end of the
> link) need to know the bus width for instance ?
Then I fill the bus-width for both ends, as shown in the V4L2 bindings.
That's what I mean with "I only supply the data for the endpoint that
uses that data". If both ends use the data, I supply it for both.
>> The most important thing in the DSS DT bindings for now is that they should
>> contain enough information so that any future DT bindings changes can be
>> handled with a boot-time conversion code.
>
> I'm afraid I can't give you any guarantee here. The bindings will be unstable
> for some time, and we'll have to deal with that somehow.
I'm not asking for a guarantee. Just "yes, feels fine" =).
> The omapdss platform data structure contains the following fields
>
> - get_context_loss_count: What is that used for ?
To find out if a HW block has been turned off and it has lost its
registers contents. It's an optimization, without it we need to restore
registers each time when runtime_resume() hook is called.
However, that's on its way out. I've already made new PM code for dispc
which doesn't use that. But I can't merge it before omapdrm has been
fixed to properly set things up when enabling a display.
> - num_devices, devices, default_device: What are those used for ?
Nothing anymore. They can be removed.
> - default_display_name: This should be easy to move to DT.
How? I handled it so that I assign the aliases for displays, and
display0 is always the default display. "default display name" is not
really a hw property =).
I think this should not be used for DT, and just use the display0 as
default (if we use aliases). If we don't use aliases, and instead use
the label properties as discussed in other thread, then there has to be
some other mechanism to tell which display should be used.
> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline.
> What's their purpose, and how are they implemented on platforms that make use
> of them ? Is the pinmux API an option ?
They are used in mainline, grep again =). They set pinmuxing for DSI.
Pinmux API is an option, but I think it would require a new driver. The
DSI pins for DSI1 and DSI2 are configured in a single register, where
the fields go in seemingly random order with varying widths.
pinmux-single cannot be used.
> - set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a generic
> solution is needed here.
>
> - version: Given that we detect the DSS revision based on the SoC revision,
> I'm tempted to either explicitly encode the DSS revision in the compatible
> string, or let the DSS driver query the SoC revision somehow. The later is
> considered as a layering violation, but let's face it, I can't see the DSS
> being used on a non-OMAP platform.
I also would just use the compatible string, but we need to separate
between different OMAP ES versions. Doing that would mean we'd need
different .dtsi and .dts files for the different OMAP ES versions. It
would be a mess.
I have a TODO item to study this. There are only a few things that are
problematic (changed between ES versions without changing DSS HW
revision). If I can find a way around those, the compatible string
should be enough.
One example is the width of a blanking interval. Newer OMAP3 revisions
have a slightly wider field. I didn't try, but maybe I can write 1-bits
to the register, then read it, and if only part of those 1 bits "stick",
I know it's an old revision.
Anyway, I think this platform data thing is not strictly related. None
of these items affect the DT data (except the pinmuxing, but I think
it's fine to add that later). So while the above issues need to be fixed
at some point, I think they don't affect this series (well, the default
display is there which may affect).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-13 10:05 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 10:05 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-omap-u79uwXL29TY76Z2rM5mHXA,
linux-fbdev-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 4702 bytes --]
On 2013-12-13 05:45, Laurent Pinchart wrote:
>> I know drivers/video is in practice "fbdev", but drivers/video (the
>> words) sound like the best place for things related to video.
>
> That's an option as well, but I'm not sure I like the idea of mixing fbdev and
> generic video in a single directory. We could use a subdirectory of
> drivers/video.
Right, that's what I meant.
>> I also don't supply the same data for both endpoints, when the data is about
>> the link. E.g. I think the V4L2 binding doc suggests to supply things like
>> bus-width for both endpoints. I only supply the data for the endpoint that
>> uses that data. With some encoders/panels the same data could be needed on
>> both ends, but not in these patches.
>
> How do you handle the situation where the two drivers (for each end of the
> link) need to know the bus width for instance ?
Then I fill the bus-width for both ends, as shown in the V4L2 bindings.
That's what I mean with "I only supply the data for the endpoint that
uses that data". If both ends use the data, I supply it for both.
>> The most important thing in the DSS DT bindings for now is that they should
>> contain enough information so that any future DT bindings changes can be
>> handled with a boot-time conversion code.
>
> I'm afraid I can't give you any guarantee here. The bindings will be unstable
> for some time, and we'll have to deal with that somehow.
I'm not asking for a guarantee. Just "yes, feels fine" =).
> The omapdss platform data structure contains the following fields
>
> - get_context_loss_count: What is that used for ?
To find out if a HW block has been turned off and it has lost its
registers contents. It's an optimization, without it we need to restore
registers each time when runtime_resume() hook is called.
However, that's on its way out. I've already made new PM code for dispc
which doesn't use that. But I can't merge it before omapdrm has been
fixed to properly set things up when enabling a display.
> - num_devices, devices, default_device: What are those used for ?
Nothing anymore. They can be removed.
> - default_display_name: This should be easy to move to DT.
How? I handled it so that I assign the aliases for displays, and
display0 is always the default display. "default display name" is not
really a hw property =).
I think this should not be used for DT, and just use the display0 as
default (if we use aliases). If we don't use aliases, and instead use
the label properties as discussed in other thread, then there has to be
some other mechanism to tell which display should be used.
> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in mainline.
> What's their purpose, and how are they implemented on platforms that make use
> of them ? Is the pinmux API an option ?
They are used in mainline, grep again =). They set pinmuxing for DSI.
Pinmux API is an option, but I think it would require a new driver. The
DSI pins for DSI1 and DSI2 are configured in a single register, where
the fields go in seemingly random order with varying widths.
pinmux-single cannot be used.
> - set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a generic
> solution is needed here.
>
> - version: Given that we detect the DSS revision based on the SoC revision,
> I'm tempted to either explicitly encode the DSS revision in the compatible
> string, or let the DSS driver query the SoC revision somehow. The later is
> considered as a layering violation, but let's face it, I can't see the DSS
> being used on a non-OMAP platform.
I also would just use the compatible string, but we need to separate
between different OMAP ES versions. Doing that would mean we'd need
different .dtsi and .dts files for the different OMAP ES versions. It
would be a mess.
I have a TODO item to study this. There are only a few things that are
problematic (changed between ES versions without changing DSS HW
revision). If I can find a way around those, the compatible string
should be enough.
One example is the width of a blanking interval. Newer OMAP3 revisions
have a slightly wider field. I didn't try, but maybe I can write 1-bits
to the register, then read it, and if only part of those 1 bits "stick",
I know it's an old revision.
Anyway, I think this platform data thing is not strictly related. None
of these items affect the DT data (except the pinmuxing, but I think
it's fine to add that later). So while the above issues need to be fixed
at some point, I think they don't affect this series (well, the default
display is there which may affect).
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-13 10:05 ` Tomi Valkeinen
@ 2013-12-13 14:37 ` Laurent Pinchart
-1 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 14:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 5366 bytes --]
Hi Tomi,
On Friday 13 December 2013 12:05:20 Tomi Valkeinen wrote:
> On 2013-12-13 05:45, Laurent Pinchart wrote:
> >> I know drivers/video is in practice "fbdev", but drivers/video (the
> >> words) sound like the best place for things related to video.
> >
> > That's an option as well, but I'm not sure I like the idea of mixing fbdev
> > and generic video in a single directory. We could use a subdirectory of
> > drivers/video.
>
> Right, that's what I meant.
>
> >> I also don't supply the same data for both endpoints, when the data is
> >> about the link. E.g. I think the V4L2 binding doc suggests to supply
> >> things like bus-width for both endpoints. I only supply the data for the
> >> endpoint that uses that data. With some encoders/panels the same data
> >> could be needed on both ends, but not in these patches.
> >
> > How do you handle the situation where the two drivers (for each end of the
> > link) need to know the bus width for instance ?
>
> Then I fill the bus-width for both ends, as shown in the V4L2 bindings.
> That's what I mean with "I only supply the data for the endpoint that
> uses that data". If both ends use the data, I supply it for both.
That sounds good to me.
> >> The most important thing in the DSS DT bindings for now is that they
> >> should contain enough information so that any future DT bindings changes
> >> can be handled with a boot-time conversion code.
> >
> > I'm afraid I can't give you any guarantee here. The bindings will be
> > unstable for some time, and we'll have to deal with that somehow.
>
> I'm not asking for a guarantee. Just "yes, feels fine" =).
>
> > The omapdss platform data structure contains the following fields
> >
> > - get_context_loss_count: What is that used for ?
>
> To find out if a HW block has been turned off and it has lost its
> registers contents. It's an optimization, without it we need to restore
> registers each time when runtime_resume() hook is called.
>
> However, that's on its way out. I've already made new PM code for dispc
> which doesn't use that. But I can't merge it before omapdrm has been
> fixed to properly set things up when enabling a display.
OK.
> > - num_devices, devices, default_device: What are those used for ?
>
> Nothing anymore. They can be removed.
>
> > - default_display_name: This should be easy to move to DT.
>
> How? I handled it so that I assign the aliases for displays, and
> display0 is always the default display. "default display name" is not
> really a hw property =).
>
> I think this should not be used for DT, and just use the display0 as
> default (if we use aliases). If we don't use aliases, and instead use
> the label properties as discussed in other thread, then there has to be
> some other mechanism to tell which display should be used.
Another option would be to add a phandle that references the default display.
I don't have a strong preference at the moment.
> > - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
> > mainline. What's their purpose, and how are they implemented on platforms
> > that make use of them ? Is the pinmux API an option ?
>
> They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
> They set pinmuxing for DSI. Pinmux API is an option, but I think it would
> require a new driver. The DSI pins for DSI1 and DSI2 are configured in a
> single register, where the fields go in seemingly random order with varying
> widths. pinmux-single cannot be used.
Or, as Archit mentioned, we could pass the SYSCONF registers as resources.
That might not be very clean though.
> > - set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a
> > generic solution is needed here.
> >
> > - version: Given that we detect the DSS revision based on the SoC
> > revision, I'm tempted to either explicitly encode the DSS revision in the
> > compatible string, or let the DSS driver query the SoC revision somehow.
> > The later is considered as a layering violation, but let's face it, I
> > can't see the DSS being used on a non-OMAP platform.
>
> I also would just use the compatible string, but we need to separate between
> different OMAP ES versions. Doing that would mean we'd need different .dtsi
> and .dts files for the different OMAP ES versions. It would be a mess.
>
> I have a TODO item to study this. There are only a few things that are
> problematic (changed between ES versions without changing DSS HW revision).
> If I can find a way around those, the compatible string should be enough.
>
> One example is the width of a blanking interval. Newer OMAP3 revisions have
> a slightly wider field. I didn't try, but maybe I can write 1-bits to the
> register, then read it, and if only part of those 1 bits "stick", I know
> it's an old revision.
>
> Anyway, I think this platform data thing is not strictly related. None of
> these items affect the DT data (except the pinmuxing, but I think it's fine
> to add that later). So while the above issues need to be fixed at some
> point, I think they don't affect this series (well, the default display is
> there which may affect).
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-13 14:37 ` Laurent Pinchart
0 siblings, 0 replies; 183+ messages in thread
From: Laurent Pinchart @ 2013-12-13 14:37 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Tony Lindgren, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 5366 bytes --]
Hi Tomi,
On Friday 13 December 2013 12:05:20 Tomi Valkeinen wrote:
> On 2013-12-13 05:45, Laurent Pinchart wrote:
> >> I know drivers/video is in practice "fbdev", but drivers/video (the
> >> words) sound like the best place for things related to video.
> >
> > That's an option as well, but I'm not sure I like the idea of mixing fbdev
> > and generic video in a single directory. We could use a subdirectory of
> > drivers/video.
>
> Right, that's what I meant.
>
> >> I also don't supply the same data for both endpoints, when the data is
> >> about the link. E.g. I think the V4L2 binding doc suggests to supply
> >> things like bus-width for both endpoints. I only supply the data for the
> >> endpoint that uses that data. With some encoders/panels the same data
> >> could be needed on both ends, but not in these patches.
> >
> > How do you handle the situation where the two drivers (for each end of the
> > link) need to know the bus width for instance ?
>
> Then I fill the bus-width for both ends, as shown in the V4L2 bindings.
> That's what I mean with "I only supply the data for the endpoint that
> uses that data". If both ends use the data, I supply it for both.
That sounds good to me.
> >> The most important thing in the DSS DT bindings for now is that they
> >> should contain enough information so that any future DT bindings changes
> >> can be handled with a boot-time conversion code.
> >
> > I'm afraid I can't give you any guarantee here. The bindings will be
> > unstable for some time, and we'll have to deal with that somehow.
>
> I'm not asking for a guarantee. Just "yes, feels fine" =).
>
> > The omapdss platform data structure contains the following fields
> >
> > - get_context_loss_count: What is that used for ?
>
> To find out if a HW block has been turned off and it has lost its
> registers contents. It's an optimization, without it we need to restore
> registers each time when runtime_resume() hook is called.
>
> However, that's on its way out. I've already made new PM code for dispc
> which doesn't use that. But I can't merge it before omapdrm has been
> fixed to properly set things up when enabling a display.
OK.
> > - num_devices, devices, default_device: What are those used for ?
>
> Nothing anymore. They can be removed.
>
> > - default_display_name: This should be easy to move to DT.
>
> How? I handled it so that I assign the aliases for displays, and
> display0 is always the default display. "default display name" is not
> really a hw property =).
>
> I think this should not be used for DT, and just use the display0 as
> default (if we use aliases). If we don't use aliases, and instead use
> the label properties as discussed in other thread, then there has to be
> some other mechanism to tell which display should be used.
Another option would be to add a phandle that references the default display.
I don't have a strong preference at the moment.
> > - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
> > mainline. What's their purpose, and how are they implemented on platforms
> > that make use of them ? Is the pinmux API an option ?
>
> They are used in mainline, grep again =).
The only implementations I can find in arch/arm/mach-omap2/display.c are
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
}
> They set pinmuxing for DSI. Pinmux API is an option, but I think it would
> require a new driver. The DSI pins for DSI1 and DSI2 are configured in a
> single register, where the fields go in seemingly random order with varying
> widths. pinmux-single cannot be used.
Or, as Archit mentioned, we could pass the SYSCONF registers as resources.
That might not be very clean though.
> > - set_min_bus_tput: We have the same problem for the OMAP3 ISP, so a
> > generic solution is needed here.
> >
> > - version: Given that we detect the DSS revision based on the SoC
> > revision, I'm tempted to either explicitly encode the DSS revision in the
> > compatible string, or let the DSS driver query the SoC revision somehow.
> > The later is considered as a layering violation, but let's face it, I
> > can't see the DSS being used on a non-OMAP platform.
>
> I also would just use the compatible string, but we need to separate between
> different OMAP ES versions. Doing that would mean we'd need different .dtsi
> and .dts files for the different OMAP ES versions. It would be a mess.
>
> I have a TODO item to study this. There are only a few things that are
> problematic (changed between ES versions without changing DSS HW revision).
> If I can find a way around those, the compatible string should be enough.
>
> One example is the width of a blanking interval. Newer OMAP3 revisions have
> a slightly wider field. I didn't try, but maybe I can write 1-bits to the
> register, then read it, and if only part of those 1 bits "stick", I know
> it's an old revision.
>
> Anyway, I think this platform data thing is not strictly related. None of
> these items affect the DT data (except the pinmuxing, but I think it's fine
> to add that later). So while the above issues need to be fixed at some
> point, I think they don't affect this series (well, the default display is
> there which may affect).
--
Regards,
Laurent Pinchart
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-13 14:37 ` Laurent Pinchart
@ 2013-12-13 15:47 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 15:47 UTC (permalink / raw)
To: Laurent Pinchart, Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Stefan Roese, Sebastian Reichel, Robert Nelson,
Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
>>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
>>> mainline. What's their purpose, and how are they implemented on platforms
>>> that make use of them ? Is the pinmux API an option ?
>>
>> They are used in mainline, grep again =).
>
> The only implementations I can find in arch/arm/mach-omap2/display.c are
>
> static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
> {
> return 0;
> }
>
> static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
> {
> }
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-13 15:47 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-13 15:47 UTC (permalink / raw)
To: Laurent Pinchart, Tony Lindgren
Cc: linux-omap, linux-fbdev, devicetree, Archit Taneja,
Darren Etheridge, Stefan Roese, Sebastian Reichel, Robert Nelson,
Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
Hi Laurent, Tony,
On 2013-12-13 16:37, Laurent Pinchart wrote:
>>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
>>> mainline. What's their purpose, and how are they implemented on platforms
>>> that make use of them ? Is the pinmux API an option ?
>>
>> They are used in mainline, grep again =).
>
> The only implementations I can find in arch/arm/mach-omap2/display.c are
>
> static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
> {
> return 0;
> }
>
> static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
> {
> }
Yep. It seems Tony removed the muxing for -rc2 in
e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
code for display.c
Tony, that patch removes DSI muxing, which is not done via DT. I can't
test right now, but I presume DSI displays don't work at all after -rc2.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-13 15:47 ` Tomi Valkeinen
@ 2013-12-13 17:22 ` Tony Lindgren
-1 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-13 17:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 07:49]:
> Hi Laurent, Tony,
>
> On 2013-12-13 16:37, Laurent Pinchart wrote:
>
> >>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
> >>> mainline. What's their purpose, and how are they implemented on platforms
> >>> that make use of them ? Is the pinmux API an option ?
> >>
> >> They are used in mainline, grep again =).
> >
> > The only implementations I can find in arch/arm/mach-omap2/display.c are
> >
> > static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
> > {
> > return 0;
> > }
> >
> > static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
> > {
> > }
>
> Yep. It seems Tony removed the muxing for -rc2 in
> e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
> code for display.c
>
> Tony, that patch removes DSI muxing, which is not done via DT. I can't
> test right now, but I presume DSI displays don't work at all after -rc2.
Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
devices on am3517-evm) as it does not yet remove the legacy data and
that's what's heading to linux next soonish.
With the DT configured displays that muxing needs to be done in the
DSS driver(s) using pinctrl-single.
BTW, I suspect quite a few of the DSI using boards have been broken a
while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
output) as at least the following have been using TWL GPIO to enable
the panel:
board-3430sdp.c
board-devkit8000.c
board-ldp.c
board-omap3stalker.c
This was the case at least for LDP.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-13 17:22 ` Tony Lindgren
0 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-13 17:22 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 07:49]:
> Hi Laurent, Tony,
>
> On 2013-12-13 16:37, Laurent Pinchart wrote:
>
> >>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
> >>> mainline. What's their purpose, and how are they implemented on platforms
> >>> that make use of them ? Is the pinmux API an option ?
> >>
> >> They are used in mainline, grep again =).
> >
> > The only implementations I can find in arch/arm/mach-omap2/display.c are
> >
> > static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
> > {
> > return 0;
> > }
> >
> > static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
> > {
> > }
>
> Yep. It seems Tony removed the muxing for -rc2 in
> e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
> code for display.c
>
> Tony, that patch removes DSI muxing, which is not done via DT. I can't
> test right now, but I presume DSI displays don't work at all after -rc2.
Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
devices on am3517-evm) as it does not yet remove the legacy data and
that's what's heading to linux next soonish.
With the DT configured displays that muxing needs to be done in the
DSS driver(s) using pinctrl-single.
BTW, I suspect quite a few of the DSI using boards have been broken a
while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
output) as at least the following have been using TWL GPIO to enable
the panel:
board-3430sdp.c
board-devkit8000.c
board-ldp.c
board-omap3stalker.c
This was the case at least for LDP.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-13 17:22 ` Tony Lindgren
@ 2013-12-14 7:34 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-14 7:34 UTC (permalink / raw)
To: Tony Lindgren
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]
On 2013-12-13 19:22, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 07:49]:
>> Hi Laurent, Tony,
>>
>> On 2013-12-13 16:37, Laurent Pinchart wrote:
>>
>>>>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
>>>>> mainline. What's their purpose, and how are they implemented on platforms
>>>>> that make use of them ? Is the pinmux API an option ?
>>>>
>>>> They are used in mainline, grep again =).
>>>
>>> The only implementations I can find in arch/arm/mach-omap2/display.c are
>>>
>>> static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
>>> {
>>> return 0;
>>> }
>>>
>>> static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
>>> {
>>> }
>>
>> Yep. It seems Tony removed the muxing for -rc2 in
>> e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
>> code for display.c
>>
>> Tony, that patch removes DSI muxing, which is not done via DT. I can't
>> test right now, but I presume DSI displays don't work at all after -rc2.
>
> Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
> devices on am3517-evm) as it does not yet remove the legacy data and
> that's what's heading to linux next soonish.
That commit is not in the mainline. I'm talking about mainline.
v3.13-rc3 contains e30b06f4d5f000c31a7747a7e7ada78a5fd419a1, and that
breaks DSI displays (just tested). It needs to be reverted (although the
HDMI parts can probably be removed).
Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
not a fix, just a cleanup.
> With the DT configured displays that muxing needs to be done in the
> DSS driver(s) using pinctrl-single.
We don't have any DT configured displays in the mainline.
pinctrl-single doesn't support the kind of register that contains the
DSI muxing. I don't know yet how that should be done. In any case, the
muxing via DT should've been added at the same time as removing the
muxing via platform callback in e30b06f4d5f000c31a77.
> BTW, I suspect quite a few of the DSI using boards have been broken a
> while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
> output) as at least the following have been using TWL GPIO to enable
> the panel:
>
> board-3430sdp.c
> board-devkit8000.c
> board-ldp.c
> board-omap3stalker.c
>
> This was the case at least for LDP.
Only 4430sdp has a DSI display in the mainline. Those boards have DPI
displays.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-14 7:34 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-14 7:34 UTC (permalink / raw)
To: Tony Lindgren
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 2502 bytes --]
On 2013-12-13 19:22, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 07:49]:
>> Hi Laurent, Tony,
>>
>> On 2013-12-13 16:37, Laurent Pinchart wrote:
>>
>>>>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
>>>>> mainline. What's their purpose, and how are they implemented on platforms
>>>>> that make use of them ? Is the pinmux API an option ?
>>>>
>>>> They are used in mainline, grep again =).
>>>
>>> The only implementations I can find in arch/arm/mach-omap2/display.c are
>>>
>>> static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
>>> {
>>> return 0;
>>> }
>>>
>>> static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
>>> {
>>> }
>>
>> Yep. It seems Tony removed the muxing for -rc2 in
>> e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
>> code for display.c
>>
>> Tony, that patch removes DSI muxing, which is not done via DT. I can't
>> test right now, but I presume DSI displays don't work at all after -rc2.
>
> Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
> devices on am3517-evm) as it does not yet remove the legacy data and
> that's what's heading to linux next soonish.
That commit is not in the mainline. I'm talking about mainline.
v3.13-rc3 contains e30b06f4d5f000c31a7747a7e7ada78a5fd419a1, and that
breaks DSI displays (just tested). It needs to be reverted (although the
HDMI parts can probably be removed).
Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
not a fix, just a cleanup.
> With the DT configured displays that muxing needs to be done in the
> DSS driver(s) using pinctrl-single.
We don't have any DT configured displays in the mainline.
pinctrl-single doesn't support the kind of register that contains the
DSI muxing. I don't know yet how that should be done. In any case, the
muxing via DT should've been added at the same time as removing the
muxing via platform callback in e30b06f4d5f000c31a77.
> BTW, I suspect quite a few of the DSI using boards have been broken a
> while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
> output) as at least the following have been using TWL GPIO to enable
> the panel:
>
> board-3430sdp.c
> board-devkit8000.c
> board-ldp.c
> board-omap3stalker.c
>
> This was the case at least for LDP.
Only 4430sdp has a DSI display in the mainline. Those boards have DPI
displays.
Tomi
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-14 7:34 ` Tomi Valkeinen
@ 2013-12-14 14:09 ` Tony Lindgren
-1 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-14 14:09 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 23:36]:
> On 2013-12-13 19:22, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 07:49]:
> >> Hi Laurent, Tony,
> >>
> >> On 2013-12-13 16:37, Laurent Pinchart wrote:
> >>
> >>>>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
> >>>>> mainline. What's their purpose, and how are they implemented on platforms
> >>>>> that make use of them ? Is the pinmux API an option ?
> >>>>
> >>>> They are used in mainline, grep again =).
> >>>
> >>> The only implementations I can find in arch/arm/mach-omap2/display.c are
> >>>
> >>> static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
> >>> {
> >>> return 0;
> >>> }
> >>>
> >>> static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
> >>> {
> >>> }
> >>
> >> Yep. It seems Tony removed the muxing for -rc2 in
> >> e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
> >> code for display.c
> >>
> >> Tony, that patch removes DSI muxing, which is not done via DT. I can't
> >> test right now, but I presume DSI displays don't work at all after -rc2.
> >
> > Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
> > devices on am3517-evm) as it does not yet remove the legacy data and
> > that's what's heading to linux next soonish.
>
> That commit is not in the mainline. I'm talking about mainline.
> v3.13-rc3 contains e30b06f4d5f000c31a7747a7e7ada78a5fd419a1, and that
> breaks DSI displays (just tested). It needs to be reverted (although the
> HDMI parts can probably be removed).
>
> Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
> not a fix, just a cleanup.
Hmm OK sorry looks like I removed some non-legacy mux framework code
by accident. The omap_mux_* parts clearly are dead code for omap4 as
it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
using omap_mux_* functions.
Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
seems to be omap4_tpd12s015_mux_pads(), right?
> > With the DT configured displays that muxing needs to be done in the
> > DSS driver(s) using pinctrl-single.
>
> We don't have any DT configured displays in the mainline.
Yes sorry omap4_dsi_mux_pads() should not have been removed.
> pinctrl-single doesn't support the kind of register that contains the
> DSI muxing. I don't know yet how that should be done. In any case, the
> muxing via DT should've been added at the same time as removing the
> muxing via platform callback in e30b06f4d5f000c31a77.
>
> > BTW, I suspect quite a few of the DSI using boards have been broken a
> > while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
> > output) as at least the following have been using TWL GPIO to enable
> > the panel:
> >
> > board-3430sdp.c
> > board-devkit8000.c
> > board-ldp.c
> > board-omap3stalker.c
> >
> > This was the case at least for LDP.
>
> Only 4430sdp has a DSI display in the mainline. Those boards have DPI
> displays.
Oops right, those are DPI.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-14 14:09 ` Tony Lindgren
0 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-14 14:09 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 23:36]:
> On 2013-12-13 19:22, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@ti.com> [131213 07:49]:
> >> Hi Laurent, Tony,
> >>
> >> On 2013-12-13 16:37, Laurent Pinchart wrote:
> >>
> >>>>> - dsi_enable_pads, dsi_disable_pads: Those don't seem to be used in
> >>>>> mainline. What's their purpose, and how are they implemented on platforms
> >>>>> that make use of them ? Is the pinmux API an option ?
> >>>>
> >>>> They are used in mainline, grep again =).
> >>>
> >>> The only implementations I can find in arch/arm/mach-omap2/display.c are
> >>>
> >>> static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
> >>> {
> >>> return 0;
> >>> }
> >>>
> >>> static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
> >>> {
> >>> }
> >>
> >> Yep. It seems Tony removed the muxing for -rc2 in
> >> e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 ARM: OMAP2+: Remove legacy mux
> >> code for display.c
> >>
> >> Tony, that patch removes DSI muxing, which is not done via DT. I can't
> >> test right now, but I presume DSI displays don't work at all after -rc2.
> >
> > Hmm I suggest you test against commit adfe9361b236 (ARM: dts: Add basic
> > devices on am3517-evm) as it does not yet remove the legacy data and
> > that's what's heading to linux next soonish.
>
> That commit is not in the mainline. I'm talking about mainline.
> v3.13-rc3 contains e30b06f4d5f000c31a7747a7e7ada78a5fd419a1, and that
> breaks DSI displays (just tested). It needs to be reverted (although the
> HDMI parts can probably be removed).
>
> Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
> not a fix, just a cleanup.
Hmm OK sorry looks like I removed some non-legacy mux framework code
by accident. The omap_mux_* parts clearly are dead code for omap4 as
it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
using omap_mux_* functions.
Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
seems to be omap4_tpd12s015_mux_pads(), right?
> > With the DT configured displays that muxing needs to be done in the
> > DSS driver(s) using pinctrl-single.
>
> We don't have any DT configured displays in the mainline.
Yes sorry omap4_dsi_mux_pads() should not have been removed.
> pinctrl-single doesn't support the kind of register that contains the
> DSI muxing. I don't know yet how that should be done. In any case, the
> muxing via DT should've been added at the same time as removing the
> muxing via platform callback in e30b06f4d5f000c31a77.
>
> > BTW, I suspect quite a few of the DSI using boards have been broken a
> > while before 0b2aa8bed3e1 (gpio: twl4030: Fix regression for twl gpio
> > output) as at least the following have been using TWL GPIO to enable
> > the panel:
> >
> > board-3430sdp.c
> > board-devkit8000.c
> > board-ldp.c
> > board-omap3stalker.c
> >
> > This was the case at least for LDP.
>
> Only 4430sdp has a DSI display in the mainline. Those boards have DPI
> displays.
Oops right, those are DPI.
Regards,
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-14 14:09 ` Tony Lindgren
@ 2013-12-16 7:24 ` Tomi Valkeinen
-1 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-16 7:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 2946 bytes --]
On 2013-12-14 16:09, Tony Lindgren wrote:
>> Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
>> not a fix, just a cleanup.
>
> Hmm OK sorry looks like I removed some non-legacy mux framework code
> by accident. The omap_mux_* parts clearly are dead code for omap4 as
> it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
> using omap_mux_* functions.
>
> Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
> seems to be omap4_tpd12s015_mux_pads(), right?
Yes. I tested the below patch on 4430SDP, both DSI and HDMI works.
Tomi
From cc38cdb5c77c82f526ebce855711a6b4d4c51180 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon, 16 Dec 2013 09:14:48 +0200
Subject: [PATCH] Revert "ARM: OMAP2+: Remove legacy mux code for display.c"
Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove
legacy mux code for display.c) removed non-DT DSI and HDMI pinmuxing.
However, DSI pinmuxing is still needed, and removing that caused DSI
displays not to work.
This reverts the DSI parts of the commit.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/display.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 58347bb874a0..4cf165502b35 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -101,13 +101,51 @@ static const struct omap_dss_hwmod_data omap4_dss_hwmod_data[] __initconst = {
{ "dss_hdmi", "omapdss_hdmi", -1 },
};
+static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
+{
+ u32 enable_mask, enable_shift;
+ u32 pipd_mask, pipd_shift;
+ u32 reg;
+
+ if (dsi_id == 0) {
+ enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
+ enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
+ pipd_mask = OMAP4_DSI1_PIPD_MASK;
+ pipd_shift = OMAP4_DSI1_PIPD_SHIFT;
+ } else if (dsi_id == 1) {
+ enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
+ enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
+ pipd_mask = OMAP4_DSI2_PIPD_MASK;
+ pipd_shift = OMAP4_DSI2_PIPD_SHIFT;
+ } else {
+ return -ENODEV;
+ }
+
+ reg = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
+
+ reg &= ~enable_mask;
+ reg &= ~pipd_mask;
+
+ reg |= (lanes << enable_shift) & enable_mask;
+ reg |= (lanes << pipd_shift) & pipd_mask;
+
+ omap4_ctrl_pad_writel(reg, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
+ if (cpu_is_omap44xx())
+ return omap4_dsi_mux_pads(dsi_id, lane_mask);
+
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
+ if (cpu_is_omap44xx())
+ omap4_dsi_mux_pads(dsi_id, 0);
}
static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
--
1.8.3.2
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-16 7:24 ` Tomi Valkeinen
0 siblings, 0 replies; 183+ messages in thread
From: Tomi Valkeinen @ 2013-12-16 7:24 UTC (permalink / raw)
To: Tony Lindgren
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
[-- Attachment #1: Type: text/plain, Size: 2946 bytes --]
On 2013-12-14 16:09, Tony Lindgren wrote:
>> Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
>> not a fix, just a cleanup.
>
> Hmm OK sorry looks like I removed some non-legacy mux framework code
> by accident. The omap_mux_* parts clearly are dead code for omap4 as
> it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
> using omap_mux_* functions.
>
> Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
> seems to be omap4_tpd12s015_mux_pads(), right?
Yes. I tested the below patch on 4430SDP, both DSI and HDMI works.
Tomi
From cc38cdb5c77c82f526ebce855711a6b4d4c51180 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen <tomi.valkeinen@ti.com>
Date: Mon, 16 Dec 2013 09:14:48 +0200
Subject: [PATCH] Revert "ARM: OMAP2+: Remove legacy mux code for display.c"
Commit e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 (ARM: OMAP2+: Remove
legacy mux code for display.c) removed non-DT DSI and HDMI pinmuxing.
However, DSI pinmuxing is still needed, and removing that caused DSI
displays not to work.
This reverts the DSI parts of the commit.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
---
arch/arm/mach-omap2/display.c | 38 ++++++++++++++++++++++++++++++++++++++
1 file changed, 38 insertions(+)
diff --git a/arch/arm/mach-omap2/display.c b/arch/arm/mach-omap2/display.c
index 58347bb874a0..4cf165502b35 100644
--- a/arch/arm/mach-omap2/display.c
+++ b/arch/arm/mach-omap2/display.c
@@ -101,13 +101,51 @@ static const struct omap_dss_hwmod_data omap4_dss_hwmod_data[] __initconst = {
{ "dss_hdmi", "omapdss_hdmi", -1 },
};
+static int omap4_dsi_mux_pads(int dsi_id, unsigned lanes)
+{
+ u32 enable_mask, enable_shift;
+ u32 pipd_mask, pipd_shift;
+ u32 reg;
+
+ if (dsi_id == 0) {
+ enable_mask = OMAP4_DSI1_LANEENABLE_MASK;
+ enable_shift = OMAP4_DSI1_LANEENABLE_SHIFT;
+ pipd_mask = OMAP4_DSI1_PIPD_MASK;
+ pipd_shift = OMAP4_DSI1_PIPD_SHIFT;
+ } else if (dsi_id == 1) {
+ enable_mask = OMAP4_DSI2_LANEENABLE_MASK;
+ enable_shift = OMAP4_DSI2_LANEENABLE_SHIFT;
+ pipd_mask = OMAP4_DSI2_PIPD_MASK;
+ pipd_shift = OMAP4_DSI2_PIPD_SHIFT;
+ } else {
+ return -ENODEV;
+ }
+
+ reg = omap4_ctrl_pad_readl(OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
+
+ reg &= ~enable_mask;
+ reg &= ~pipd_mask;
+
+ reg |= (lanes << enable_shift) & enable_mask;
+ reg |= (lanes << pipd_shift) & pipd_mask;
+
+ omap4_ctrl_pad_writel(reg, OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY);
+
+ return 0;
+}
+
static int omap_dsi_enable_pads(int dsi_id, unsigned lane_mask)
{
+ if (cpu_is_omap44xx())
+ return omap4_dsi_mux_pads(dsi_id, lane_mask);
+
return 0;
}
static void omap_dsi_disable_pads(int dsi_id, unsigned lane_mask)
{
+ if (cpu_is_omap44xx())
+ omap4_dsi_mux_pads(dsi_id, 0);
}
static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)
--
1.8.3.2
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
^ permalink raw reply related [flat|nested] 183+ messages in thread* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
2013-12-16 7:24 ` Tomi Valkeinen
@ 2013-12-18 0:30 ` Tony Lindgren
-1 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-18 0:30 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131215 23:26]:
> On 2013-12-14 16:09, Tony Lindgren wrote:
>
> >> Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
> >> not a fix, just a cleanup.
> >
> > Hmm OK sorry looks like I removed some non-legacy mux framework code
> > by accident. The omap_mux_* parts clearly are dead code for omap4 as
> > it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
> > using omap_mux_* functions.
> >
> > Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
> > seems to be omap4_tpd12s015_mux_pads(), right?
>
> Yes. I tested the below patch on 4430SDP, both DSI and HDMI works.
OK thanks applying for the -rc cycle.
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread
* Re: [PATCH 00/26] OMAPDSS: DT support (Christmas edition)
@ 2013-12-18 0:30 ` Tony Lindgren
0 siblings, 0 replies; 183+ messages in thread
From: Tony Lindgren @ 2013-12-18 0:30 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, linux-omap, linux-fbdev, devicetree,
Archit Taneja, Darren Etheridge, Stefan Roese, Sebastian Reichel,
Robert Nelson, Dr . H . Nikolaus Schaller, Marek Belisko
* Tomi Valkeinen <tomi.valkeinen@ti.com> [131215 23:26]:
> On 2013-12-14 16:09, Tony Lindgren wrote:
>
> >> Why was e30b06f4d5f000c31a7747a7e7ada78a5fd419a1 merged into -rc2? It's
> >> not a fix, just a cleanup.
> >
> > Hmm OK sorry looks like I removed some non-legacy mux framework code
> > by accident. The omap_mux_* parts clearly are dead code for omap4 as
> > it's been DT only since v3.10, but the omap4_dsi_mux_pads() is not
> > using omap_mux_* functions.
> >
> > Yes, let's revert e30b06f4d5f0 except for the dead code parts, which
> > seems to be omap4_tpd12s015_mux_pads(), right?
>
> Yes. I tested the below patch on 4430SDP, both DSI and HDMI works.
OK thanks applying for the -rc cycle.
Tony
^ permalink raw reply [flat|nested] 183+ messages in thread