From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:33
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 | 2 +
arch/arm/mach-omap2/common.h | 2 +
arch/arm/mach-omap2/display.c | 76 +++++++++++++++++++++++++++++++++++++
3 files changed, 80 insertions(+)
@@ -552,3 +554,77 @@ int omap_dss_reset(struct omap_hwmod *oh)returnr;}++int__initomapdss_init_of(void)+{+intr;+enumomapdss_versionver;+structdevice_node*node;++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,+};++/* only create dss helper devices if dss is enabled in the .dts */++node=of_find_compatible_node(NULL,NULL,"ti,omap2-dss");+if(!node)+node=of_find_compatible_node(NULL,NULL,"ti,omap3-dss");+if(!node)+node=of_find_compatible_node(NULL,NULL,"ti,omap4-dss");+if(!node)+return0;++if(!of_device_is_available(node))+return0;++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;+}++/* create DRM device */+r=omap_init_drm();+if(r<0){+pr_err("Unable to register omapdrm device\n");+returnr;+}++/* create vrfb device */+r=omap_init_vrfb();+if(r<0){+pr_err("Unable to register omapvrfb device\n");+returnr;+}++/* create FB device */+r=omap_init_fb();+if(r<0){+pr_err("Unable to register omapfb device\n");+returnr;+}++/* create V4L2 display device */+r=omap_init_vout();+if(r<0){+pr_err("Unable to register omap_vout device\n");+returnr;+}++return0;+}
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:34
As there is no common panel framework in the kernel, we have OMAP
specific panel drivers. However, the DT data should be generic. This
brings the issue that some other platform could use the same panels, and
would need to create a driver with the same 'compatible' string as the
OMAP driver.
In the long run, we have to get a common panel framework. For the time
being, this patch solves the issue:
At early boot time, we go through the DT nodes looking for the panels
the kernel supports for OMAP. For each found node, the 'compatible'
string is prepended with "omapdss,", i.e. "sony,acx565akm" becomes
"omapdss,sony,acx565akm". The OMAP display drivers all have "omapdss,"
at the beginning of their compatible field.
This allows us to have generic DT data, but OMAP specific display
drivers.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/board-generic.c | 2 ++
arch/arm/mach-omap2/common.h | 1 +
arch/arm/mach-omap2/display.c | 56 +++++++++++++++++++++++++++++++++++++
3 files changed, 59 insertions(+)
@@ -555,6 +556,61 @@ int omap_dss_reset(struct omap_hwmod *oh)returnr;}+/* list of 'compatible' nodes to convert to omapdss specific */+staticconstchar*constdss_compat_conv_list[]__initconst={+"composite-connector",+"dvi-connector",+"hdmi-connector",+"panel-dpi",+"panel-dsi-cm",+"sony,acx565akm",+"svideo-connector",+"ti,tfp410",+"ti,tpd12s015",+};++/* prepend compatible string with "omapdss," */+static__initvoidomapdss_omapify_node(structdevice_node*node,+constchar*compat)+{+char*new_compat;+structproperty*prop;++new_compat=kasprintf(GFP_KERNEL,"omapdss,%s",compat);++prop=kzalloc(sizeof(*prop),GFP_KERNEL);+prop->name="compatible";+prop->value=new_compat;+prop->length=strlen(new_compat)+1;++of_update_property(node,prop);+}++/*+*Asomapdsspaneldriversareomapdssspecific,butwewanttodefinethe+*DT-dataingenericmanner,weconvertthecompatiblestringsofthepanel+*nodesfrom"panel-foo"to"omapdss,panel-foo".Thiswaywecanhaveboth+*correctDTdataandomapdssspecificdrivers.+*+*Whenwegetgenericpaneldriverstothekernel,thiswillberemoved.+*/+void__initomapdss_early_init_of(void)+{+inti;++for(i=0;i<ARRAY_SIZE(dss_compat_conv_list);++i){+constchar*compat=dss_compat_conv_list[i];+structdevice_node*node=NULL;++while((node=of_find_compatible_node(node,NULL,compat))){+if(!of_device_is_available(node))+continue;++omapdss_omapify_node(node,compat);+}+}+}+int__initomapdss_init_of(void){intr;
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:35
Add support to get the label (i.e. a "nickname") for a display from the
DT data. If there is no label defined, use the display's alias (e.g.
'display0') as a name.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/display.c | 9 +++++++++
1 file changed, 9 insertions(+)
@@ -137,6 +138,14 @@ int omapdss_register_display(struct omap_dss_device *dssdev)snprintf(dssdev->alias,sizeof(dssdev->alias),"display%d",disp_num_counter++);+/* Use 'label' property for name, if it exists */+if(dssdev->dev->of_node)+of_property_read_string(dssdev->dev->of_node,"label",+&dssdev->name);++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)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:37
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 <redacted>
---
drivers/video/omap2/omapfb/omapfb-main.c | 46 ++++++++++++++++++++------------
1 file changed, 29 insertions(+), 17 deletions(-)
@@ -2417,6 +2417,34 @@ static int omapfb_init_connections(struct omapfb2_device *fbdev,return0;}+staticstructomap_dss_device*+omapfb_find_default_display(structomapfb2_device*fbdev)+{+constchar*def_name;+inti;++/* 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){+structomap_dss_device*dssdev;++dssdev=fbdev->displays[i].dssdev;++if(dssdev->name&&strcmp(def_name,dssdev->name)=0)+returndssdev;+}++/* def_name given but not found */+returnNULL;+}++/* return the first display we have in the list */+returnfbdev->displays[0].dssdev;+}+staticintomapfb_probe(structplatform_device*pdev){structomapfb2_device*fbdev=NULL;
@@ -2494,23 +2522,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){-structomap_dss_device*dssdev;-constchar*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;
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:38
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 <redacted>
---
drivers/video/omap2/omapfb/omapfb-main.c | 23 ++++++++++++++++++++++-
1 file changed, 22 insertions(+), 1 deletion(-)
@@ -2423,7 +2423,10 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)constchar*def_name;inti;-/* search with the display name from the user or the board file */+/*+*Searchwiththedisplaynamefromtheuserortheboardfile,+*comparingtodisplaynamesandaliases+*/def_name=omapdss_get_default_display_name();
@@ -2435,12 +2438,30 @@ omapfb_find_default_display(struct omapfb2_device *fbdev)if(dssdev->name&&strcmp(def_name,dssdev->name)=0)returndssdev;++if(strcmp(def_name,dssdev->alias)=0)+returndssdev;}/* def_name given but not found */returnNULL;}+/* then look for DT alias display0 */+for(i=0;i<fbdev->num_displays;++i){+structomap_dss_device*dssdev;+intid;++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)+returndssdev;+}+/* return the first display we have in the list */returnfbdev->displays[0].dssdev;}
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:40
The regulator names used for DSS components are somewhat ugly for DT
use. As we're just adding DT support, it's simple to change the
regulator names.
This patch makes the DSS driver get the regulators with somewhat cleaner
names. For example, this allows us to define HDMI's VDDA regulator in
the DT data as:
vdda-supply = <...>;
instead of
vdda_hdmi_dac-supply = <...>;
The code also still tries to get the regulators with the old names, if
the regulator_get with the new names fail. This keep backward
compatibility, and can be removed after we have moved to DT.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dsi.c | 5 ++++-
drivers/video/omap2/dss/hdmi4.c | 5 ++++-
drivers/video/omap2/dss/venc.c | 5 ++++-
3 files changed, 12 insertions(+), 3 deletions(-)
@@ -1151,7 +1151,10 @@ static int dsi_regulator_init(struct platform_device *dsidev)if(dsi->vdds_dsi_reg!=NULL)return0;-vdds_dsi=devm_regulator_get(&dsi->pdev->dev,"vdds_dsi");+vdds_dsi=devm_regulator_get(&dsi->pdev->dev,"vdd");++if(IS_ERR(vdds_dsi))+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))
@@ -88,7 +88,10 @@ static int hdmi_init_regulator(void)if(hdmi.vdda_hdmi_dac_reg!=NULL)return0;-reg=devm_regulator_get(&hdmi.pdev->dev,"vdda_hdmi_dac");+reg=devm_regulator_get(&hdmi.pdev->dev,"vdda");++if(IS_ERR(reg)+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))
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:42
Add DT support to DISPC. Only thing needed here is the of_match_table.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dispc.c | 8 ++++++++
1 file changed, 8 insertions(+)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:43
Add DT support to HDMI driver. The only thing needed for DT support here
is the of_match_table.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/hdmi4.c | 6 ++++++
1 file changed, 6 insertions(+)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:44
Add DT support to VENC.
In contrast to non-DT version, the DT version gets the invert-polarity
and connector type via venc's endpoint, not from the connector.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/venc.c | 61 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 61 insertions(+)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:45
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 <redacted>
---
drivers/video/omap2/dss/dsi.c | 139 +++++++++++++++++++++++++++++++++++++++++-
1 file changed, 138 insertions(+), 1 deletion(-)
@@ -5373,12 +5382,69 @@ static void dsi_uninit_output(struct platform_device *dsidev)omapdss_unregister_output(out);}+staticintdsi_probe_of(structplatform_device*pdev)+{+structdevice_node*node=pdev->dev.of_node;+structdsi_data*dsi=dsi_get_dsidrv_data(pdev);+structproperty*prop;+u32lane_arr[10];+intlen,num_pins;+intr,i;+structdevice_node*ep;+structomap_dsi_pin_configpin_cfg;++ep=omapdss_of_get_first_endpoint(node);+if(!ep)+return0;++prop=of_find_property(ep,"lanes",&len);+if(prop=NULL){+dev_err(&pdev->dev,"failed to find lane data\n");+r=-EINVAL;+gotoerr;+}++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;+gotoerr;+}++r=of_property_read_u32_array(ep,"lanes",lane_arr,num_pins);+if(r){+dev_err(&pdev->dev,"failed to read lane data\n");+gotoerr;+}++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");+gotoerr;+}++of_node_put(ep);++return0;++err:+of_node_put(ep);+returnr;+}+/* DSI1 HW IP initialisation */staticintomap_dsihw_probe(structplatform_device*dsidev){u32rev;intr,i;structdsi_data*dsi;+structresource*dsi_mem;structresource*res;structresourcetemp_res;
@@ -5386,7 +5452,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);
@@ -5424,6 +5489,8 @@ static int omap_dsihw_probe(struct platform_device *dsidev)res=&temp_res;}+dsi_mem=res;+dsi->proto_base=devm_ioremap(&dsidev->dev,res->start,resource_size(res));if(!dsi->proto_base){
@@ -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");-gotoerr0;+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");+gotoerr0;+}}r=in->ops.dsi->set_config(in,&dsi_config);
@@ -1156,6 +1161,46 @@ static int dsicm_probe_pdata(struct platform_device *pdev)return0;}+staticintdsicm_probe_of(structplatform_device*pdev)+{+structdevice_node*node=pdev->dev.of_node;+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structomap_dss_device*in;+intgpio;++gpio=of_get_gpio(node,0);+if(!gpio_is_valid(gpio)){+dev_err(&pdev->dev,"failed to parse reset gpio\n");+returngpio;+}+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");+returngpio;+}+}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");+returnPTR_ERR(in);+}++ddata->in=in;++/* TODO: ulps, backlight */++return0;+}+staticintdsicm_probe(structplatform_device*pdev){structbacklight_propertiesprops;
@@ -1178,6 +1223,10 @@ static int dsicm_probe(struct platform_device *pdev)r=dsicm_probe_pdata(pdev);if(r)returnr;+}elseif(pdev->dev.of_node){+r=dsicm_probe_of(pdev);+if(r)+returnr;}else{return-ENODEV;}
@@ -1320,12 +1369,20 @@ static int __exit dsicm_remove(struct platform_device *pdev)return0;}+staticconststructof_device_iddsicm_of_match[]={+{.compatible="omapdss,panel-dsi-cm",},+{},+};++MODULE_DEVICE_TABLE(of,dsicm_of_match);+staticstructplatform_driverdsicm_driver={.probe=dsicm_probe,.remove=__exit_p(dsicm_remove),.driver={.name="panel-dsi-cm",.owner=THIS_MODULE,+.of_match_table=dsicm_of_match,},};
@@ -82,7 +83,8 @@ static int tfp410_enable(struct omap_dss_device *dssdev)return0;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)return0;}+staticinttfp410_probe_of(structplatform_device*pdev)+{+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structdevice_node*node=pdev->dev.of_node;+structomap_dss_device*in;+intgpio;++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");+returngpio;+}++in=omapdss_of_find_source_for_first_ep(node);+if(IS_ERR(in)){+dev_err(&pdev->dev,"failed to find video source\n");+returnPTR_ERR(in);+}++ddata->in=in;++return0;+}+staticinttfp410_probe(structplatform_device*pdev){structpanel_drv_data*ddata;
@@ -195,6 +224,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;}
@@ -251,12 +284,20 @@ static int __exit tfp410_remove(struct platform_device *pdev)return0;}+staticconststructof_device_idtfp410_of_match[]={+{.compatible="omapdss,ti,tfp410",},+{},+};++MODULE_DEVICE_TABLE(of,tfp410_of_match);+staticstructplatform_drivertfp410_driver={.probe=tfp410_probe,.remove=__exit_p(tfp410_remove),.driver={.name="tfp410",.owner=THIS_MODULE,+.of_match_table=tfp410_of_match,},};
@@ -277,6 +277,37 @@ static int dvic_probe_pdata(struct platform_device *pdev)return0;}+staticintdvic_probe_of(structplatform_device*pdev)+{+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structdevice_node*node=pdev->dev.of_node;+structomap_dss_device*in;+structdevice_node*adapter_node;+structi2c_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");+returnPTR_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-EPROBE_DEFER;+}++ddata->i2c_adapter=adapter;+}++return0;+}+staticintdvic_probe(structplatform_device*pdev){structpanel_drv_data*ddata;
@@ -293,6 +324,10 @@ static int dvic_probe(struct platform_device *pdev)r=dvic_probe_pdata(pdev);if(r)returnr;+}elseif(pdev->dev.of_node){+r=dvic_probe_of(pdev);+if(r)+returnr;}else{return-ENODEV;}
@@ -342,12 +377,20 @@ static int __exit dvic_remove(struct platform_device *pdev)return0;}+staticconststructof_device_iddvic_of_match[]={+{.compatible="omapdss,dvi-connector",},+{},+};++MODULE_DEVICE_TABLE(of,dvic_of_match);+staticstructplatform_driverdvi_connector_driver={.probe=dvic_probe,.remove=__exit_p(dvic_remove),.driver={.name="connector-dvi",.owner=THIS_MODULE,+.of_match_table=dvic_of_match,},};
@@ -289,6 +290,49 @@ static int tpd_probe_pdata(struct platform_device *pdev)return0;}+staticinttpd_probe_of(structplatform_device*pdev)+{+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structdevice_node*node=pdev->dev.of_node;+structomap_dss_device*in;+intgpio;++/* 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");+returngpio;+}+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");+returngpio;+}++/* HPD GPIO */+gpio=of_get_gpio(node,2);+if(!gpio_is_valid(gpio)){+dev_err(&pdev->dev,"failed to parse HPD gpio\n");+returngpio;+}+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");+returnPTR_ERR(in);+}++ddata->in=in;++return0;+}+staticinttpd_probe(structplatform_device*pdev){structomap_dss_device*in,*dssdev;
@@ -307,6 +351,10 @@ static int tpd_probe(struct platform_device *pdev)r=tpd_probe_pdata(pdev);if(r)returnr;+}elseif(pdev->dev.of_node){+r=tpd_probe_of(pdev);+if(r)+returnr;}else{return-ENODEV;}
@@ -379,12 +427,20 @@ static int __exit tpd_remove(struct platform_device *pdev)return0;}+staticconststructof_device_idtpd_of_match[]={+{.compatible="omapdss,ti,tpd12s015",},+{},+};++MODULE_DEVICE_TABLE(of,tpd_of_match);+staticstructplatform_drivertpd_driver={.probe=tpd_probe,.remove=__exit_p(tpd_remove),.driver={.name="tpd12s015",.owner=THIS_MODULE,+.of_match_table=tpd_of_match,},};
@@ -301,6 +302,23 @@ static int hdmic_probe_pdata(struct platform_device *pdev)return0;}+staticinthdmic_probe_of(structplatform_device*pdev)+{+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structdevice_node*node=pdev->dev.of_node;+structomap_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");+returnPTR_ERR(in);+}++ddata->in=in;++return0;+}+staticinthdmic_probe(structplatform_device*pdev){structpanel_drv_data*ddata;
@@ -318,6 +336,10 @@ static int hdmic_probe(struct platform_device *pdev)r=hdmic_probe_pdata(pdev);if(r)returnr;+}elseif(pdev->dev.of_node){+r=hdmic_probe_of(pdev);+if(r)+returnr;}else{return-ENODEV;}
@@ -359,12 +381,20 @@ static int __exit hdmic_remove(struct platform_device *pdev)return0;}+staticconststructof_device_idhdmic_of_match[]={+{.compatible="omapdss,hdmi-connector",},+{},+};++MODULE_DEVICE_TABLE(of,hdmic_of_match);+staticstructplatform_driverhdmi_connector_driver={.probe=hdmic_probe,.remove=__exit_p(hdmic_remove),.driver={.name="connector-hdmi",.owner=THIS_MODULE,+.of_match_table=hdmic_of_match,},};
@@ -70,7 +73,8 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)if(omapdss_device_is_enabled(dssdev))return0;-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)return0;}+staticintpanel_dpi_probe_of(structplatform_device*pdev)+{+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structdevice_node*node=pdev->dev.of_node;+structomap_dss_device*in;+intr;+structdisplay_timingtiming;+structvideomodevm;+intgpio;++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");+returngpio;+}++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");+returngpio;+}++r=of_get_display_timing(node,"panel-timing",&timing);+if(r){+dev_err(&pdev->dev,"failed to get video timing\n");+returnr;+}++videomode_from_timing(&timing,&vm);+videomode_to_omap_video_timings(&vm,&ddata->videomode);++in=omapdss_of_find_source_for_first_ep(node);+if(IS_ERR(in)){+dev_err(&pdev->dev,"failed to find video source\n");+returnPTR_ERR(in);+}++ddata->in=in;++return0;+}+staticintpanel_dpi_probe(structplatform_device*pdev){structpanel_drv_data*ddata;
@@ -198,6 +248,10 @@ static int panel_dpi_probe(struct platform_device *pdev)r=panel_dpi_probe_pdata(pdev);if(r)returnr;+}elseif(pdev->dev.of_node){+r=panel_dpi_probe_of(pdev);+if(r)+returnr;}else{return-ENODEV;}
@@ -254,12 +308,20 @@ static int __exit panel_dpi_remove(struct platform_device *pdev)return0;}+staticconststructof_device_idpanel_dpi_of_match[]={+{.compatible="omapdss,panel-dpi",},+{},+};++MODULE_DEVICE_TABLE(of,panel_dpi_of_match);+staticstructplatform_driverpanel_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,},};
@@ -91,8 +98,12 @@ 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->set_type(in,ddata->connector_type);++in->ops.atv->invert_vid_out_polarity(in,+ddata->invert_polarity);+}r=in->ops.atv->enable(in);if(r)
@@ -205,6 +216,23 @@ static int tvc_probe_pdata(struct platform_device *pdev)return0;}+staticinttvc_probe_of(structplatform_device*pdev)+{+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structdevice_node*node=pdev->dev.of_node;+structomap_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");+returnPTR_ERR(in);+}++ddata->in=in;++return0;+}+staticinttvc_probe(structplatform_device*pdev){structpanel_drv_data*ddata;
@@ -222,6 +250,10 @@ static int tvc_probe(struct platform_device *pdev)r=tvc_probe_pdata(pdev);if(r)returnr;+}elseif(pdev->dev.of_node){+r=tvc_probe_of(pdev);+if(r)+returnr;}else{return-ENODEV;}
@@ -263,12 +295,19 @@ static int __exit tvc_remove(struct platform_device *pdev)return0;}+staticconststructof_device_idtvc_of_match[]={+{.compatible="omapdss,svideo-connector",},+{.compatible="omapdss,composite-video-connector",},+{},+};+staticstructplatform_drivertvc_connector_driver={.probe=tvc_probe,.remove=__exit_p(tvc_remove),.driver={.name="connector-analog-tv",.owner=THIS_MODULE,+.of_match_table=tvc_of_match,},};
@@ -547,7 +549,9 @@ static int acx565akm_panel_power_on(struct omap_dss_device *dssdev)dev_dbg(&ddata->spi->dev,"%s\n",__func__);in->ops.sdi->set_timings(in,&ddata->videomode);-in->ops.sdi->set_datapairs(in,ddata->datapairs);++if(ddata->datapairs>0)+in->ops.sdi->set_datapairs(in,ddata->datapairs);r=in->ops.sdi->enable(in);if(r){
@@ -726,6 +730,22 @@ static int acx565akm_probe_pdata(struct spi_device *spi)return0;}+staticintacx565akm_probe_of(structspi_device*spi)+{+structpanel_drv_data*ddata=dev_get_drvdata(&spi->dev);+structdevice_node*np=spi->dev.of_node;++ddata->reset_gpio=of_get_gpio(np,0);++ddata->in=omapdss_of_find_source_for_first_ep(np);+if(IS_ERR(ddata->in)){+dev_err(&spi->dev,"failed to find video source\n");+returnPTR_ERR(ddata->in);+}++return0;+}+staticintacx565akm_probe(structspi_device*spi){structpanel_drv_data*ddata;
@@ -753,7 +773,12 @@ static int acx565akm_probe(struct spi_device *spi)r=acx565akm_probe_pdata(spi);if(r)returnr;+}elseif(spi->dev.of_node){+r=acx565akm_probe_of(spi);+if(r)+returnr;}else{+dev_err(&spi->dev,"platform data missing!\n");return-ENODEV;}
@@ -864,10 +889,16 @@ static int acx565akm_remove(struct spi_device *spi)return0;}+staticconststructof_device_idacx565akm_of_match[]={+{.compatible="omapdss,sony,acx565akm",},+{},+};+staticstructspi_driveracx565akm_driver={.driver={.name="acx565akm",.owner=THIS_MODULE,+.of_match_table=acx565akm_of_match,},.probe=acx565akm_probe,.remove=acx565akm_remove,
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:54
Add DT data for OMAP2 display subsystem, which contains the following
blocks:
dss - the wrapper/glue for the display modules
dispc - display controller
rfbi - MIPI DBI encoder
venc - analog TV encoder
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/boot/dts/omap2.dtsi | 31 +++++++++++++++++++++++++++++++
1 file changed, 31 insertions(+)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:55
Add DT data for OMAP3 display subsystem, which contains the following
blocks:
dss - the wrapper/glue for the display modules
dispc - display controller
dsi - MIPI DSI encoder
rfbi - MIPI DBI encoder
venc - analog TV encoder
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/boot/dts/omap3.dtsi | 42 ++++++++++++++++++++++++++++++++++++++++++
1 file changed, 42 insertions(+)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:57
Add DT data for OMAP4 Pandaboard. The board has the following displays:
dvi: uses TFP410 encoder to convert DPI to DVI
hdmi: OMAP HDMI output with TPD12S015 ESD/level shifter
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/boot/dts/omap4-panda-common.dtsi | 119 +++++++++++++++++++++++++++++-
1 file changed, 115 insertions(+), 4 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:56:59
Add DT data for OMAP3 Beagle board. The board has the following displays:
dvi: uses TFP410 encoder to convert DPI to DVI
tv: analog svideo
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/boot/dts/omap3-beagle.dts | 116 +++++++++++++++++++++++++++++++++++++
1 file changed, 116 insertions(+)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:57:00
Add DT data for OMAP3 Beagle-xM board. The board has the following displays:
dvi: uses TFP410 encoder to convert DPI to DVI
tv: analog svideo
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/boot/dts/omap3-beagle-xm.dts | 119 ++++++++++++++++++++++++++++++++++
1 file changed, 119 insertions(+)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:57:02
Add DT data for OMAP3 N900 board. The board has the following displays:
lcd: LCD panel connected to OMAP's SDI output
tv: analog svideo
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/boot/dts/omap3-n900.dts | 70 +++++++++++++++++++++++++++++++++++++---
1 file changed, 66 insertions(+), 4 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:57:03
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 <redacted>
---
drivers/video/omap2/dss/dsi.c | 9 +--------
drivers/video/omap2/dss/hdmi4.c | 9 +--------
2 files changed, 2 insertions(+), 16 deletions(-)
@@ -1162,16 +1162,9 @@ static int dsi_regulator_init(struct platform_device *dsidev)vdds_dsi=devm_regulator_get(&dsi->pdev->dev,"vdd");-if(IS_ERR(vdds_dsi))-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)){if(PTR_ERR(vdds_dsi)!=-EPROBE_DEFER)-DSSERR("can't get VDDS_DSI regulator\n");+DSSERR("can't get DSI VDD regulator\n");returnPTR_ERR(vdds_dsi);}
@@ -90,16 +90,9 @@ static int hdmi_init_regulator(void)reg=devm_regulator_get(&hdmi.pdev->dev,"vdda");-if(IS_ERR(reg)-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)){if(PTR_ERR(reg)!=-EPROBE_DEFER)-DSSERR("can't get VDDA_HDMI_DAC regulator\n");+DSSERR("can't get VDDA regulator\n");returnPTR_ERR(reg);}
From: Tomi Valkeinen <hidden> Date: 2014-01-21 10:57:04
Remove pdata quirks for the displays on boards that are now supported
properly with DT.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/dss-common.c | 224 -------------------------------------
arch/arm/mach-omap2/pdata-quirks.c | 3 -
2 files changed, 227 deletions(-)
@@ -0,0 +1,197 @@+Texas Instruments OMAP Display Subsystem+====================++Generic Description+-------------------++This document is a generic description of the OMAP Display Subsystem bindings.+Binding details for each OMAP SoC version are described in respective binding+documentation.++The OMAP Display Subsystem (DSS) hardware consists of DSS Core, DISPC module and+a number of encoder modules. All DSS versions contain DSS Core and DISPC, but+the encoder modules vary.++The DSS Core is the parent of the other DSS modules, and manages clock routing,+integration to the SoC, etc.++DISPC is the display controller, which reads pixels from the memory and outputs+a RGB pixel stream to encoders.++The encoder modules encode the received RGB pixel stream to a video output like+HDMI, MIPI DPI, etc.++Video Ports+-----------++The DSS Core and the encoders have video port outputs. The structure of the+video ports is described in Documentation/devicetree/bindings/video/video-+ports.txt, and the properties for the ports and endpoints for each encoder are+described in the SoC's DSS binding documentation.++The video ports are used to describe the connections to external hardware, like+panels or external encoders.++Aliases+-------++The board dts file may define aliases for displays to assign "displayX" style+name for each display. If no aliases are defined, a semi-random number is used+for the display.++Example+-------++A shortened example of the DSS description for OMAP4, with non-relevant parts+removed, defined in omap4.dtsi:++dss: dss@58000000 {+ compatible = "ti,omap4-dss", "simple-bus";+ reg = <0x58000000 0x80>;+ status = "disabled";+ ti,hwmods = "dss_core";+ #address-cells = <1>;+ #size-cells = <1>;+ ranges;++ dispc@58001000 {+ compatible = "ti,omap4-dispc";+ reg = <0x58001000 0x1000>;+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH>;+ ti,hwmods = "dss_dispc";+ };++ hdmi: encoder@58006000 {+ compatible = "ti,omap4-hdmi";+ reg = <0x58006000 0x200>,+ <0x58006200 0x100>,+ <0x58006300 0x100>,+ <0x58006400 0x1000>;+ reg-names = "wp", "pll", "phy", "core";+ interrupts = <GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;+ status = "disabled";+ ti,hwmods = "dss_hdmi";+ };+};++A shortened example of the board description for OMAP4 Panda board, defined in+omap4-panda.dts.++The Panda board has a DVI and a HDMI connector, and the board contains a TFP410+chip (MIPI DPI to DVI encoder) and a TPD12S015 chip (HDMI ESD protection & level+shifter). The video pipelines for the connectors are formed as follows:++DSS Core --(MIPI DPI)--> TFP410 --(DVI)--> DVI Connector+OMAP HDMI --(HDMI)--> TPD12S015 --(HDMI)--> HDMI COnnector++/ {+ aliases {+ display0 = &dvi0;+ display1 = &hdmi0;+ };++ tfp410: encoder@0 {+ compatible = "ti,tfp410";+ gpios = <&gpio1 0 GPIO_ACTIVE_LOW>; /* 0, power-down */++ pinctrl-names = "default";+ pinctrl-0 = <&tfp410_pins>;++ 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@0 {+ remote-endpoint = <&dvi_connector_in>;+ };+ };+ };+ };++ dvi0: connector@0 {+ compatible = "dvi-connector";+ label = "dvi";++ i2c-bus = <&i2c3>;++ dvi_connector_in: endpoint {+ remote-endpoint = <&tfp410_out>;+ };+ };++ tpd12s015: encoder@1 {+ compatible = "ti,tpd12s015";++ pinctrl-names = "default";+ pinctrl-0 = <&tpd12s015_pins>;++ gpios = <&gpio2 28 GPIO_ACTIVE_HIGH>, /* 60, CT CP HPD */+ <&gpio2 9 GPIO_ACTIVE_HIGH>, /* 41, LS OE */+ <&gpio2 31 GPIO_ACTIVE_HIGH>; /* 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@0 {+ remote-endpoint = <&hdmi_connector_in>;+ };+ };+ };+ };++ hdmi0: connector@1 {+ compatible = "hdmi-connector";+ label = "hdmi";++ hdmi_connector_in: endpoint {+ remote-endpoint = <&tpd12s015_out>;+ };+ };+};++&dss {+ status = "ok";++ pinctrl-names = "default";+ pinctrl-0 = <&dss_dpi_pins>;++ dpi_out: endpoint {+ remote-endpoint = <&tfp410_in>;+ data-lines = <24>;+ };+};++&hdmi {+ status = "ok";+ vdda-supply = <&vdac>;++ pinctrl-names = "default";+ pinctrl-0 = <&dss_hdmi_pins>;++ hdmi_out: endpoint {+ remote-endpoint = <&tpd12s015_in>;+ };+};
@@ -0,0 +1,54 @@+Texas Instruments OMAP2 Display Subsystem+====================++See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic+description about OMAP Display Subsystem bindings.++DSS Core+--------++Required properties:+- compatible: "ti,omap2-dss"+- reg: address and length of the register space+- ti,hwmods: "dss_core"++Optional nodes:+- Video port for DPI output++DPI Endpoint required properties:+- data-lines: number of lines used+++DISPC+-----++Required properties:+- compatible: "ti,omap2-dispc"+- reg: address and length of the register space+- ti,hwmods: "dss_dispc"+- interrupts: the DISPC interrupt+++RFBI+----++Required properties:+- compatible: "ti,omap2-rfbi"+- reg: address and length of the register space+- ti,hwmods: "dss_rfbi"+++VENC+----++Required properties:+- compatible: "ti,omap2-venc"+- reg: address and length of the register space+- ti,hwmods: "dss_venc"+- vdda-supply: power supply for DAC++VENC Endpoint required properties:++Required properties:+- ti,invert-polarity: invert the polarity of the video signal+- ti,channels: 1 for composite, 2 for s-video
@@ -0,0 +1,73 @@+Texas Instruments OMAP3 Display Subsystem+====================++See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic+description about OMAP Display Subsystem bindings.++DSS Core+--------++Required properties:+- compatible: "ti,omap3-dss"+- reg: address and length of the register space+- ti,hwmods: "dss_core"++Optional nodes:+- Video ports:+ - Port 0: DPI output+ - Port 1: SDI output++DPI Endpoint required properties:+- data-lines: number of lines used++SDI Endpoint required properties:+- datapairs: number of datapairs used+++DISPC+-----++Required properties:+- compatible: "ti,omap3-dispc"+- reg: address and length of the register space+- ti,hwmods: "dss_dispc"+- interrupts: the DISPC interrupt+++RFBI+----++Required properties:+- compatible: "ti,omap3-rfbi"+- reg: address and length of the register space+- ti,hwmods: "dss_rfbi"+++VENC+----++Required properties:+- compatible: "ti,omap3-venc"+- reg: address and length of the register space+- ti,hwmods: "dss_venc"+- vdda-supply: power supply for DAC++VENC Endpoint required properties:+- ti,invert-polarity: invert the polarity of the video signal+- ti,channels: 1 for composite, 2 for s-video+++DSI+---++Required properties:+- compatible: "ti,omap3-dsi"+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'+- reg-names: "proto", "phy", "pll"+- interrupts: the DSI interrupt line+- ti,hwmods: "dss_dsi1"+- vdd-supply: power supply for DSI++DSI Endpoint required properties:+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,+ DATA1+, DATA1-, ...
@@ -0,0 +1,99 @@+Texas Instruments OMAP4 Display Subsystem+====================++See Documentation/devicetree/bindings/video/ti,omap-dss.txt for generic+description about OMAP Display Subsystem bindings.++DSS Core+--------++Required properties:+- compatible: "ti,omap4-dss"+- reg: address and length of the register space+- ti,hwmods: "dss_core"++Required nodes:+- DISPC++Optional nodes:+- DSS Submodules: RFBI, VENC, DSI, HDMI+- Video port for DPI output++DPI Endpoint required properties:+- data-lines: number of lines used+++DISPC+-----++Required properties:+- compatible: "ti,omap4-dispc"+- reg: address and length of the register space+- ti,hwmods: "dss_dispc"+- interrupts: the DISPC interrupt+++RFBI+----++Required properties:+- compatible: "ti,omap4-rfbi"+- reg: address and length of the register space+- ti,hwmods: "dss_rfbi"++Optional nodes:+- Video port for RFBI output+- RFBI controlled peripherals+++VENC+----++Required properties:+- compatible: "ti,omap4-venc"+- reg: address and length of the register space+- ti,hwmods: "dss_venc"+- vdda-supply: power supply for DAC++Optional nodes:+- Video port for VENC output++VENC Endpoint required properties:+- ti,invert-polarity: invert the polarity of the video signal+- ti,channels: 1 for composite, 2 for s-video+++DSI+---++Required properties:+- compatible: "ti,omap4-dsi"+- reg: addresses and lengths of the register spaces for 'proto', 'phy' and 'pll'+- reg-names: "proto", "phy", "pll"+- interrupts: the DSI interrupt line+- ti,hwmods: "dss_dsi1" or "dss_dsi2"+- vdd-supply: power supply for DSI++Optional nodes:+- Video port for DSI output+- DSI controlled peripherals++DSI Endpoint required properties:+- lanes: list of pin numbers for the DSI lanes: CLK+, CLK-, DATA0+, DATA0-,+ DATA1+, DATA1-, ...+++HDMI+----++Required properties:+- compatible: "ti,omap4-hdmi"+- reg: addresses and lengths of the register spaces for 'wp', 'pll', 'phy',+ 'core'+- reg-names: "wp", "pll", "phy", "core"+- interrupts: the HDMI interrupt line+- ti,hwmods: "dss_hdmi"+- vdda-supply: vdda power supply++Optional nodes:+- Video port for HDMI output
@@ -0,0 +1,22 @@+Video Ports+=====++The video port bindings used for display devices is a superset of the v4l2 video+ports described here:++Documentation/devicetree/bindings/media/video-interfaces.txt++The only difference is a more compact way to describe devices with only one+endpoint. In cases like that, the 'ports' and 'port' nodes are not needed. For+example, a DPI panel with a single input endpoint:++lcd0: display@0 {+ compatible = "samsung,lte430wq-f0c", "panel-dpi";++ lcd_in: endpoint {+ remote-endpoint = <&dpi_out>;+ };+};++The rest of the bindings are the same as in v4l2 video port bindings and not+described here.
@@ -0,0 +1,23 @@+Analog TV Connector+=========++Required properties:+- compatible: "composite-connector" or "svideo-connector"++Optional properties:+- label: a symbolic name for the connector++Required nodes:+- Video port for TV input++Example+-------++tv: connector {+ compatible = "composite-connector";+ label = "tv";++ tv_connector_in: endpoint {+ remote-endpoint = <&venc_out>;+ };+};
@@ -0,0 +1,26 @@+DVI Connector+=======++Required properties:+- compatible: "dvi-connector"++Optional properties:+- label: a symbolic name for the connector+- i2c-bus: phandle to the i2c bus that is connected to DVI DDC++Required nodes:+- Video port for DVI input++Example+-------++dvi0: connector@0 {+ compatible = "dvi-connector";+ label = "dvi";++ i2c-bus = <&i2c3>;++ dvi_connector_in: endpoint {+ remote-endpoint = <&tfp410_out>;+ };+};
From: Sebastian Reichel <hidden> Date: 2014-01-21 15:26:05
On Tue, Jan 21, 2014 at 12:57:02PM +0200, Tomi Valkeinen wrote:
Add DT data for OMAP3 N900 board. The board has the following
displays:
lcd: LCD panel connected to OMAP's SDI output
tv: analog svideo
Signed-off-by: Tomi Valkeinen <redacted>
Your dss-dt-review-3 branch boots on my N900 with working display.
Tested-by: Sebastian Reichel <redacted>
-- Sebastian
Tomi,
On 01/21/2014 04:56 AM, Tomi Valkeinen wrote:
Hi,
Here's version 3 of the DSS DT series.
The previous version can be found from:
v1: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108249
v2: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108866
The main changes to v2 are:
- DT Binding documentation
- OMAP2 DSS support
- Split DSI register space
- DSS nodes disabled by default
- Hack to have generic DT bindings but OMAP specific drivers (for now)
This series can also be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-review-3
http://slexy.org/view/s20JhteOFR is my quick build test report -> few
checkpatch and build bisect issues would probably need fixing.
--
Regards,
Nishanth Menon
From: Tomi Valkeinen <hidden> Date: 2014-01-22 08:41:55
On 2014-01-21 23:29, Nishanth Menon wrote:
Tomi,
On 01/21/2014 04:56 AM, Tomi Valkeinen wrote:
quoted
Hi,
Here's version 3 of the DSS DT series.
The previous version can be found from:
v1: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108249
v2: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108866
The main changes to v2 are:
- DT Binding documentation
- OMAP2 DSS support
- Split DSI register space
- DSS nodes disabled by default
- Hack to have generic DT bindings but OMAP specific drivers (for now)
This series can also be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-review-3
http://slexy.org/view/s20JhteOFR is my quick build test report -> few
checkpatch and build bisect issues would probably need fixing.
Thanks. Shouldn't make trivial changes, and then not run a full
commit-by-commit compile test...
I fixed the issues and pushed the branch again to work/dss-dt-review-3.
The fixes are minor, so the already posted series can be reviewed.
Tomi
From: Tomi Valkeinen <hidden> Date: 2014-01-24 11:46:15
On 2014-01-21 17:26, Sebastian Reichel wrote:
On Tue, Jan 21, 2014 at 12:57:02PM +0200, Tomi Valkeinen wrote:
quoted
Add DT data for OMAP3 N900 board. The board has the following
displays:
lcd: LCD panel connected to OMAP's SDI output
tv: analog svideo
Signed-off-by: Tomi Valkeinen <redacted>
Your dss-dt-review-3 branch boots on my N900 with working display.
Tested-by: Sebastian Reichel <redacted>
From: Javier Martinez Canillas <javier@dowhile0.org> Date: 2014-01-26 23:07:45
Hi Tomi,
On Tue, Jan 21, 2014 at 7:56 AM, Tomi Valkeinen [off-list ref] wrote:
Hi,
Here's version 3 of the DSS DT series.
The previous version can be found from:
v1: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108249
v2: http://permalink.gmane.org/gmane.linux.ports.arm.omap/108866
The main changes to v2 are:
- DT Binding documentation
- OMAP2 DSS support
- Split DSI register space
- DSS nodes disabled by default
- Hack to have generic DT bindings but OMAP specific drivers (for now)
This series can also be found from:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/dss-dt-review-3
I tested this branch on my DM3730 IGEPv2 and output display is working
correctly.
Tested-by: Javier Martinez Canillas <javier@dowhile0.org>
Tomi
Javier Martinez Canillas (1):
ARM: omap3-igep0020.dts: add display information
Sebastian Reichel (1):
OMAPDSS: acx565akm: Add DT support
Tomi Valkeinen (39):
ARM: OMAP2+: add omapdss_init_of()
ARM: OMAP2+: DT 'compatible' tweak for displays
OMAPDSS: add 'label' support for DT
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: Improve regulator names for DT
OMAPDSS: Add DT support to DSS
OMAPDSS: Add DT support to DISPC
OMAPDSS: Add DT support to HDMI
OMAPDSS: Add DT support to VENC
OMAPDSS: Add DT support to DSI
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
ARM: omap2.dtsi: add omapdss information
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-beagle.dts: add display information
ARM: omap3-beagle-xm.dts: add display information
ARM: omap3-n900.dts: add display information
OMAPDSS: remove DT hacks for regulators
ARM: OMAP2+: remove pdata quirks for displays
Doc/DT: Add OMAP DSS DT Bindings
Doc/DT: Add DT binding documentation for Analog TV Connector
Doc/DT: Add DT binding documentation for DVI Connector
Doc/DT: Add DT binding documentation for HDMI Connector
Doc/DT: Add DT binding documentation for MIPI DPI Panel
Doc/DT: Add DT binding documentation for MIPI DSI CM Panel
Doc/DT: Add DT binding documentation for Sony acx565akm panel
Doc/DT: Add DT binding documentation for TFP410 encoder
Doc/DT: Add DT binding documentation for tpd12s015 encoder
.../bindings/video/analog-tv-connector.txt | 23 +++
.../devicetree/bindings/video/dvi-connector.txt | 26 +++
.../devicetree/bindings/video/hdmi-connector.txt | 23 +++
.../devicetree/bindings/video/panel-dpi.txt | 43 ++++
.../devicetree/bindings/video/panel-dsi-cm.txt | 26 +++
.../devicetree/bindings/video/sony,acx565akm.txt | 28 +++
.../devicetree/bindings/video/ti,omap-dss.txt | 197 ++++++++++++++++++
.../devicetree/bindings/video/ti,omap2-dss.txt | 54 +++++
.../devicetree/bindings/video/ti,omap3-dss.txt | 73 +++++++
.../devicetree/bindings/video/ti,omap4-dss.txt | 99 +++++++++
.../devicetree/bindings/video/ti,tfp410.txt | 41 ++++
.../devicetree/bindings/video/ti,tpd12s015.txt | 44 ++++
.../devicetree/bindings/video/video-ports.txt | 22 ++
arch/arm/boot/dts/omap2.dtsi | 31 +++
arch/arm/boot/dts/omap3-beagle-xm.dts | 119 +++++++++++
arch/arm/boot/dts/omap3-beagle.dts | 116 +++++++++++
arch/arm/boot/dts/omap3-igep0020.dts | 59 +++++-
arch/arm/boot/dts/omap3-n900.dts | 70 ++++++-
arch/arm/boot/dts/omap3.dtsi | 42 ++++
arch/arm/boot/dts/omap4-panda-common.dtsi | 119 ++++++++++-
arch/arm/boot/dts/omap4-sdp.dts | 107 +++++++++-
arch/arm/boot/dts/omap4.dtsi | 65 ++++++
arch/arm/mach-omap2/board-generic.c | 4 +
arch/arm/mach-omap2/common.h | 3 +
arch/arm/mach-omap2/display.c | 132 ++++++++++++
arch/arm/mach-omap2/dss-common.c | 224 ---------------------
arch/arm/mach-omap2/pdata-quirks.c | 3 -
.../video/omap2/displays-new/connector-analog-tv.c | 43 +++-
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 +++++-
.../omap2/displays-new/panel-sony-acx565akm.c | 33 ++-
drivers/video/omap2/dss/Makefile | 2 +-
drivers/video/omap2/dss/dispc.c | 8 +
drivers/video/omap2/dss/display.c | 28 ++-
drivers/video/omap2/dss/dpi.c | 47 +++++
drivers/video/omap2/dss/dsi.c | 147 +++++++++++++-
drivers/video/omap2/dss/dss-of.c | 159 +++++++++++++++
drivers/video/omap2/dss/dss.c | 64 ++++++
drivers/video/omap2/dss/dss.h | 6 +
drivers/video/omap2/dss/hdmi4.c | 14 +-
drivers/video/omap2/dss/sdi.c | 45 +++++
drivers/video/omap2/dss/venc.c | 66 +++++-
drivers/video/omap2/omapfb/omapfb-main.c | 67 ++++--
include/video/omapdss.h | 14 ++
48 files changed, 2550 insertions(+), 287 deletions(-)
create mode 100644 Documentation/devicetree/bindings/video/analog-tv-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/dvi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/hdmi-connector.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dpi.txt
create mode 100644 Documentation/devicetree/bindings/video/panel-dsi-cm.txt
create mode 100644 Documentation/devicetree/bindings/video/sony,acx565akm.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap2-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap3-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,omap4-dss.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tfp410.txt
create mode 100644 Documentation/devicetree/bindings/video/ti,tpd12s015.txt
create mode 100644 Documentation/devicetree/bindings/video/video-ports.txt
create mode 100644 drivers/video/omap2/dss/dss-of.c
--
1.8.3.2
From: Tomi Valkeinen <hidden> Date: 2014-03-06 07:29:09
Hi Tony,
On 21/01/14 12:56, Tomi Valkeinen wrote:
Hi,
Here's version 3 of the DSS DT series.
Can you have a look at the arch/arm/ parts in the series and ack if
they're ok, i.e, patches 1, 2, 32.
Then there are the .dts patches, 22-30, for which I haven't been able to
get any acks. I'm not sure who I should get acks from for those, but I
don't mind adding yours if you want to give it.
The .dts patches have had minor changes compared to the ones posted
here, according to the DT bindings review comments, but nothing much has
changed.
Tomi
From: Tony Lindgren <tony@atomide.com> Date: 2014-03-07 16:49:29
* Tomi Valkeinen [off-list ref] [140305 23:32]:
Hi Tony,
On 21/01/14 12:56, Tomi Valkeinen wrote:
quoted
Hi,
Here's version 3 of the DSS DT series.
Can you have a look at the arch/arm/ parts in the series and ack if
they're ok, i.e, patches 1, 2, 32.
Patches 1, 2 & 32 look OK to me, so for those please feel free to add:
Acked-by: Tony Lindgren <tony@atomide.com>
There's a minor merge conflict in pdata-quirks.c, but that's trivial
so it should be OK for you to queue those along with the DSS patches.
Then there are the .dts patches, 22-30, for which I haven't been able to
get any acks. I'm not sure who I should get acks from for those, but I
don't mind adding yours if you want to give it.
The .dts patches have had minor changes compared to the ones posted
here, according to the DT bindings review comments, but nothing much has
changed.
These will cause unnecessary merge conflicts all over the place:
Auto-merging arch/arm/boot/dts/omap4.dtsi
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4.dtsi
Auto-merging arch/arm/boot/dts/omap4-sdp.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4-sdp.dts
Auto-merging arch/arm/boot/dts/omap4-panda-common.dtsi
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap4-panda-common.dtsi
Auto-merging arch/arm/boot/dts/omap3.dtsi
Auto-merging arch/arm/boot/dts/omap3-n900.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-n900.dts
Auto-merging arch/arm/boot/dts/omap3-igep0020.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-igep0020.dts
Auto-merging arch/arm/boot/dts/omap3-beagle.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-beagle.dts
Auto-merging arch/arm/boot/dts/omap3-beagle-xm.dts
CONFLICT (content): Merge conflict in arch/arm/boot/dts/omap3-beagle-xm.dts
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break anything.
Then make sure your series works both ways and maybe do a follow up
patch that flips things over after the dependencies are merged.
Regards,
Tony
From: Tomi Valkeinen <hidden> Date: 2014-03-10 13:22:48
On 07/03/14 18:49, Tony Lindgren wrote:
* Tomi Valkeinen [off-list ref] [140305 23:32]:
quoted
Hi Tony,
On 21/01/14 12:56, Tomi Valkeinen wrote:
quoted
Hi,
Here's version 3 of the DSS DT series.
Can you have a look at the arch/arm/ parts in the series and ack if
they're ok, i.e, patches 1, 2, 32.
Patches 1, 2 & 32 look OK to me, so for those please feel free to add:
Acked-by: Tony Lindgren <tony@atomide.com>
Thanks.
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break anything.
Unfortunately they do break. At least pinmuxing is moved from the global
definitions to be handled by the respective display drivers, and there
are some regulator_name hacks that the DT patches remove.
I think those changes could be removed from my patches, and then added
back later when everything else has been merged.
The bigger issue is that suddenly there's lots of discussion about the
display DT bindings. If those are not resolved very soon, I guess I have
no choice but to again skip the merge window for the DSS DT changes.
Tomi
From: Tony Lindgren <tony@atomide.com> Date: 2014-03-10 15:41:06
* Tomi Valkeinen [off-list ref] [140310 06:26]:
On 07/03/14 18:49, Tony Lindgren wrote:
quoted
* Tomi Valkeinen [off-list ref] [140305 23:32]:
quoted
Hi Tony,
On 21/01/14 12:56, Tomi Valkeinen wrote:
quoted
Hi,
Here's version 3 of the DSS DT series.
Can you have a look at the arch/arm/ parts in the series and ack if
they're ok, i.e, patches 1, 2, 32.
Patches 1, 2 & 32 look OK to me, so for those please feel free to add:
Acked-by: Tony Lindgren <tony@atomide.com>
Thanks.
quoted
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break anything.
Unfortunately they do break. At least pinmuxing is moved from the global
definitions to be handled by the respective display drivers, and there
are some regulator_name hacks that the DT patches remove.
OK. Will that cause regressions for omap3 as that's still also booting
in legacy mode?
I think those changes could be removed from my patches, and then added
back later when everything else has been merged.
Or you could have a second branch that also merges in omap-for-v3.15/dt
branch that you can send later towards the merge window after the arm-soc
changes have been merged. If you want to do that, then feel free to add
my ack also for the .dts changes:
Acked-by: Tony Lindgren <tony@atomide.com>
If however those changes get postponed to v3.16, it's best that you'll
redo the branch as I'm sure we'll have other merge issues for v3.16.
The bigger issue is that suddenly there's lots of discussion about the
display DT bindings. If those are not resolved very soon, I guess I have
no choice but to again skip the merge window for the DSS DT changes.
OK, some of these more bindings can take easily six months to reach
some kind of resolution. You may be able to use TI specific unstable
bindings meanwhile if that makese sense.
Regards,
Tony
From: Tomi Valkeinen <hidden> Date: 2014-03-11 10:15:55
On 10/03/14 17:41, Tony Lindgren wrote:
quoted
quoted
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break anything.
Unfortunately they do break. At least pinmuxing is moved from the global
definitions to be handled by the respective display drivers, and there
are some regulator_name hacks that the DT patches remove.
OK. Will that cause regressions for omap3 as that's still also booting
in legacy mode?
No, I don't think so. The problems revolve around the pdata-quirks, with
current DSS support when booting with DT. It's rather difficult to split
the series so that it could be merged freely in multiple parts.
If I split the series into three parts: 1) .dts changes 2) main DSS DT
changes 3) removal of pdata-quirks etc, I run into problems. Both 1) and
2) work fine individually, but when both are merged, there are two
competing systems, the proper DT stuff and the pdata-quirks stuff. And I
haven't found out a simple way to manage that, as the whole display
support is split into multiple independent devices.
One option would be to combine 1) and 3), so that when they are merged,
there would be proper DT data, and the pdata-quirks would be removed so
that it wouldn't be messing everything up. But that would, of course,
mean that after merging 1+3, the display wouldn't work on those boards
that rely on pdata-quirks, until 2) is merged.
quoted
I think those changes could be removed from my patches, and then added
back later when everything else has been merged.
Or you could have a second branch that also merges in omap-for-v3.15/dt
branch that you can send later towards the merge window after the arm-soc
changes have been merged. If you want to do that, then feel free to add
my ack also for the .dts changes:
Acked-by: Tony Lindgren <tony@atomide.com>
If however those changes get postponed to v3.16, it's best that you'll
redo the branch as I'm sure we'll have other merge issues for v3.16.
Ok. At the moment I feel that the easiest option would be to keep the
DSS DT series as it is, but merge omap-for-v3.15/dt to it and solve the
conflicts. I'd keep that branch separate from the fbdev changes, so that
I could send the DSS DT pull request later, when arm-soc has been pulled.
quoted
The bigger issue is that suddenly there's lots of discussion about the
display DT bindings. If those are not resolved very soon, I guess I have
no choice but to again skip the merge window for the DSS DT changes.
OK, some of these more bindings can take easily six months to reach
some kind of resolution. You may be able to use TI specific unstable
bindings meanwhile if that makese sense.
Yep. I don't know... If the whole port/endpoint system that I currently
use is changed totally, it might be painful to support both the TI
specific bindings with the old format and the newer format.
Tomi
From: Tony Lindgren <tony@atomide.com> Date: 2014-03-11 16:28:16
* Tomi Valkeinen [off-list ref] [140311 03:19]:
On 10/03/14 17:41, Tony Lindgren wrote:
quoted
quoted
quoted
How about do a pull request for just the .dts changes against current
omap-for-v3.15/dt branch ASAP for me so I can pull it in? That is assuming
that just the .dts changes alone won't break anything.
Unfortunately they do break. At least pinmuxing is moved from the global
definitions to be handled by the respective display drivers, and there
are some regulator_name hacks that the DT patches remove.
OK. Will that cause regressions for omap3 as that's still also booting
in legacy mode?
No, I don't think so. The problems revolve around the pdata-quirks, with
current DSS support when booting with DT. It's rather difficult to split
the series so that it could be merged freely in multiple parts.
If I split the series into three parts: 1) .dts changes 2) main DSS DT
changes 3) removal of pdata-quirks etc, I run into problems. Both 1) and
2) work fine individually, but when both are merged, there are two
competing systems, the proper DT stuff and the pdata-quirks stuff. And I
haven't found out a simple way to manage that, as the whole display
support is split into multiple independent devices.
One option would be to combine 1) and 3), so that when they are merged,
there would be proper DT data, and the pdata-quirks would be removed so
that it wouldn't be messing everything up. But that would, of course,
mean that after merging 1+3, the display wouldn't work on those boards
that rely on pdata-quirks, until 2) is merged.
OK, best to keep the series together then.
quoted
quoted
I think those changes could be removed from my patches, and then added
back later when everything else has been merged.
Or you could have a second branch that also merges in omap-for-v3.15/dt
branch that you can send later towards the merge window after the arm-soc
changes have been merged. If you want to do that, then feel free to add
my ack also for the .dts changes:
Acked-by: Tony Lindgren <tony@atomide.com>
If however those changes get postponed to v3.16, it's best that you'll
redo the branch as I'm sure we'll have other merge issues for v3.16.
Ok. At the moment I feel that the easiest option would be to keep the
DSS DT series as it is, but merge omap-for-v3.15/dt to it and solve the
conflicts. I'd keep that branch separate from the fbdev changes, so that
I could send the DSS DT pull request later, when arm-soc has been pulled.
OK makes sense to me.
quoted
quoted
The bigger issue is that suddenly there's lots of discussion about the
display DT bindings. If those are not resolved very soon, I guess I have
no choice but to again skip the merge window for the DSS DT changes.
OK, some of these more bindings can take easily six months to reach
some kind of resolution. You may be able to use TI specific unstable
bindings meanwhile if that makese sense.
Yep. I don't know... If the whole port/endpoint system that I currently
use is changed totally, it might be painful to support both the TI
specific bindings with the old format and the newer format.
OK that's up you guys in the display land, I have not followed the
latest bindings discussion.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com> Date: 2014-04-08 00:13:39
Tomi,
* Tomi Valkeinen [off-list ref] [140121 03:01]:
Add DT support for panel-dpi.
Looks like this patch did not get merged or am I missing
something?
As you probably are aware, we have at least these boards
needing it before we can remove the omap3 legacy support:
board-am3517evm.c
board-cm-t35.c
board-devkit8000.c
board-ldp.c
board-overo.c
We could probably set the display timings based on the
compatible flag in the driver if that's an issue?
And then board-omap3pandora.c also needs support for
panel_tpo_td043mtea1_platform_data.
Regards,
Tony
@@ -70,7 +73,8 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)if(omapdss_device_is_enabled(dssdev))return0;-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)return0;}+staticintpanel_dpi_probe_of(structplatform_device*pdev)+{+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structdevice_node*node=pdev->dev.of_node;+structomap_dss_device*in;+intr;+structdisplay_timingtiming;+structvideomodevm;+intgpio;++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");+returngpio;+}++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");+returngpio;+}++r=of_get_display_timing(node,"panel-timing",&timing);+if(r){+dev_err(&pdev->dev,"failed to get video timing\n");+returnr;+}++videomode_from_timing(&timing,&vm);+videomode_to_omap_video_timings(&vm,&ddata->videomode);++in=omapdss_of_find_source_for_first_ep(node);+if(IS_ERR(in)){+dev_err(&pdev->dev,"failed to find video source\n");+returnPTR_ERR(in);+}++ddata->in=in;++return0;+}+staticintpanel_dpi_probe(structplatform_device*pdev){structpanel_drv_data*ddata;
@@ -198,6 +248,10 @@ static int panel_dpi_probe(struct platform_device *pdev)r=panel_dpi_probe_pdata(pdev);if(r)returnr;+}elseif(pdev->dev.of_node){+r=panel_dpi_probe_of(pdev);+if(r)+returnr;}else{return-ENODEV;}
@@ -254,12 +308,20 @@ static int __exit panel_dpi_remove(struct platform_device *pdev)return0;}+staticconststructof_device_idpanel_dpi_of_match[]={+{.compatible="omapdss,panel-dpi",},+{},+};++MODULE_DEVICE_TABLE(of,panel_dpi_of_match);+staticstructplatform_driverpanel_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,},};
From: Tomi Valkeinen <hidden> Date: 2014-04-08 05:38:13
On 08/04/14 03:13, Tony Lindgren wrote:
Tomi,
* Tomi Valkeinen [off-list ref] [140121 03:01]:
quoted
Add DT support for panel-dpi.
Looks like this patch did not get merged or am I missing
something?
Yes, I dropped it. None of the boards that I converted used panel-dpi.
There was so much discussions about the display bindings, so I thought
it's better to leave out all but the needed patches.
As you probably are aware, we have at least these boards
needing it before we can remove the omap3 legacy support:
board-am3517evm.c
board-cm-t35.c
board-devkit8000.c
board-ldp.c
board-overo.c
We could probably set the display timings based on the
compatible flag in the driver if that's an issue?
The timings shouldn't be an issue. But there's the backlight GPIO,
currently handled by panel-dpi, which should be removed from the panel.
We should use gpio-backlight for that one.
And then board-omap3pandora.c also needs support for
panel_tpo_td043mtea1_platform_data.
Yep, there's still much to do for DSS DT support. Hopefully it will be
easier now that the core support is there. I'll continue working on the
remaining boards and panels. However, I don't have any of the remaining
boards, so help is of course appreciated.
Tomi
From: Tony Lindgren <tony@atomide.com> Date: 2014-04-08 15:29:15
* Tomi Valkeinen [off-list ref] [140407 22:42]:
On 08/04/14 03:13, Tony Lindgren wrote:
quoted
Tomi,
* Tomi Valkeinen [off-list ref] [140121 03:01]:
quoted
Add DT support for panel-dpi.
Looks like this patch did not get merged or am I missing
something?
Yes, I dropped it. None of the boards that I converted used panel-dpi.
There was so much discussions about the display bindings, so I thought
it's better to leave out all but the needed patches.
OK
quoted
As you probably are aware, we have at least these boards
needing it before we can remove the omap3 legacy support:
board-am3517evm.c
board-cm-t35.c
board-devkit8000.c
board-ldp.c
board-overo.c
We could probably set the display timings based on the
compatible flag in the driver if that's an issue?
The timings shouldn't be an issue. But there's the backlight GPIO,
currently handled by panel-dpi, which should be removed from the panel.
We should use gpio-backlight for that one.
Using gpio-backlight makes sense for sure.
FYI, in the case of the LDP there are four GPIOs to configure to
get things going:
gpio55 LCD RESET panel-dpi?
gpio56 LCD QVGA panel-dpi?
twl gpio7 LCD power panel-dpi
twl gpio15 LCD backlight gpio-backlight
quoted
And then board-omap3pandora.c also needs support for
panel_tpo_td043mtea1_platform_data.
Yep, there's still much to do for DSS DT support. Hopefully it will be
easier now that the core support is there. I'll continue working on the
remaining boards and panels. However, I don't have any of the remaining
boards, so help is of course appreciated.
Yeah I can test at least the LDP here.
Regards,
Tony
From: Tony Lindgren <tony@atomide.com> Date: 2014-04-18 15:51:08
Hi,
Just trying to summarize what has been discussed so far in
various threads regarding changes needed to this patch.
* Tomi Valkeinen [off-list ref] [140121 03:01]:
@@ -182,6 +186,52 @@ static int panel_dpi_probe_pdata(struct platform_device *pdev)return0;}+staticintpanel_dpi_probe_of(structplatform_device*pdev)+{+structpanel_drv_data*ddata=platform_get_drvdata(pdev);+structdevice_node*node=pdev->dev.of_node;+structomap_dss_device*in;+intr;+structdisplay_timingtiming;+structvideomodevm;+intgpio;++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");+returngpio;+}
We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
gpio_backlight_probe_dt is doing.
Then do we really want to do the dev_err for each -EPROBE_DEFER here?
How about let's drop the backlight_gpio as discussed since it
can be handled with gpio-backlight?
Instead, let's add the panel specific reset_gpio as suggested by
Joachim. That seems common to some dpi using panels.
Then support for the other panel specific GPIOs can then be added
as a follow-up patch when we know how we want to handle them.
Oh, and this patch needs the related binding documentation too in
Documentation/devicetree/bindings.
Regards,
Tony
We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
gpio_backlight_probe_dt is doing.
Instead of doing it with the old gpio API, and checking the 'active'
flag everywhere, I think we can use the new gpiod API which handles the
polarity automatically.
I attached prototype patches (based on -rc2) for panel dpi using that
approach. It's a bit messier than I'd like, because for non-DT boot we
need to request the gpio using the old API, and then convert it to
gpio_desc. We can remove that code when all the boards use DT.
I've compiled tested this only, as I don't have DPI panels I could use.
I did try similar approach for TFP410, and it seemed to work fine.
Tomi
We should set the GPIO polarity based on the OF_GPIO_ACTIVE_LOW like
gpio_backlight_probe_dt is doing.
Instead of doing it with the old gpio API, and checking the 'active'
flag everywhere, I think we can use the new gpiod API which handles the
polarity automatically.
I attached prototype patches (based on -rc2) for panel dpi using that
approach. It's a bit messier than I'd like, because for non-DT boot we
need to request the gpio using the old API, and then convert it to
gpio_desc. We can remove that code when all the boards use DT.
I've compiled tested this only, as I don't have DPI panels I could use.
I did try similar approach for TFP410, and it seemed to work fine.
Got these working by updating my test patch to use enable-gpios instead
of gpios, and had to change from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH.
Are we now also breaking legacy booting by reversing the polarity?
In any case, looks like we have some duplicate panel code.. Turns
out most panel dpi users for omap3 board-*.c files are just
sharp-ls037v7dw01 panels but configured in QVGA mode. At least for
EVM and and LDP based on looking at the pictures and the configuration
pins (using the names kernel):
QVGA = lcd MO
reset = lcd RESB
...
Then the enable_gpio should be just a GPIO controlled 3.3V regulator
in most cases. I suggest we move them over to ls037v7dw01 and allow
configuring them both for VGA and QVGA depending on the orientation.
I guess you do have some device with ls037v7dw01 since you've been
patching it?
Regards,
Tony