From: Tomi Valkeinen <hidden> Date: 2013-03-27 08:45:07
Hi,
This is an RFC for OMAPDSS DT support. I've only added support for a few boards
and a few DSS outputs, but they should give quite a good range of different use
cases. If these work well, I think the rest of the outputs and panels will be
ok too.
The purpose of this series is to get comments about the dts changes. There are
still work to be done, like adding DT binding documentation.
Some notes:
* DSS Submodules
The DSS submodules are children of the dss_core node. This is done because the
submodules require the dss_core to be alive and initialized to work, even if
the submodules are not really behind dss_core. Having the submodules as
children will make runtime PM automatically handle the dependency to dss_core.
I think usually a node being a child means that it's on the parent's bus, which
is not the case here. I'm not sure if that's an issue or not.
* ti,dsi-module-id
There's a ti,dsi-module-id property in the dsi node. The reason for this
module-id property is that we have muxes in the dss_core that route clocks
to/from a particular DSI module. So we need some way to index the DSI modules.
Another option would be to have a list of DSI modules (phandles) in the
dss_core. Both options feel a bit wrong to me, but I went for the module-id
approach as that is already used when not using DT.
* Display chains
Currently omapdss driver can handle only one display device connected to one
OMAP SoC output. This is not right in many cases, as there may be multiple
display devices in a chain, like first an external encoder and then a panel.
However, I tried to model this right in the dts.
So, for example, for Panda HDMI output we have the following display "entities"
in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
connector. These are connected using the "video-source" property, which tells
where the component in question gets its video data.
You could ask why there's a separate node for HDMI connector. It's true it's
not really a proper device, but we need some kind of terminator for the display
chains. For HDMI we could as well have an embedded solution, having a chain
like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
marks the end of the chain, and acts as a panel in a sense.
* DSI lanes
The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
connected to the DSI panel. I'm not sure if the panel data is the proper place
for this, or should the data be separately for the OMAP DSI node.
Tomi
Tomi Valkeinen (14):
ARM: OMAP: remove DSS DT hack
ARM: OMAP2+: add omapdss_init_of()
OMAPDSS: Add DT support to DSS, DISPC, DPI
OMAPDSS: Add DT support to DSI
OMAPDSS: Add DT support to HDMI
OMAPDSS: Taal: Add DT support
OMAPDSS: TFP410: Add DT support
OMAPDSS: panel-generic-dpi: add DT support
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 TFP410
arch/arm/boot/dts/omap3-beagle.dts | 20 +++++
arch/arm/boot/dts/omap3-tobi.dts | 13 ++++
arch/arm/boot/dts/omap3.dtsi | 49 ++++++++++++
arch/arm/boot/dts/omap4-panda.dts | 44 +++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 64 ++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 71 +++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 9 +--
arch/arm/mach-omap2/common.h | 2 +
arch/arm/mach-omap2/display.c | 34 +++++++++
arch/arm/mach-omap2/dss-common.c | 24 ------
arch/arm/mach-omap2/dss-common.h | 2 -
drivers/video/omap2/displays/panel-generic-dpi.c | 47 ++++++++++++
drivers/video/omap2/displays/panel-taal.c | 89 ++++++++++++++++++++++
drivers/video/omap2/displays/panel-tfp410.c | 71 +++++++++++++++++
drivers/video/omap2/dss/dispc.c | 7 ++
drivers/video/omap2/dss/dpi.c | 8 ++
drivers/video/omap2/dss/dsi.c | 24 +++++-
drivers/video/omap2/dss/dss.c | 7 ++
drivers/video/omap2/dss/hdmi.c | 7 ++
drivers/video/omap2/dss/hdmi_panel.c | 86 ++++++++++++++++++++-
20 files changed, 641 insertions(+), 37 deletions(-)
--
1.7.10.4
From: Tomi Valkeinen <hidden> Date: 2013-03-27 08:45:08
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 <redacted>
---
arch/arm/mach-omap2/board-generic.c | 8 --------
arch/arm/mach-omap2/dss-common.c | 24 ------------------------
arch/arm/mach-omap2/dss-common.h | 2 --
3 files changed, 34 deletions(-)
@@ -242,20 +235,3 @@ void __init omap_4430sdp_display_init(void)omap_mux_init_gpio(HDMI_GPIO_CT_CP_HPD,OMAP_PIN_OUTPUT);omap_mux_init_gpio(HDMI_GPIO_HPD,OMAP_PIN_INPUT_PULLDOWN);}--void__initomap_4430sdp_display_init_of(void)-{-intr;--/* Enable LCD2 by default (instead of Pico DLP) */-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__);--sdp4430_picodlp_init();-omap_display_init(&sdp4430_dss_data);-platform_device_register(&sdp4430_hdmi_device);-platform_device_register(&sdp4430_lcd1_device);-platform_device_register(&sdp4430_lcd2_device);-}
From: Tomi Valkeinen <hidden> Date: 2013-03-27 08:45:09
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 <redacted>
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/display.c | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+)
@@ -564,3 +566,35 @@ int omap_dss_reset(struct omap_hwmod *oh)returnr;}++int__initomapdss_init_of(void)+{+intr;+enumomapdss_versionver;++staticstructomap_dss_board_infoboard_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");+returnr;+}++return0;+}
From: Tomi Valkeinen <hidden> Date: 2013-03-27 08:45:10
Add the code to make DSS, DISPC and DPI drivers work with device tree on
OMAP3 and OMAP4. The only change is adding the of_match_tables.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 +++++++
drivers/video/omap2/dss/dpi.c | 8 ++++++++
drivers/video/omap2/dss/dss.c | 7 +++++++
3 files changed, 22 insertions(+)
From: Tomi Valkeinen <hidden> Date: 2013-03-27 08:45:11
Add the code to make the DSI driver work with device tree on OMAP3 and
OMAP4. The of_match_table is added, and also a bit hacky
"ti,dsi-module-id" DT property, which tells the DSI ID number.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dsi.c | 24 +++++++++++++++++++++++-
1 file changed, 23 insertions(+), 1 deletion(-)
From: Tomi Valkeinen <hidden> Date: 2013-03-27 08:45:12
Add the code to make the HDMI driver work with device tree.
The OMAP SoC HDMI (hdmi.c) change is simple, just add of_match_table.
The hdmi_panel.c is a bit more complex. We model both the TPD12S015 chip
and the HDMI connector, and handle both in the same driver. In the
future those should be separate drivers.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/hdmi.c | 7 +++
drivers/video/omap2/dss/hdmi_panel.c | 86 +++++++++++++++++++++++++++++++++-
2 files changed, 91 insertions(+), 2 deletions(-)
@@ -27,12 +27,16 @@#include<video/omapdss.h>#include<linux/slab.h>#include<linux/platform_device.h>+#include<linux/of.h>+#include<linux/of_gpio.h>#include"dss.h"staticstruct{structomap_dss_devicedssdev;+structomap_dss_hdmi_datapdata;+/* This protects the panel ops, mainly when accessing the HDMI IP. */structmutexlock;#if defined(CONFIG_OMAP4_DSS_HDMI_AUDIO)
@@ -43,6 +47,62 @@ static struct {staticstructomap_dss_driverhdmi_driver;+staticinthdmi_panel_probe_pdata(structplatform_device*pdev)+{+conststructomap_dss_hdmi_data*pdata=dev_get_platdata(&pdev->dev);++hdmi.pdata=*pdata;++return0;+}++staticinthdmi_parse_tpd12s015_of(structdevice_node*node,+structomap_dss_hdmi_data*pdata)+{+intgpio;++gpio=of_get_gpio(node,0);/* CT CP HPD */+if(!gpio_is_valid(gpio))+return-EINVAL;+pdata->ct_cp_hpd_gpio=gpio;++gpio=of_get_gpio(node,1);/* LS OE */+if(!gpio_is_valid(gpio))+return-EINVAL;+pdata->ls_oe_gpio=gpio;++gpio=of_get_gpio(node,2);/* HPD */+if(!gpio_is_valid(gpio))+return-EINVAL;+pdata->hpd_gpio=gpio;++return0;+}++staticinthdmi_panel_probe_of(structplatform_device*pdev)+{+structdevice_node*node=pdev->dev.of_node;+structdevice_node*src_node;+intr;++/*+*Wedon'thavearealdriverfortheTPD12S015chip,butitis+*modeledrightintheDTdata.SoweneedtoparsetheTPD12S015data+*here.+*/+src_node=of_parse_phandle(node,"video-source",0);+if(!src_node){+dev_err(&pdev->dev,"failed to parse video source\n");+return-ENODEV;+}++r=hdmi_parse_tpd12s015_of(src_node,&hdmi.pdata);+if(r)+returnr;++return0;+}+staticinthdmi_panel_probe(structplatform_device*pdev){/* Initialize default timings to VGA in DVI mode */
@@ -63,12 +123,28 @@ static int hdmi_panel_probe(struct platform_device *pdev).interlace=false,};-structomap_dss_hdmi_data*pdata=dev_get_platdata(&pdev->dev);structomap_dss_device*dssdev=&hdmi.dssdev;intr;DSSDBG("ENTER hdmi_panel_probe\n");+if(dev_get_platdata(&pdev->dev)){+r=hdmi_panel_probe_pdata(pdev);+if(r){+dev_err(&pdev->dev,"failed to read platform data\n");+returnr;+}+}elseif(pdev->dev.of_node){+r=hdmi_panel_probe_of(pdev);+if(r){+dev_err(&pdev->dev,"failed to parse OF data\n");+returnr;+}+}else{+return-ENODEV;+}++dssdev->panel.timings=default_timings;dssdev->driver=&hdmi_driver;dssdev->name="hdmi";
@@ -788,6 +790,81 @@ static int taal_probe_pdata(struct platform_device *pdev)return0;}+staticinttaal_probe_of(structplatform_device*pdev)+{+structdevice_node*node=pdev->dev.of_node;+structtaal_data*td=dev_get_drvdata(&pdev->dev);+structproperty*prop;+structdevice_node*src_node;+u32lane_arr[10];+intgpio,len,num_pins;+intr,i;++src_node=of_parse_phandle(node,"video-source",0);+if(!src_node){+dev_err(&pdev->dev,"failed to parse video source\n");+return-ENODEV;+}++td->src=omap_dss_find_output_by_node(src_node);+if(!td->src){+dev_err(&pdev->dev,"failed to find video source\n");+return-ENODEV;+}++gpio=of_get_gpio(node,0);++if(gpio_is_valid(gpio)){+td->reset_gpio=gpio;+}else{+dev_err(&pdev->dev,"failed to parse reset gpio\n");+returngpio;+}++if(of_gpio_count(node)>1){+gpio=of_get_gpio(node,1);++if(gpio_is_valid(gpio)){+td->ext_te_gpio=gpio;+}elseif(gpio=-ENOENT){+td->ext_te_gpio=-1;+}else{+dev_err(&pdev->dev,"failed to parse TE gpio\n");+returngpio;+}+}else{+td->ext_te_gpio=-1;+}++prop=of_find_property(node,"lanes",&len);+if(prop=NULL){+dev_err(&pdev->dev,"failed to find lane data\n");+return-EINVAL;+}++num_pins=len/sizeof(u32);++if(num_pins<4||num_pins%2!=0+||num_pins>ARRAY_SIZE(lane_arr)){+dev_err(&pdev->dev,"bad number of lanes\n");+return-EINVAL;+}++r=of_property_read_u32_array(node,"lanes",lane_arr,num_pins);+if(r){+dev_err(&pdev->dev,"failed to read lane data\n");+returnr;+}++td->pin_config.num_pins=num_pins;+for(i=0;i<num_pins;++i)+td->pin_config.pins[i]=(int)lane_arr[i];++td->dssdev.name=node->name;++return0;+}+staticinttaal_probe(structplatform_device*pdev){conststructnokia_dsi_panel_data*pdata=dev_get_platdata(&pdev->dev);
@@ -813,6 +890,12 @@ static int taal_probe(struct platform_device *pdev)dev_err(&pdev->dev,"failed to read platform data\n");returnr;}+}elseif(pdev->dev.of_node){+r=taal_probe_of(pdev);+if(r){+dev_err(&pdev->dev,"failed to parse OF data\n");+returnr;+}}else{return-ENODEV;}
From: Tomi Valkeinen <hidden> Date: 2013-03-27 08:45:14
In the DT data we model the TFP410 chip and the DVI connector. For the
moment we have only 1 driver to handle those both.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/displays/panel-tfp410.c | 71 +++++++++++++++++++++++++++
1 file changed, 71 insertions(+)
@@ -112,6 +114,63 @@ static int tfp410_probe_pdata(struct platform_device *pdev)return0;}+staticinttfp410_probe_of(structplatform_device*pdev)+{+structdevice_node*node=pdev->dev.of_node;+structpanel_drv_data*ddata=dev_get_drvdata(&pdev->dev);+structdevice_node*adapter_node;+structi2c_adapter*adapter;+intr,gpio,datalines;++ddata->name=node->name;++node=of_parse_phandle(node,"video-source",0);+if(!node){+dev_err(&pdev->dev,"failed to parse video source\n");+return-ENODEV;+}++gpio=of_get_gpio(node,0);++if(gpio_is_valid(gpio)){+r=devm_gpio_request_one(&pdev->dev,gpio,+GPIOF_OUT_INIT_LOW,"tfp410 pd");+if(r){+dev_err(&pdev->dev,"Failed to request PD GPIO %d\n",+gpio);+returnr;+}++ddata->pd_gpio=gpio;+}elseif(gpio=-ENOENT){+ddata->pd_gpio=-1;+}else{+dev_err(&pdev->dev,"failed to parse PD gpio\n");+returngpio;+}++r=of_property_read_u32(node,"data-lines",&datalines);+if(r){+dev_err(&pdev->dev,"failed to parse datalines");+returnr;+}++ddata->data_lines=datalines;++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");+return-EINVAL;+}++ddata->i2c_adapter=adapter;+}++return0;+}+staticinttfp410_probe(structplatform_device*pdev){structtfp410_platform_data*pdata=dev_get_platdata(&pdev->dev);
@@ -131,6 +190,10 @@ static int tfp410_probe(struct platform_device *pdev)r=tfp410_probe_pdata(pdev);if(r)returnr;+}elseif(pdev->dev.of_node){+r=tfp410_probe_of(pdev);+if(r)+returnr;}else{return-ENODEV;}
Hi Tomi,
On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
quoted hunk
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 <redacted>
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/display.c | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+)
Mmm, you should not have to call that explicitly. It looks like a hack
to me. Everything in theory should be initialized during
of_platform_populate / driver probe.
All that code should disappear with DT. hacking a platform device with
pdata is the old way of initializing a device.
I know that you do have some omap_pm callback, but you'd better get rid
of them in case of DT boot.
Fixing that is a generic issue, and as soon as a solution will be done
to handle these specific hooks, every drivers will be able to use that.
quoted hunk
+ };++ 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;
Hi Tomi,
On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
Hi,
This is an RFC for OMAPDSS DT support. I've only added support for a few boards
and a few DSS outputs, but they should give quite a good range of different use
cases. If these work well, I think the rest of the outputs and panels will be
ok too.
The purpose of this series is to get comments about the dts changes. There are
still work to be done, like adding DT binding documentation.
Some notes:
* DSS Submodules
The DSS submodules are children of the dss_core node. This is done because the
submodules require the dss_core to be alive and initialized to work, even if
the submodules are not really behind dss_core. Having the submodules as
children will make runtime PM automatically handle the dependency to dss_core.
I think usually a node being a child means that it's on the parent's bus, which
is not the case here. I'm not sure if that's an issue or not.
FWIW, there is a L4_DSS interconnect. It is used internally to connect
all the submodules to the DSS L3 port. So this representation is
perfectly valid and does represent accurately the HW.
Regards,
Benoit
* ti,dsi-module-id
There's a ti,dsi-module-id property in the dsi node. The reason for this
module-id property is that we have muxes in the dss_core that route clocks
to/from a particular DSI module. So we need some way to index the DSI modules.
Another option would be to have a list of DSI modules (phandles) in the
dss_core. Both options feel a bit wrong to me, but I went for the module-id
approach as that is already used when not using DT.
* Display chains
Currently omapdss driver can handle only one display device connected to one
OMAP SoC output. This is not right in many cases, as there may be multiple
display devices in a chain, like first an external encoder and then a panel.
However, I tried to model this right in the dts.
So, for example, for Panda HDMI output we have the following display "entities"
in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
connector. These are connected using the "video-source" property, which tells
where the component in question gets its video data.
You could ask why there's a separate node for HDMI connector. It's true it's
not really a proper device, but we need some kind of terminator for the display
chains. For HDMI we could as well have an embedded solution, having a chain
like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
marks the end of the chain, and acts as a panel in a sense.
* DSI lanes
The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
connected to the DSI panel. I'm not sure if the panel data is the proper place
for this, or should the data be separately for the OMAP DSI node.
Tomi
Tomi Valkeinen (14):
ARM: OMAP: remove DSS DT hack
ARM: OMAP2+: add omapdss_init_of()
OMAPDSS: Add DT support to DSS, DISPC, DPI
OMAPDSS: Add DT support to DSI
OMAPDSS: Add DT support to HDMI
OMAPDSS: Taal: Add DT support
OMAPDSS: TFP410: Add DT support
OMAPDSS: panel-generic-dpi: add DT support
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 TFP410
arch/arm/boot/dts/omap3-beagle.dts | 20 +++++
arch/arm/boot/dts/omap3-tobi.dts | 13 ++++
arch/arm/boot/dts/omap3.dtsi | 49 ++++++++++++
arch/arm/boot/dts/omap4-panda.dts | 44 +++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 64 ++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 71 +++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 9 +--
arch/arm/mach-omap2/common.h | 2 +
arch/arm/mach-omap2/display.c | 34 +++++++++
arch/arm/mach-omap2/dss-common.c | 24 ------
arch/arm/mach-omap2/dss-common.h | 2 -
drivers/video/omap2/displays/panel-generic-dpi.c | 47 ++++++++++++
drivers/video/omap2/displays/panel-taal.c | 89 ++++++++++++++++++++++
drivers/video/omap2/displays/panel-tfp410.c | 71 +++++++++++++++++
drivers/video/omap2/dss/dispc.c | 7 ++
drivers/video/omap2/dss/dpi.c | 8 ++
drivers/video/omap2/dss/dsi.c | 24 +++++-
drivers/video/omap2/dss/dss.c | 7 ++
drivers/video/omap2/dss/hdmi.c | 7 ++
drivers/video/omap2/dss/hdmi_panel.c | 86 ++++++++++++++++++++-
20 files changed, 641 insertions(+), 37 deletions(-)
+ mturquette and Rajendra
On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
...
* ti,dsi-module-id
There's a ti,dsi-module-id property in the dsi node. The reason for this
module-id property is that we have muxes in the dss_core that route clocks
to/from a particular DSI module. So we need some way to index the DSI modules.
Another option would be to have a list of DSI modules (phandles) in the
dss_core. Both options feel a bit wrong to me, but I went for the module-id
approach as that is already used when not using DT.
That's not a very nice representation. Ideally you should expose 1 clock
node per DSI node, and enabling one will select the proper mux for you.
Regards,
Benoit
* Display chains
Currently omapdss driver can handle only one display device connected to one
OMAP SoC output. This is not right in many cases, as there may be multiple
display devices in a chain, like first an external encoder and then a panel.
However, I tried to model this right in the dts.
So, for example, for Panda HDMI output we have the following display "entities"
in a chain: OMAP SoC HDMI output, TPD12S015 ESD/level shifter, and HDMI
connector. These are connected using the "video-source" property, which tells
where the component in question gets its video data.
You could ask why there's a separate node for HDMI connector. It's true it's
not really a proper device, but we need some kind of terminator for the display
chains. For HDMI we could as well have an embedded solution, having a chain
like this: SoC HDMI, TPD12S015, hardwired embedded HDMI panel. So the connector
marks the end of the chain, and acts as a panel in a sense.
* DSI lanes
The DSI panels contain "lanes" property, which tells how the SoCs DSI pins are
connected to the DSI panel. I'm not sure if the panel data is the proper place
for this, or should the data be separately for the OMAP DSI node.
Tomi
Tomi Valkeinen (14):
ARM: OMAP: remove DSS DT hack
ARM: OMAP2+: add omapdss_init_of()
OMAPDSS: Add DT support to DSS, DISPC, DPI
OMAPDSS: Add DT support to DSI
OMAPDSS: Add DT support to HDMI
OMAPDSS: Taal: Add DT support
OMAPDSS: TFP410: Add DT support
OMAPDSS: panel-generic-dpi: add DT support
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 TFP410
arch/arm/boot/dts/omap3-beagle.dts | 20 +++++
arch/arm/boot/dts/omap3-tobi.dts | 13 ++++
arch/arm/boot/dts/omap3.dtsi | 49 ++++++++++++
arch/arm/boot/dts/omap4-panda.dts | 44 +++++++++++
arch/arm/boot/dts/omap4-sdp.dts | 64 ++++++++++++++++
arch/arm/boot/dts/omap4.dtsi | 71 +++++++++++++++++
arch/arm/mach-omap2/board-generic.c | 9 +--
arch/arm/mach-omap2/common.h | 2 +
arch/arm/mach-omap2/display.c | 34 +++++++++
arch/arm/mach-omap2/dss-common.c | 24 ------
arch/arm/mach-omap2/dss-common.h | 2 -
drivers/video/omap2/displays/panel-generic-dpi.c | 47 ++++++++++++
drivers/video/omap2/displays/panel-taal.c | 89 ++++++++++++++++++++++
drivers/video/omap2/displays/panel-tfp410.c | 71 +++++++++++++++++
drivers/video/omap2/dss/dispc.c | 7 ++
drivers/video/omap2/dss/dpi.c | 8 ++
drivers/video/omap2/dss/dsi.c | 24 +++++-
drivers/video/omap2/dss/dss.c | 7 ++
drivers/video/omap2/dss/hdmi.c | 7 ++
drivers/video/omap2/dss/hdmi_panel.c | 86 ++++++++++++++++++++-
20 files changed, 641 insertions(+), 37 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2013-03-27 10:09:12
On 2013-03-27 11:28, Benoit Cousson wrote:
Hi Tomi,
Hi Benoit. Thanks for your comments!
On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
quoted
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 <redacted>
---
arch/arm/mach-omap2/board-generic.c | 1 +
arch/arm/mach-omap2/common.h | 2 ++
arch/arm/mach-omap2/display.c | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 37 insertions(+)
Mmm, you should not have to call that explicitly. It looks like a hack
to me. Everything in theory should be initialized during
of_platform_populate / driver probe.
All the "real" devices are initialized properly. However, we still have
a "virtual" omapdss device, which does not represent a particular HW
block as such, and is not represented in the DT data. It's a legacy
thing, and slowly on its way out.
However, it still helps us to pass the platform callbacks via platform
data even in DT call, so we have this (hacky) omapdss_init_of() call.
And we also pass the OMAP revision information via the platform data, as
we need to know the DSS HW version. The only way to get that is to know
the OMAP version and revision. If we would set the DSS HW version
information into DT data, we could need separate dts files for each OMAP
revision.
Pads config should be handle by pinmux framework is possible. Otherwise
a dedicated driver will be required.
Hmm. These functions touch the OMAP4_CTRL_MODULE_PAD_CORE_CONTROL_DSIPHY
(CONTROL_DSIPHY in the TRM) register. It's not a normal padconfig thing
(like, selecting between GPIO and some other function).
Can they be handled by the pinmux framework? I'm not familiar with it.
What do you mean with dedicated driver? Dedicated pinmux driver, or
something else?
All that code should disappear with DT. hacking a platform device with
pdata is the old way of initializing a device.
I know that you do have some omap_pm callback, but you'd better get rid
of them in case of DT boot.
Fixing that is a generic issue, and as soon as a solution will be done
to handle these specific hooks, every drivers will be able to use that.
So, what you're saying is that this is not the correct way, but there's
no other way to handle it currently? If so, yes, I know that, but, well,
there's no other way to handle it currently.
I could leave them out, but in that case when booting with DT there must
be no DSS context loss, and OPP must be at OPP100 all the time.
Tomi
From: Tomi Valkeinen <hidden> Date: 2013-03-27 10:15:44
On 2013-03-27 11:30, Benoit Cousson wrote:
Hi Tomi,
On 03/27/2013 09:45 AM, Tomi Valkeinen wrote:
quoted
Hi,
This is an RFC for OMAPDSS DT support. I've only added support for a few boards
and a few DSS outputs, but they should give quite a good range of different use
cases. If these work well, I think the rest of the outputs and panels will be
ok too.
The purpose of this series is to get comments about the dts changes. There are
still work to be done, like adding DT binding documentation.
Some notes:
* DSS Submodules
The DSS submodules are children of the dss_core node. This is done because the
submodules require the dss_core to be alive and initialized to work, even if
the submodules are not really behind dss_core. Having the submodules as
children will make runtime PM automatically handle the dependency to dss_core.
I think usually a node being a child means that it's on the parent's bus, which
is not the case here. I'm not sure if that's an issue or not.
FWIW, there is a L4_DSS interconnect. It is used internally to connect
all the submodules to the DSS L3 port. So this representation is
perfectly valid and does represent accurately the HW.
Ah, yes, I can see it mentioned in the OMAP4430 Block Diagram figure in
the TRM. No other mentions, though, I guess it's not really relevant =).
But good to know that the DT representation is actually correct.
Tomi