From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:36
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's the
first set of patches from that ordeal. There's nothing DT specific in these
patches, but they are mostly generic cleanups that make sense even without DT.
This is the second version of these patches, the previous version can be found
from: http://www.spinics.net/lists/linux-fbdev/msg05667.html
The first 21 patches, which were in the previous version, have only gotten
minor cleanups (and, of course, more testing). The last 4 patches are new. The
most important of those patches is the DSI pin config patch, which makes it
possible for the panel driver to configure the DSI pins it needs.
This series can also be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base
Tomi
Tomi Valkeinen (25):
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi -> tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: TFP410: pdata rewrite
OMAPDSS: DSI: use dsi_get_dsidev_id(dsidev) instead of dsidev->id
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: clean up the omapdss platform data mess
OMAPDSS: remove return from platform_driver_unreg
OMAPDSS: use platform_driver_probe for core/dispc/dss
OMAPDSS: create custom pdevs for DSS omap_devices
OMAPDSS: create DPI & SDI devices
OMAPDSS: create DPI & SDI drivers
OMAPDSS: remove uses of dss_runtime_get/put
OMAPDSS: handle output-driver reg/unreg more dynamically
OMAPDSS: move the creation of debugfs files
OMAPDSS: use platform_driver_probe for dsi/hdmi/rfbi/venc/dpi/sdi
OMAPDSS: add __init & __exit
OMAPFB: add __init & __exit
OMAPDSS: change default_device handling
OMAPDSS: interface drivers register their panel devices
OMAPDSS: init omap_dss_devices internally
OMAPDSS: DSI: implement generic DSI pin config
OMAPDSS: DSI: improve DSI module id handling
OMAPDSS: separate pdata based initialization
arch/arm/mach-omap2/board-3430sdp.c | 38 +--
arch/arm/mach-omap2/board-4430sdp.c | 37 +--
arch/arm/mach-omap2/board-am3517evm.c | 25 +-
arch/arm/mach-omap2/board-cm-t35.c | 30 +--
arch/arm/mach-omap2/board-devkit8000.c | 30 +--
arch/arm/mach-omap2/board-igep0020.c | 32 +--
arch/arm/mach-omap2/board-omap3beagle.c | 37 +--
arch/arm/mach-omap2/board-omap3evm.c | 29 +-
arch/arm/mach-omap2/board-omap3stalker.c | 29 +-
arch/arm/mach-omap2/board-omap4panda.c | 39 +--
arch/arm/mach-omap2/board-overo.c | 25 +-
arch/arm/mach-omap2/display.c | 175 ++++++++++--
drivers/video/omap2/displays/Kconfig | 8 +-
drivers/video/omap2/displays/Makefile | 2 +-
drivers/video/omap2/displays/panel-dvi.c | 363 -------------------------
drivers/video/omap2/displays/panel-taal.c | 22 ++
drivers/video/omap2/displays/panel-tfp410.c | 385 +++++++++++++++++++++++++++
drivers/video/omap2/dss/core.c | 239 ++++++++++-------
drivers/video/omap2/dss/dispc.c | 50 ++--
drivers/video/omap2/dss/display.c | 40 ---
drivers/video/omap2/dss/dpi.c | 68 +++--
drivers/video/omap2/dss/dsi.c | 281 ++++++++++---------
drivers/video/omap2/dss/dss.c | 44 ++-
drivers/video/omap2/dss/dss.h | 113 ++------
drivers/video/omap2/dss/hdmi.c | 86 +++---
drivers/video/omap2/dss/rfbi.c | 60 +++--
drivers/video/omap2/dss/sdi.c | 61 ++++-
drivers/video/omap2/dss/venc.c | 62 +++--
drivers/video/omap2/omapfb/omapfb-main.c | 9 +-
include/video/omap-panel-dvi.h | 37 ---
include/video/omap-panel-nokia-dsi.h | 3 +
include/video/omap-panel-tfp410.h | 35 +++
include/video/omapdss.h | 33 +--
33 files changed, 1220 insertions(+), 1307 deletions(-)
delete mode 100644 drivers/video/omap2/displays/panel-dvi.c
create mode 100644 drivers/video/omap2/displays/panel-tfp410.c
delete mode 100644 include/video/omap-panel-dvi.h
create mode 100644 include/video/omap-panel-tfp410.h
--
1.7.9.5
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:37
The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/displays/panel-dvi.c | 31 ++++++++++++++++++++++++++++++
include/video/omap-panel-dvi.h | 2 ++
2 files changed, 33 insertions(+)
@@ -244,13 +230,7 @@ static int devkit8000_twl_gpio_setup(struct device *dev,}/* gpio + 7 is "DVI_PD" (out, active low) */-devkit8000_dvi_device.reset_gpio=gpio+7;-ret=gpio_request_one(devkit8000_dvi_device.reset_gpio,-GPIOF_OUT_INIT_LOW,"DVI PowerDown");-if(ret<0){-devkit8000_dvi_device.reset_gpio=-EINVAL;-printk(KERN_ERR"Failed to request GPIO for DVI PowerDown\n");-}+dvi_panel.power_down_gpio=gpio+7;return0;}
@@ -448,18 +436,6 @@ struct omap_dss_device omap4_panda_dvi_device = {.channel=OMAP_DSS_CHANNEL_LCD2,};-int__initomap4_panda_dvi_init(void)-{-intr;--/* Requesting TFP410 DVI GPIO and disabling it, at bootup */-r=gpio_request_one(omap4_panda_dvi_device.reset_gpio,-GPIOF_OUT_INIT_LOW,"DVI PD");-if(r)-pr_err("Failed to get DVI powerdown GPIO\n");--returnr;-}staticstructgpiopanda_hdmi_gpios[]={{HDMI_GPIO_CT_CP_HPD,GPIOF_OUT_INIT_HIGH,"hdmi_gpio_ct_cp_hpd"},
@@ -0,0 +1,381 @@+/*+*TFP410DPI-to-DVIchip+*+*Copyright(C)2011TexasInstrumentsInc+*Author:TomiValkeinen<tomi.valkeinen@ti.com>+*+*Thisprogramisfreesoftware;youcanredistributeitand/ormodifyit+*underthetermsoftheGNUGeneralPublicLicenseversion2aspublishedby+*theFreeSoftwareFoundation.+*+*Thisprogramisdistributedinthehopethatitwillbeuseful,butWITHOUT+*ANYWARRANTY;withouteventheimpliedwarrantyofMERCHANTABILITYor+*FITNESSFORAPARTICULARPURPOSE.SeetheGNUGeneralPublicLicensefor+*moredetails.+*+*YoushouldhavereceivedacopyoftheGNUGeneralPublicLicensealongwith+*thisprogram.Ifnot,see<http://www.gnu.org/licenses/>.+*/++#include<linux/module.h>+#include<linux/slab.h>+#include<video/omapdss.h>+#include<linux/i2c.h>+#include<linux/gpio.h>+#include<drm/drm_edid.h>++#include<video/omap-panel-tfp410.h>++staticconststructomap_video_timingstfp410_default_timings={+.x_res=640,+.y_res=480,++.pixel_clock=23500,++.hfp=48,+.hsw=32,+.hbp=80,++.vfp=3,+.vsw=4,+.vbp=7,+};++structpanel_drv_data{+structomap_dss_device*dssdev;++structmutexlock;++intpd_gpio;+};++staticinlinestructtfp410_platform_data+*get_pdata(conststructomap_dss_device*dssdev)+{+returndssdev->data;+}++staticinttfp410_power_on(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+intr;++if(dssdev->state=OMAP_DSS_DISPLAY_ACTIVE)+return0;++r=omapdss_dpi_display_enable(dssdev);+if(r)+gotoerr0;++if(gpio_is_valid(ddata->pd_gpio))+gpio_set_value(ddata->pd_gpio,1);++return0;+err0:+returnr;+}++staticvoidtfp410_power_off(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++if(dssdev->state!=OMAP_DSS_DISPLAY_ACTIVE)+return;++if(gpio_is_valid(ddata->pd_gpio))+gpio_set_value(ddata->pd_gpio,0);++omapdss_dpi_display_disable(dssdev);+}++staticinttfp410_probe(structomap_dss_device*dssdev)+{+structtfp410_platform_data*pdata=get_pdata(dssdev);+structpanel_drv_data*ddata;+intr;++ddata=kzalloc(sizeof(*ddata),GFP_KERNEL);+if(!ddata)+return-ENOMEM;++dssdev->panel.timings=tfp410_default_timings;+dssdev->panel.config=OMAP_DSS_LCD_TFT;++ddata->dssdev=dssdev;+mutex_init(&ddata->lock);++if(pdata)+ddata->pd_gpio=pdata->power_down_gpio;+else+ddata->pd_gpio=-1;++if(gpio_is_valid(ddata->pd_gpio)){+r=gpio_request_one(ddata->pd_gpio,GPIOF_OUT_INIT_LOW,+"tfp410 pd");+if(r){+dev_err(&dssdev->dev,"Failed to request PD GPIO %d\n",+ddata->pd_gpio);+ddata->pd_gpio=-1;+}+}++dev_set_drvdata(&dssdev->dev,ddata);++return0;+}++staticvoid__exittfp410_remove(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++mutex_lock(&ddata->lock);++if(gpio_is_valid(ddata->pd_gpio))+gpio_free(ddata->pd_gpio);++dev_set_drvdata(&dssdev->dev,NULL);++mutex_unlock(&ddata->lock);++kfree(ddata);+}++staticinttfp410_enable(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+intr;++mutex_lock(&ddata->lock);++r=tfp410_power_on(dssdev);+if(r=0)+dssdev->state=OMAP_DSS_DISPLAY_ACTIVE;++mutex_unlock(&ddata->lock);++returnr;+}++staticvoidtfp410_disable(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++mutex_lock(&ddata->lock);++tfp410_power_off(dssdev);++dssdev->state=OMAP_DSS_DISPLAY_DISABLED;++mutex_unlock(&ddata->lock);+}++staticinttfp410_suspend(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++mutex_lock(&ddata->lock);++tfp410_power_off(dssdev);++dssdev->state=OMAP_DSS_DISPLAY_SUSPENDED;++mutex_unlock(&ddata->lock);++return0;+}++staticinttfp410_resume(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+intr;++mutex_lock(&ddata->lock);++r=tfp410_power_on(dssdev);+if(r=0)+dssdev->state=OMAP_DSS_DISPLAY_ACTIVE;++mutex_unlock(&ddata->lock);++returnr;+}++staticvoidtfp410_set_timings(structomap_dss_device*dssdev,+structomap_video_timings*timings)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++mutex_lock(&ddata->lock);+dpi_set_timings(dssdev,timings);+mutex_unlock(&ddata->lock);+}++staticvoidtfp410_get_timings(structomap_dss_device*dssdev,+structomap_video_timings*timings)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++mutex_lock(&ddata->lock);+*timings=dssdev->panel.timings;+mutex_unlock(&ddata->lock);+}++staticinttfp410_check_timings(structomap_dss_device*dssdev,+structomap_video_timings*timings)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+intr;++mutex_lock(&ddata->lock);+r=dpi_check_timings(dssdev,timings);+mutex_unlock(&ddata->lock);++returnr;+}+++staticinttfp410_ddc_read(structi2c_adapter*adapter,+unsignedchar*buf,u16count,u8offset)+{+intr,retries;++for(retries=3;retries>0;retries--){+structi2c_msgmsgs[]={+{+.addr=DDC_ADDR,+.flags=0,+.len=1,+.buf=&offset,+},{+.addr=DDC_ADDR,+.flags=I2C_M_RD,+.len=count,+.buf=buf,+}+};++r=i2c_transfer(adapter,msgs,2);+if(r=2)+return0;++if(r!=-EAGAIN)+break;+}++returnr<0?r:-EIO;+}++staticinttfp410_read_edid(structomap_dss_device*dssdev,+u8*edid,intlen)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+structtfp410_platform_data*pdata=get_pdata(dssdev);+structi2c_adapter*adapter;+intr,l,bytes_read;++mutex_lock(&ddata->lock);++if(pdata->i2c_bus_num=0){+r=-ENODEV;+gotoerr;+}++adapter=i2c_get_adapter(pdata->i2c_bus_num);+if(!adapter){+dev_err(&dssdev->dev,"Failed to get I2C adapter, bus %d\n",+pdata->i2c_bus_num);+r=-EINVAL;+gotoerr;+}++l=min(EDID_LENGTH,len);+r=tfp410_ddc_read(adapter,edid,l,0);+if(r)+gotoerr;++bytes_read=l;++/* if there are extensions, read second block */+if(len>EDID_LENGTH&&edid[0x7e]>0){+l=min(EDID_LENGTH,len-EDID_LENGTH);++r=tfp410_ddc_read(adapter,edid+EDID_LENGTH,+l,EDID_LENGTH);+if(r)+gotoerr;++bytes_read+=l;+}++mutex_unlock(&ddata->lock);++returnbytes_read;++err:+mutex_unlock(&ddata->lock);+returnr;+}++staticbooltfp410_detect(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+structtfp410_platform_data*pdata=get_pdata(dssdev);+structi2c_adapter*adapter;+unsignedcharout;+intr;++mutex_lock(&ddata->lock);++if(pdata->i2c_bus_num=0)+gotoout;++adapter=i2c_get_adapter(pdata->i2c_bus_num);+if(!adapter)+gotoout;++r=tfp410_ddc_read(adapter,&out,1,0);++mutex_unlock(&ddata->lock);++returnr=0;++out:+mutex_unlock(&ddata->lock);+returntrue;+}++staticstructomap_dss_drivertfp410_driver={+.probe=tfp410_probe,+.remove=__exit_p(tfp410_remove),++.enable=tfp410_enable,+.disable=tfp410_disable,+.suspend=tfp410_suspend,+.resume=tfp410_resume,++.set_timings=tfp410_set_timings,+.get_timings=tfp410_get_timings,+.check_timings=tfp410_check_timings,++.read_edid=tfp410_read_edid,+.detect=tfp410_detect,++.driver={+.name="tfp410",+.owner=THIS_MODULE,+},+};++staticint__inittfp410_init(void)+{+returnomap_dss_register_driver(&tfp410_driver);+}++staticvoid__exittfp410_exit(void)+{+omap_dss_unregister_driver(&tfp410_driver);+}++module_init(tfp410_init);+module_exit(tfp410_exit);+MODULE_LICENSE("GPL");
@@ -1,35 +0,0 @@-/*- * Header for TFP410 chip driver- *- * Copyright (C) 2011 Texas Instruments Inc- * Author: Tomi Valkeinen <tomi.valkeinen@ti.com>- *- * This program is free software; you can redistribute it and/or modify it- * under the terms of the GNU General Public License version 2 as published by- * the Free Software Foundation.- *- * This program is distributed in the hope that it will be useful, but WITHOUT- * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or- * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for- * more details.- *- * You should have received a copy of the GNU General Public License along with- * this program. If not, see <http://www.gnu.org/licenses/>.- */--#ifndef __OMAP_PANEL_TFP410_H-#define __OMAP_PANEL_TFP410_H--struct omap_dss_device;--/**- * struct tfp410_platform_data - panel driver configuration data- * @i2c_bus_num: i2c bus id for the panel- * @power_down_gpio: gpio number for PD pin (or -1 if not available)- */-struct tfp410_platform_data {- u16 i2c_bus_num;- int power_down_gpio;-};--#endif /* __OMAP_PANEL_TFP410_H */
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:41
To ease device tree adaptation in the future, rewrite TFP410 platform
data handling to be done inside probe(), so that probe() is the only
place where we need to handle the DT/pdata choice.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/displays/panel-tfp410.c | 72 ++++++++++++++-------------
1 file changed, 38 insertions(+), 34 deletions(-)
@@ -104,10 +100,15 @@ static int tfp410_probe(struct omap_dss_device *dssdev)ddata->dssdev=dssdev;mutex_init(&ddata->lock);-if(pdata)+if(dssdev->data){+structtfp410_platform_data*pdata=dssdev->data;+ddata->pd_gpio=pdata->power_down_gpio;-else+i2c_bus_num=pdata->i2c_bus_num;+}else{ddata->pd_gpio=-1;+i2c_bus_num=-1;+}if(gpio_is_valid(ddata->pd_gpio)){r=gpio_request_one(ddata->pd_gpio,GPIOF_OUT_INIT_LOW,
@@ -115,13 +116,31 @@ static int tfp410_probe(struct omap_dss_device *dssdev)if(r){dev_err(&dssdev->dev,"Failed to request PD GPIO %d\n",ddata->pd_gpio);-ddata->pd_gpio=-1;+returnr;}}+if(i2c_bus_num!=-1){+structi2c_adapter*adapter;++adapter=i2c_get_adapter(i2c_bus_num);+if(!adapter){+dev_err(&dssdev->dev,"Failed to get I2C adapter, bus %d\n",+i2c_bus_num);+r=-EINVAL;+gotoerr_i2c;+}++ddata->i2c_adapter=adapter;+}+dev_set_drvdata(&dssdev->dev,ddata);return0;+err_i2c:+if(gpio_is_valid(ddata->pd_gpio))+gpio_free(ddata->pd_gpio);+returnr;}staticvoid__exittfp410_remove(structomap_dss_device*dssdev)
@@ -269,27 +289,17 @@ static int tfp410_read_edid(struct omap_dss_device *dssdev,u8*edid,intlen){structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);-structtfp410_platform_data*pdata=get_pdata(dssdev);-structi2c_adapter*adapter;intr,l,bytes_read;mutex_lock(&ddata->lock);-if(pdata->i2c_bus_num=0){+if(!ddata->i2c_adapter){r=-ENODEV;gotoerr;}-adapter=i2c_get_adapter(pdata->i2c_bus_num);-if(!adapter){-dev_err(&dssdev->dev,"Failed to get I2C adapter, bus %d\n",-pdata->i2c_bus_num);-r=-EINVAL;-gotoerr;-}-l=min(EDID_LENGTH,len);-r=tfp410_ddc_read(adapter,edid,l,0);+r=tfp410_ddc_read(ddata->i2c_adapter,edid,l,0);if(r)gotoerr;
@@ -299,7 +309,7 @@ static int tfp410_read_edid(struct omap_dss_device *dssdev,if(len>EDID_LENGTH&&edid[0x7e]>0){l=min(EDID_LENGTH,len-EDID_LENGTH);-r=tfp410_ddc_read(adapter,edid+EDID_LENGTH,+r=tfp410_ddc_read(ddata->i2c_adapter,edid+EDID_LENGTH,l,EDID_LENGTH);if(r)gotoerr;
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:42
The DSI driver uses dsi_get_dsidev_id() to get the ID number for the DSI
instance. However, there were a few places where dsidev->id was used
instead of the function. Fix those places to use the function.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dsi.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:43
The reset GPIO for Taal panel driver is currently requested in the
4430sdp board file. This patch moves the gpio request/free into the Taal
driver, where it should be.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/board-4430sdp.c | 16 ----------------
drivers/video/omap2/displays/panel-taal.c | 15 +++++++++++++++
2 files changed, 15 insertions(+), 16 deletions(-)
@@ -758,21 +758,6 @@ static struct omap_dss_device sdp4430_lcd2_device = {.channel=OMAP_DSS_CHANNEL_LCD2,};-staticvoidsdp4430_lcd_init(void)-{-intr;--r=gpio_request_one(dsi1_panel.reset_gpio,GPIOF_DIR_OUT,-"lcd1_reset_gpio");-if(r)-pr_err("%s: Could not get lcd1_reset_gpio\n",__func__);--r=gpio_request_one(dsi2_panel.reset_gpio,GPIOF_DIR_OUT,-"lcd2_reset_gpio");-if(r)-pr_err("%s: Could not get lcd2_reset_gpio\n",__func__);-}-staticstructomap_dss_hdmi_datasdp4430_hdmi_data={.hpd_gpio=HDMI_GPIO_HPD,};
@@ -858,7 +843,6 @@ static void __init omap_4430sdp_display_init(void)if(r)pr_err("%s: Could not get display_sel GPIO\n",__func__);-sdp4430_lcd_init();sdp4430_picodlp_init();omap_display_init(&sdp4430_dss_data);/*
@@ -1030,6 +1042,9 @@ static void __exit taal_remove(struct omap_dss_device *dssdev)/* reset, to be sure that the panel is in a valid state */taal_hw_reset(dssdev);+if(gpio_is_valid(panel_data->reset_gpio))+gpio_free(panel_data->reset_gpio);+kfree(td);}
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:44
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/display.c | 39 +++++++++++++++++++--------------------
drivers/video/omap2/dss/core.c | 35 +++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dispc.c | 21 ++-------------------
drivers/video/omap2/dss/dsi.c | 17 +++--------------
drivers/video/omap2/dss/dss.h | 3 +++
drivers/video/omap2/dss/hdmi.c | 2 --
include/video/omapdss.h | 5 -----
7 files changed, 62 insertions(+), 60 deletions(-)
@@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)structomap_hwmod*oh;structplatform_device*pdev;inti,oh_count;-structomap_display_platform_datapdata;conststructomap_dss_hwmod_data*curr_dss_hwmod;-memset(&pdata,0,sizeof(pdata));+/* create omapdss device */++board_data->dsi_enable_pads=omap_dsi_enable_pads;+board_data->dsi_disable_pads=omap_dsi_disable_pads;+board_data->get_context_loss_count=omap_pm_get_dev_context_loss_count;+board_data->set_min_bus_tput=omap_dss_set_min_bus_tput;++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 devices for dss hwmods */if(cpu_is_omap24xx()){curr_dss_hwmod=omap2_dss_hwmod_data;
@@ -207,16 +221,6 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)oh_count=ARRAY_SIZE(omap4_dss_hwmod_data);}-if(board_data->dsi_enable_pads=NULL)-board_data->dsi_enable_pads=omap_dsi_enable_pads;-if(board_data->dsi_disable_pads=NULL)-board_data->dsi_disable_pads=omap_dsi_disable_pads;--pdata.board_data=board_data;-pdata.board_data->get_context_loss_count-omap_pm_get_dev_context_loss_count;-pdata.board_data->set_min_bus_tput=omap_dss_set_min_bus_tput;-for(i=0;i<oh_count;i++){oh=omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);if(!oh){
@@ -226,21 +230,16 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)}pdev=omap_device_build(curr_dss_hwmod[i].dev_name,-curr_dss_hwmod[i].id,oh,&pdata,-sizeof(structomap_display_platform_data),+curr_dss_hwmod[i].id,oh,+NULL,0,NULL,0,0);if(WARN((IS_ERR(pdev)),"Could not build omap_device for %s\n",curr_dss_hwmod[i].oh_name))return-ENODEV;}-omap_display_device.dev.platform_data=board_data;-r=platform_device_register(&omap_display_device);-if(r<0)-printk(KERN_ERR"Unable to register OMAP-Display device\n");--returnr;+return0;}staticvoiddispc_disable_outputs(void)
@@ -317,11 +317,6 @@ extern int omap_display_init(struct omap_dss_board_info *board_data);/* HDMI mux init*/externintomap_hdmi_init(enumomap_hdmi_flagsflags);-structomap_display_platform_data{-structomap_dss_board_info*board_data;-/* TODO: Additional members to be added when PM is considered */-};-structomap_video_timings{/* Unit: pixels */u16x_res;
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:45
For unknown reasons we seem to have a return in each of the omapdss's
uninit functions, which is a void function.
Remove the returns.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dispc.c | 2 +-
drivers/video/omap2/dss/dsi.c | 2 +-
drivers/video/omap2/dss/dss.c | 2 +-
drivers/video/omap2/dss/hdmi.c | 2 +-
drivers/video/omap2/dss/rfbi.c | 2 +-
drivers/video/omap2/dss/venc.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:46
The platform devices for omapdss, dss and dispc drivers are always
present, so we can use platform_driver_probe instead of
platform_driver_register.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/core.c | 3 +--
drivers/video/omap2/dss/dispc.c | 3 +--
drivers/video/omap2/dss/dss.c | 3 +--
3 files changed, 3 insertions(+), 6 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:47
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/display.c | 88 ++++++++++++++++++++++++++++++++++-------
1 file changed, 74 insertions(+), 14 deletions(-)
@@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)returnomap_pm_set_min_bus_tput(dev,OCP_INITIATOR_AGENT,tput);}+staticstructplatform_device*create_dss_pdev(constchar*pdev_name,+intpdev_id,constchar*oh_name,void*pdata,intpdata_len,+structplatform_device*parent)+{+structplatform_device*pdev;+structomap_device*od;+structomap_hwmod*ohs[1];+structomap_hwmod*oh;+intr;++oh=omap_hwmod_lookup(oh_name);+if(!oh){+pr_err("Could not look up %s\n",oh_name);+r=-ENODEV;+gotoerr;+}++pdev=platform_device_alloc(pdev_name,pdev_id);+if(!pdev){+pr_err("Could not create pdev for %s\n",pdev_name);+r=-ENOMEM;+gotoerr;+}++if(parent!=NULL)+pdev->dev.parent=&parent->dev;++if(pdev->id!=-1)+dev_set_name(&pdev->dev,"%s.%d",pdev->name,pdev->id);+else+dev_set_name(&pdev->dev,"%s",pdev->name);++ohs[0]=oh;+od=omap_device_alloc(pdev,ohs,1,NULL,0);+if(!od){+pr_err("Could not alloc omap_device for %s\n",pdev_name);+r=-ENOMEM;+gotoerr;+}++r=platform_device_add_data(pdev,pdata,pdata_len);+if(r){+pr_err("Could not set pdata for %s\n",pdev_name);+gotoerr;+}++r=omap_device_register(pdev);+if(r){+pr_err("Could not register omap_device for %s\n",pdev_name);+gotoerr;+}++returnpdev;++err:+returnERR_PTR(r);+}+int__initomap_display_init(structomap_dss_board_info*board_data){intr=0;-structomap_hwmod*oh;structplatform_device*pdev;inti,oh_count;conststructomap_dss_hwmod_data*curr_dss_hwmod;+structplatform_device*dss_pdev;/* create omapdss device */
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)oh_count=ARRAY_SIZE(omap4_dss_hwmod_data);}-for(i=0;i<oh_count;i++){-oh=omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);-if(!oh){-pr_err("Could not look up %s\n",-curr_dss_hwmod[i].oh_name);-return-ENODEV;-}+dss_pdev=NULL;-pdev=omap_device_build(curr_dss_hwmod[i].dev_name,-curr_dss_hwmod[i].id,oh,+for(i=0;i<oh_count;i++){+pdev=create_dss_pdev(curr_dss_hwmod[i].dev_name,+curr_dss_hwmod[i].id,+curr_dss_hwmod[i].oh_name,NULL,0,-NULL,0,0);+dss_pdev);++if(IS_ERR(pdev)){+pr_err("Could not build omap_device for %s\n",+curr_dss_hwmod[i].oh_name);++returnPTR_ERR(pdev);+}-if(WARN((IS_ERR(pdev)),"Could not build omap_device for %s\n",-curr_dss_hwmod[i].oh_name))-return-ENODEV;+if(i=0)+dss_pdev=pdev;}return0;
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:48
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI & SDI somehow differently than the rest would just make the
code more complex.
This patch modifies arch/arm/mach-omap2/display.c to create platform
devices for DPI and SDI, and later patches will implement driver for
them.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/display.c | 57 +++++++++++++++++++++++++++++++++++++++++
1 file changed, 57 insertions(+)
@@ -243,6 +243,46 @@ err:returnERR_PTR(r);}+staticstructplatform_device*create_simple_dss_pdev(constchar*pdev_name,+intpdev_id,void*pdata,intpdata_len,+structplatform_device*parent)+{+structplatform_device*pdev;+intr;++pdev=platform_device_alloc(pdev_name,pdev_id);+if(!pdev){+pr_err("Could not create pdev for %s\n",pdev_name);+r=-ENOMEM;+gotoerr;+}++if(parent!=NULL)+pdev->dev.parent=&parent->dev;++if(pdev->id!=-1)+dev_set_name(&pdev->dev,"%s.%d",pdev->name,pdev->id);+else+dev_set_name(&pdev->dev,"%s",pdev->name);++r=platform_device_add_data(pdev,pdata,pdata_len);+if(r){+pr_err("Could not set pdata for %s\n",pdev_name);+gotoerr;+}++r=omap_device_register(pdev);+if(r){+pr_err("Could not register omap_device for %s\n",pdev_name);+gotoerr;+}++returnpdev;++err:+returnERR_PTR(r);+}+int__initomap_display_init(structomap_dss_board_info*board_data){intr=0;
@@ -299,6 +339,23 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)dss_pdev=pdev;}+/* Create devices for DPI and SDI */++pdev=create_simple_dss_pdev("omapdss_dpi",-1,NULL,0,dss_pdev);+if(IS_ERR(pdev)){+pr_err("Could not build platform_device for omapdss_dpi\n");+returnPTR_ERR(pdev);+}++if(cpu_is_omap34xx()){+pdev=create_simple_dss_pdev("omapdss_sdi",-1,NULL,0,+dss_pdev);+if(IS_ERR(pdev)){+pr_err("Could not build platform_device for omapdss_sdi\n");+returnPTR_ERR(pdev);+}+}+return0;}
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:49
We currently have separate device/driver for each DSS HW module. The DPI
and SDI outputs are more or less parts of the DSS or DISPC hardware
modules, but in SW it makes sense to represent them as device/driver
pairs similarly to all the other outputs. This also makes sense for
device tree, as each node under dss will be a platform device, and
handling DPI & SDI somehow differently than the rest would just make the
code more complex.
This patch modifies the dpi.c and sdi.c to create drivers for the
platform devices.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/core.c | 18 ++++++++++++++++++
drivers/video/omap2/dss/dpi.c | 23 +++++++++++++++++++++--
drivers/video/omap2/dss/dss.c | 20 +-------------------
drivers/video/omap2/dss/dss.h | 26 ++++++++------------------
drivers/video/omap2/dss/sdi.c | 25 +++++++++++++++++++++++--
5 files changed, 71 insertions(+), 41 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:50
Now that the omapdss_core device is the parent for all other dss
devices, we don't need to use the dss_runtime_get/put anymore. Instead,
enabling omapdss_core will happen automatically when a child device is
enabled.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dispc.c | 7 -------
drivers/video/omap2/dss/dpi.c | 16 +---------------
drivers/video/omap2/dss/dsi.c | 12 +-----------
drivers/video/omap2/dss/dss.c | 7 +++++--
drivers/video/omap2/dss/dss.h | 3 ---
drivers/video/omap2/dss/hdmi.c | 34 ++--------------------------------
drivers/video/omap2/dss/rfbi.c | 12 +-----------
drivers/video/omap2/dss/sdi.c | 7 -------
drivers/video/omap2/dss/venc.c | 12 +-----------
9 files changed, 11 insertions(+), 99 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:51
Initialize and uninitialize the output drivers by using arrays of
pointers to the init/uninit functions. This simplifies the code
slightly.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/core.c | 111 +++++++++++++++++++++-------------------
drivers/video/omap2/dss/dss.h | 41 ---------------
2 files changed, 59 insertions(+), 93 deletions(-)
@@ -454,13 +437,6 @@ void venc_dump_regs(struct seq_file *s);intvenc_init_display(structomap_dss_device*display);unsignedlongvenc_get_pixel_clock(void);#else-staticinlineintvenc_init_platform_driver(void)-{-return0;-}-staticinlinevoidvenc_uninit_platform_driver(void)-{-}staticinlineunsignedlongvenc_get_pixel_clock(void){WARN("%s: VENC not compiled in, returning pclk as 0\n",__func__);
@@ -480,13 +456,6 @@ static inline int hdmi_init_display(struct omap_dss_device *dssdev){return0;}-staticinlineinthdmi_init_platform_driver(void)-{-return0;-}-staticinlinevoidhdmi_uninit_platform_driver(void)-{-}staticinlineunsignedlonghdmi_get_pixel_clock(void){WARN("%s: HDMI not compiled in, returning pclk as 0\n",__func__);
@@ -504,20 +473,10 @@ int hdmi_panel_init(void);voidhdmi_panel_exit(void);/* RFBI */-#ifdef CONFIG_OMAP2_DSS_RFBIintrfbi_init_platform_driver(void);voidrfbi_uninit_platform_driver(void);voidrfbi_dump_regs(structseq_file*s);intrfbi_init_display(structomap_dss_device*display);-#else-staticinlineintrfbi_init_platform_driver(void)-{-return0;-}-staticinlinevoidrfbi_uninit_platform_driver(void)-{-}-#endif#ifdef CONFIG_OMAP2_DSS_COLLECT_IRQ_STATS
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:52
Instead of having an ugly #ifdef mess in the core.c for creating debugfs
files, add a dss_debugfs_create_file() function that the dss drivers
can use to create the debugfs files.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/core.c | 46 +++++++++++++++------------------------
drivers/video/omap2/dss/dispc.c | 7 +++++-
drivers/video/omap2/dss/dsi.c | 42 ++++++++++-------------------------
drivers/video/omap2/dss/dss.c | 4 +++-
drivers/video/omap2/dss/dss.h | 11 +---------
drivers/video/omap2/dss/hdmi.c | 4 +++-
drivers/video/omap2/dss/rfbi.c | 4 +++-
drivers/video/omap2/dss/venc.c | 4 +++-
8 files changed, 48 insertions(+), 74 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:53
Now that the core.c doesn't fail if output driver's init fails, we can
change the uses of platform_driver_register to platform_driver_probe.
This will allow us to use __init in the following patches.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dpi.c | 3 +--
drivers/video/omap2/dss/dsi.c | 3 +--
drivers/video/omap2/dss/hdmi.c | 3 +--
drivers/video/omap2/dss/rfbi.c | 3 +--
drivers/video/omap2/dss/sdi.c | 3 +--
drivers/video/omap2/dss/venc.c | 3 +--
6 files changed, 6 insertions(+), 12 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:56
We currently have a two ways to set a "default panel device" for dss, to
which the overlays are connected when the omapdss driver is loaded:
- in textual format (name of the display) as cmdline parameter
- as a pointer to the panel device from board file via pdata
The current code handles this in a bit too complex way by using both of
the above methods during runtime. However, with DT we don't have pdata
anymore, so the code handling the second case won't work anymore. The
current code has also the problem that it modifies the platform_data.
This patch simplifies the code a bit by using the pointer method only
inside the probe function, and stores the name of the panel device. This
way we only need to handle the textual format during operation and also
avoid modifying the platform_data.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/core.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:57
Currently the higher level omapdss platform driver gets the list of
displays in its platform data, and uses that list to create the
omap_dss_device for each display.
With DT, the logical way to do the above is to list the displays under
each individual output, i.e. we'd have "dpi" node, under which we would
have the display that uses DPI. In other words, each output driver
handles the displays that use that particular output.
To make the current code ready for DT, this patch modifies the output
drivers so that each of them creates the display devices which use that
output. However, instead of changing the platform data to suit this
method, each output driver is passed the full list of displays, and the
drivers pick the displays that are meant for them. This allows us to
keep the old platform data, and thus we avoid the need to change the
board files.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/display.c | 9 ++++----
drivers/video/omap2/dss/core.c | 46 ++++++++++++++--------------------------
drivers/video/omap2/dss/dpi.c | 17 +++++++++++++++
drivers/video/omap2/dss/dsi.c | 18 ++++++++++++++++
drivers/video/omap2/dss/dss.h | 5 +++++
drivers/video/omap2/dss/hdmi.c | 17 ++++++++++++++-
drivers/video/omap2/dss/rfbi.c | 16 +++++++++++++-
drivers/video/omap2/dss/sdi.c | 17 +++++++++++++++
drivers/video/omap2/dss/venc.c | 18 +++++++++++++++-
9 files changed, 126 insertions(+), 37 deletions(-)
@@ -325,7 +325,7 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)pdev=create_dss_pdev(curr_dss_hwmod[i].dev_name,curr_dss_hwmod[i].id,curr_dss_hwmod[i].oh_name,-NULL,0,+board_data,sizeof(*board_data),dss_pdev);if(IS_ERR(pdev)){
@@ -341,15 +341,16 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)/* Create devices for DPI and SDI */-pdev=create_simple_dss_pdev("omapdss_dpi",-1,NULL,0,dss_pdev);+pdev=create_simple_dss_pdev("omapdss_dpi",-1,+board_data,sizeof(*board_data),dss_pdev);if(IS_ERR(pdev)){pr_err("Could not build platform_device for omapdss_dpi\n");returnPTR_ERR(pdev);}if(cpu_is_omap34xx()){-pdev=create_simple_dss_pdev("omapdss_sdi",-1,NULL,0,-dss_pdev);+pdev=create_simple_dss_pdev("omapdss_sdi",-1,+board_data,sizeof(*board_data),dss_pdev);if(IS_ERR(pdev)){pr_err("Could not build platform_device for omapdss_sdi\n");returnPTR_ERR(pdev);
@@ -446,13 +442,8 @@ static inline unsigned long venc_get_pixel_clock(void)#ifdef CONFIG_OMAP4_DSS_HDMIinthdmi_init_platform_driver(void)__init;voidhdmi_uninit_platform_driver(void)__exit;-inthdmi_init_display(structomap_dss_device*dssdev);unsignedlonghdmi_get_pixel_clock(void);#else-staticinlineinthdmi_init_display(structomap_dss_device*dssdev)-{-return0;-}staticinlineunsignedlonghdmi_get_pixel_clock(void){WARN("%s: HDMI not compiled in, returning pclk as 0\n",__func__);
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:57:59
In preparation for device tree, this patch changes how the DSI pins are
configured. The current configuration method is only doable with board
files and the configuration data is OMAP specific.
This patch moves the configuration data to the panel's platform data,
and the data can easily be given via DT in the future. The configuration
data format is also changed to a generic one which should be suitable
for all platforms.
The new format is an array of pin numbers, where the array items start
from clock + and -, then data1 + and -, and so on. For example:
{
0, // pin num for clock lane +
1, // pin num for clock lane -
2, // pin num for data1 lane +
3, // pin num for data1 lane -
...
}
The pin numbers are translated by the DSI driver and used to configure
the hardware appropriately.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/board-4430sdp.c | 21 ++---
drivers/video/omap2/displays/panel-taal.c | 7 ++
drivers/video/omap2/dss/dsi.c | 133 +++++++++++++++--------------
include/video/omap-panel-nokia-dsi.h | 3 +
include/video/omapdss.h | 28 +++---
5 files changed, 103 insertions(+), 89 deletions(-)
@@ -464,6 +464,21 @@ struct omap_overlay_manager {int(*wait_for_vsync)(structomap_overlay_manager*mgr);};+/* 22 pins means 1 clk lane and 10 data lanes */+#define OMAP_DSS_MAX_DSI_PINS 22++structomap_dsi_pin_config{+intnum_pins;+/*+*pinnumbersinthefollowingorder:+*clk+,clk-+*data1+,data1-+*data2+,data2-+*...+*/+intpins[OMAP_DSS_MAX_DSI_PINS];+};+structomap_dss_device{structdevicedev;
@@ -685,6 +689,8 @@ int omap_dsi_update(struct omap_dss_device *dssdev, int channel,intomap_dsi_request_vc(structomap_dss_device*dssdev,int*channel);intomap_dsi_set_vc_id(structomap_dss_device*dssdev,intchannel,intvc_id);voidomap_dsi_release_vc(structomap_dss_device*dssdev,intchannel);+intomapdss_dsi_configure_pins(structomap_dss_device*dssdev,+conststructomap_dsi_pin_config*pin_cfg);intomapdss_dsi_display_enable(structomap_dss_device*dssdev);voidomapdss_dsi_display_disable(structomap_dss_device*dssdev,
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:58:00
We currently use the id of the dsi platform device (dsidev->id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.
Instead of using dsidev->id during operation, this patch stores the
value of dsidev->id to a private field of the dsi driver at probe(). The
future device tree code can thus set the private field with some other
way.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dsi.c | 46 +++++++++++++++++++----------------------
1 file changed, 21 insertions(+), 25 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2012-05-03 13:58:01
Move the platform-data based display device initialization into a
separate function, so that we may later add of-based initialization.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dpi.c | 7 +++++-
drivers/video/omap2/dss/dsi.c | 50 +++++++++++++++++++++++-----------------
drivers/video/omap2/dss/hdmi.c | 46 +++++++++++++++++++++---------------
drivers/video/omap2/dss/rfbi.c | 45 +++++++++++++++++++++---------------
drivers/video/omap2/dss/sdi.c | 7 +++++-
drivers/video/omap2/dss/venc.c | 45 +++++++++++++++++++++---------------
6 files changed, 120 insertions(+), 80 deletions(-)
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted hunk
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinen<redacted>
---
arch/arm/mach-omap2/display.c | 39 +++++++++++++++++++--------------------
drivers/video/omap2/dss/core.c | 35 +++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dispc.c | 21 ++-------------------
drivers/video/omap2/dss/dsi.c | 17 +++--------------
drivers/video/omap2/dss/dss.h | 3 +++
drivers/video/omap2/dss/hdmi.c | 2 --
include/video/omapdss.h | 5 -----
7 files changed, 62 insertions(+), 60 deletions(-)
@@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)structomap_hwmod*oh;structplatform_device*pdev;inti,oh_count;-structomap_display_platform_datapdata;conststructomap_dss_hwmod_data*curr_dss_hwmod;-memset(&pdata,0,sizeof(pdata));+/* create omapdss device */++board_data->dsi_enable_pads=omap_dsi_enable_pads;+board_data->dsi_disable_pads=omap_dsi_disable_pads;+board_data->get_context_loss_count=omap_pm_get_dev_context_loss_count;+board_data->set_min_bus_tput=omap_dss_set_min_bus_tput;++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;+}
After this patch, the "omapdss" platform device is registered before the
other dss platform devices. This would change the sequence of probes of
these devices. Was this intentional?
Archit
quoted hunk
++ /* create devices for dss hwmods */ if (cpu_is_omap24xx()) { curr_dss_hwmod = omap2_dss_hwmod_data;
@@ -207,16 +221,6 @@ int __init omap_display_init(struct omap_dss_board_info *board_data) oh_count = ARRAY_SIZE(omap4_dss_hwmod_data); }- if (board_data->dsi_enable_pads = NULL)- board_data->dsi_enable_pads = omap_dsi_enable_pads;- if (board_data->dsi_disable_pads = NULL)- board_data->dsi_disable_pads = omap_dsi_disable_pads;-- pdata.board_data = board_data;- pdata.board_data->get_context_loss_count > - omap_pm_get_dev_context_loss_count;- pdata.board_data->set_min_bus_tput = omap_dss_set_min_bus_tput;- for (i = 0; i< oh_count; i++) { oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name); if (!oh) {
@@ -226,21 +230,16 @@ int __init omap_display_init(struct omap_dss_board_info *board_data) } pdev = omap_device_build(curr_dss_hwmod[i].dev_name,- curr_dss_hwmod[i].id, oh,&pdata,- sizeof(struct omap_display_platform_data),+ curr_dss_hwmod[i].id, oh,+ NULL, 0, NULL, 0, 0); if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n", curr_dss_hwmod[i].oh_name)) return -ENODEV; }- omap_display_device.dev.platform_data = board_data;- r = platform_device_register(&omap_display_device);- if (r< 0)- printk(KERN_ERR "Unable to register OMAP-Display device\n");-- return r;+ return 0; } static void dispc_disable_outputs(void)
@@ -317,11 +317,6 @@ extern int omap_display_init(struct omap_dss_board_info *board_data);/* HDMI mux init*/externintomap_hdmi_init(enumomap_hdmi_flagsflags);-structomap_display_platform_data{-structomap_dss_board_info*board_data;-/* TODO: Additional members to be added when PM is considered */-};-structomap_video_timings{/* Unit: pixels */u16x_res;
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted hunk
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinen<redacted>
---
arch/arm/mach-omap2/display.c | 88 ++++++++++++++++++++++++++++++++++-------
1 file changed, 74 insertions(+), 14 deletions(-)
@@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)returnomap_pm_set_min_bus_tput(dev,OCP_INITIATOR_AGENT,tput);}+staticstructplatform_device*create_dss_pdev(constchar*pdev_name,+intpdev_id,constchar*oh_name,void*pdata,intpdata_len,+structplatform_device*parent)
This function looks quite generic, it's like omap_device_build() but
with a parent associated. omap_device_build() seems to be a special case
of this function with parent passed as null. Won't this
function be needed by other devices too?
Maybe we could modify omap_device_build_ss() to take a parent argument,
and make a function called omap_device_build_parent(), where both
omap_device_build() and omap_device_build_parent() call
omap_device_build_ss()?
Archit
quoted hunk
+{+ struct platform_device *pdev;+ struct omap_device *od;+ struct omap_hwmod *ohs[1];+ struct omap_hwmod *oh;+ int r;++ oh = omap_hwmod_lookup(oh_name);+ if (!oh) {+ pr_err("Could not look up %s\n", oh_name);+ r = -ENODEV;+ goto err;+ }++ pdev = platform_device_alloc(pdev_name, pdev_id);+ if (!pdev) {+ pr_err("Could not create pdev for %s\n", pdev_name);+ r = -ENOMEM;+ goto err;+ }++ if (parent != NULL)+ pdev->dev.parent =&parent->dev;++ if (pdev->id != -1)+ dev_set_name(&pdev->dev, "%s.%d", pdev->name, pdev->id);+ else+ dev_set_name(&pdev->dev, "%s", pdev->name);++ ohs[0] = oh;+ od = omap_device_alloc(pdev, ohs, 1, NULL, 0);+ if (!od) {+ pr_err("Could not alloc omap_device for %s\n", pdev_name);+ r = -ENOMEM;+ goto err;+ }++ r = platform_device_add_data(pdev, pdata, pdata_len);+ if (r) {+ pr_err("Could not set pdata for %s\n", pdev_name);+ goto err;+ }++ r = omap_device_register(pdev);+ if (r) {+ pr_err("Could not register omap_device for %s\n", pdev_name);+ goto err;+ }++ return pdev;++err:+ return ERR_PTR(r);+}+ int __init omap_display_init(struct omap_dss_board_info *board_data) { int r = 0;- struct omap_hwmod *oh; struct platform_device *pdev; int i, oh_count; const struct omap_dss_hwmod_data *curr_dss_hwmod;+ struct platform_device *dss_pdev; /* create omapdss device */
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data) oh_count = ARRAY_SIZE(omap4_dss_hwmod_data); }- for (i = 0; i< oh_count; i++) {- oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);- if (!oh) {- pr_err("Could not look up %s\n",- curr_dss_hwmod[i].oh_name);- return -ENODEV;- }+ dss_pdev = NULL;- pdev = omap_device_build(curr_dss_hwmod[i].dev_name,- curr_dss_hwmod[i].id, oh,+ for (i = 0; i< oh_count; i++) {+ pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,+ curr_dss_hwmod[i].id,+ curr_dss_hwmod[i].oh_name, NULL, 0,- NULL, 0, 0);+ dss_pdev);++ if (IS_ERR(pdev)) {+ pr_err("Could not build omap_device for %s\n",+ curr_dss_hwmod[i].oh_name);++ return PTR_ERR(pdev);+ }- if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",- curr_dss_hwmod[i].oh_name))- return -ENODEV;+ if (i = 0)+ dss_pdev = pdev; } return 0;
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted hunk
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinen<redacted>
---
arch/arm/mach-omap2/display.c | 88 ++++++++++++++++++++++++++++++++++-------
1 file changed, 74 insertions(+), 14 deletions(-)
@@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)returnomap_pm_set_min_bus_tput(dev,OCP_INITIATOR_AGENT,tput);}+staticstructplatform_device*create_dss_pdev(constchar*pdev_name,+intpdev_id,constchar*oh_name,void*pdata,intpdata_len,+structplatform_device*parent)+{+structplatform_device*pdev;+structomap_device*od;+structomap_hwmod*ohs[1];+structomap_hwmod*oh;+intr;++oh=omap_hwmod_lookup(oh_name);+if(!oh){+pr_err("Could not look up %s\n",oh_name);+r=-ENODEV;+gotoerr;+}++pdev=platform_device_alloc(pdev_name,pdev_id);+if(!pdev){+pr_err("Could not create pdev for %s\n",pdev_name);+r=-ENOMEM;+gotoerr;+}++if(parent!=NULL)+pdev->dev.parent=&parent->dev;++if(pdev->id!=-1)+dev_set_name(&pdev->dev,"%s.%d",pdev->name,pdev->id);+else+dev_set_name(&pdev->dev,"%s",pdev->name);++ohs[0]=oh;+od=omap_device_alloc(pdev,ohs,1,NULL,0);+if(!od){+pr_err("Could not alloc omap_device for %s\n",pdev_name);+r=-ENOMEM;+gotoerr;+}++r=platform_device_add_data(pdev,pdata,pdata_len);+if(r){+pr_err("Could not set pdata for %s\n",pdev_name);+gotoerr;+}++r=omap_device_register(pdev);+if(r){+pr_err("Could not register omap_device for %s\n",pdev_name);+gotoerr;+}++returnpdev;++err:+returnERR_PTR(r);+}+int__initomap_display_init(structomap_dss_board_info*board_data){intr=0;-structomap_hwmod*oh;structplatform_device*pdev;inti,oh_count;conststructomap_dss_hwmod_data*curr_dss_hwmod;+structplatform_device*dss_pdev;/* create omapdss device */
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)oh_count=ARRAY_SIZE(omap4_dss_hwmod_data);}-for(i=0;i<oh_count;i++){-oh=omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);-if(!oh){-pr_err("Could not look up %s\n",-curr_dss_hwmod[i].oh_name);-return-ENODEV;-}+dss_pdev=NULL;-pdev=omap_device_build(curr_dss_hwmod[i].dev_name,-curr_dss_hwmod[i].id,oh,+for(i=0;i<oh_count;i++){+pdev=create_dss_pdev(curr_dss_hwmod[i].dev_name,+curr_dss_hwmod[i].id,+curr_dss_hwmod[i].oh_name,NULL,0,-NULL,0,0);+dss_pdev);++if(IS_ERR(pdev)){+pr_err("Could not build omap_device for %s\n",+curr_dss_hwmod[i].oh_name);++returnPTR_ERR(pdev);+}-if(WARN((IS_ERR(pdev)),"Could not build omap_device for %s\n",-curr_dss_hwmod[i].oh_name))-return-ENODEV;+if(i=0)+dss_pdev=pdev;
The above line is a bit tricky to understand, maybe something like this
may explain the parent-child setting better:
if (!strcmp(curr_dss_hwmod[i].oh_name, "dss_core"))
dss_pdev = pdev;
I had another general question about the parent-child series. What is
the use of the platform device omap_display_device (with the name
"omapdss"). Is it just a way to get the board data?
Archit
From: Tomi Valkeinen <hidden> Date: 2012-05-04 08:32:00
On Fri, 2012-05-04 at 11:02 +0530, Archit Taneja wrote:
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinen<redacted>
---
arch/arm/mach-omap2/display.c | 39 +++++++++++++++++++--------------------
drivers/video/omap2/dss/core.c | 35 +++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dispc.c | 21 ++-------------------
drivers/video/omap2/dss/dsi.c | 17 +++--------------
drivers/video/omap2/dss/dss.h | 3 +++
drivers/video/omap2/dss/hdmi.c | 2 --
include/video/omapdss.h | 5 -----
7 files changed, 62 insertions(+), 60 deletions(-)
@@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)structomap_hwmod*oh;structplatform_device*pdev;inti,oh_count;-structomap_display_platform_datapdata;conststructomap_dss_hwmod_data*curr_dss_hwmod;-memset(&pdata,0,sizeof(pdata));+/* create omapdss device */++board_data->dsi_enable_pads=omap_dsi_enable_pads;+board_data->dsi_disable_pads=omap_dsi_disable_pads;+board_data->get_context_loss_count=omap_pm_get_dev_context_loss_count;+board_data->set_min_bus_tput=omap_dss_set_min_bus_tput;++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;+}
After this patch, the "omapdss" platform device is registered before the
other dss platform devices. This would change the sequence of probes of
these devices. Was this intentional?
Hmm. The sequence shouldn't change. The order in which the devices are
registered doesn't matter if there are no drivers registered yet. When
the drivers are registered, and there's a device for it, the probe will
be done. So in this case the order of the driver registration will
dictate the order of probes.
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-05-04 08:37:10
On Fri, 2012-05-04 at 11:33 +0530, Archit Taneja wrote:
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted
Instead of using omap_device_build() to create the omap_devices for DSS
hwmods, create them with a custom function. This will allow us to create
a parent-child hierarchy for the devices so that the omapdss_core device
is parent for the rest of the dss hwmod devices.
Signed-off-by: Tomi Valkeinen<redacted>
---
arch/arm/mach-omap2/display.c | 88 ++++++++++++++++++++++++++++++++++-------
1 file changed, 74 insertions(+), 14 deletions(-)
@@ -185,13 +185,71 @@ static int omap_dss_set_min_bus_tput(struct device *dev, unsigned long tput)returnomap_pm_set_min_bus_tput(dev,OCP_INITIATOR_AGENT,tput);}+staticstructplatform_device*create_dss_pdev(constchar*pdev_name,+intpdev_id,constchar*oh_name,void*pdata,intpdata_len,+structplatform_device*parent)
This function looks quite generic, it's like omap_device_build() but
with a parent associated. omap_device_build() seems to be a special case
of this function with parent passed as null. Won't this
function be needed by other devices too?
Maybe we could modify omap_device_build_ss() to take a parent argument,
and make a function called omap_device_build_parent(), where both
omap_device_build() and omap_device_build_parent() call
omap_device_build_ss()?
Yes, that sounds good to me.
Paul, Kevin, what do you think, could the omap_device functions be
extended to allow setting a parent device?
Tomi
On Friday 04 May 2012 02:02 PM, Tomi Valkeinen wrote:
On Fri, 2012-05-04 at 11:02 +0530, Archit Taneja wrote:
quoted
Hi,
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted
The omapdss pdata handling is a mess. This is more evident when trying
to use device tree for DSS, as we don't have platform data anymore in
that case. This patch cleans the pdata handling by:
- Remove struct omap_display_platform_data. It was used just as a
wrapper for struct omap_dss_board_info.
- Pass the platform data only to omapdss device. The drivers for omap
dss hwmods do not need the platform data. This should also work better
for DT, as we can create omapdss device programmatically in generic omap
boot code, and thus we can pass the pdata to it.
- Create dss functions for get_ctx_loss_count and dsi_enable/disable_pads
that the dss hwmod drivers can call.
Signed-off-by: Tomi Valkeinen<redacted>
---
arch/arm/mach-omap2/display.c | 39 +++++++++++++++++++--------------------
drivers/video/omap2/dss/core.c | 35 +++++++++++++++++++++++++++++++++++
drivers/video/omap2/dss/dispc.c | 21 ++-------------------
drivers/video/omap2/dss/dsi.c | 17 +++--------------
drivers/video/omap2/dss/dss.h | 3 +++
drivers/video/omap2/dss/hdmi.c | 2 --
include/video/omapdss.h | 5 -----
7 files changed, 62 insertions(+), 60 deletions(-)
@@ -191,10 +191,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data)structomap_hwmod*oh;structplatform_device*pdev;inti,oh_count;-structomap_display_platform_datapdata;conststructomap_dss_hwmod_data*curr_dss_hwmod;-memset(&pdata,0,sizeof(pdata));+/* create omapdss device */++board_data->dsi_enable_pads=omap_dsi_enable_pads;+board_data->dsi_disable_pads=omap_dsi_disable_pads;+board_data->get_context_loss_count=omap_pm_get_dev_context_loss_count;+board_data->set_min_bus_tput=omap_dss_set_min_bus_tput;++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;+}
After this patch, the "omapdss" platform device is registered before the
other dss platform devices. This would change the sequence of probes of
these devices. Was this intentional?
Hmm. The sequence shouldn't change. The order in which the devices are
registered doesn't matter if there are no drivers registered yet. When
the drivers are registered, and there's a device for it, the probe will
be done. So in this case the order of the driver registration will
dictate the order of probes.
Oh okay, I don't know where the initcalls exactly happen, but I guess
they will happen after the .init_machine op in the board file.
Do you know where the initcalls happen, I couldn't find it by browsing
the kernel code :)
Archit
From: Tomi Valkeinen <hidden> Date: 2012-05-04 08:49:47
On Fri, 2012-05-04 at 14:06 +0530, Archit Taneja wrote:
On Friday 04 May 2012 02:02 PM, Tomi Valkeinen wrote:
quoted
Hmm. The sequence shouldn't change. The order in which the devices are
registered doesn't matter if there are no drivers registered yet. When
the drivers are registered, and there's a device for it, the probe will
be done. So in this case the order of the driver registration will
dictate the order of probes.
Oh okay, I don't know where the initcalls exactly happen, but I guess
they will happen after the .init_machine op in the board file.
Do you know where the initcalls happen, I couldn't find it by browsing
the kernel code :)
Well, include/linux/init.h lists the inits in order. machine init is not
there, I guess it's not part of the init order, but even earlier.
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-05-04 09:00:06
On Fri, 2012-05-04 at 13:47 +0530, Archit Taneja wrote:
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data) oh_count = ARRAY_SIZE(omap4_dss_hwmod_data); }- for (i = 0; i< oh_count; i++) {- oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);- if (!oh) {- pr_err("Could not look up %s\n",- curr_dss_hwmod[i].oh_name);- return -ENODEV;- }+ dss_pdev = NULL;- pdev = omap_device_build(curr_dss_hwmod[i].dev_name,- curr_dss_hwmod[i].id, oh,+ for (i = 0; i< oh_count; i++) {+ pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,+ curr_dss_hwmod[i].id,+ curr_dss_hwmod[i].oh_name, NULL, 0,- NULL, 0, 0);+ dss_pdev);++ if (IS_ERR(pdev)) {+ pr_err("Could not build omap_device for %s\n",+ curr_dss_hwmod[i].oh_name);++ return PTR_ERR(pdev);+ }- if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",- curr_dss_hwmod[i].oh_name))- return -ENODEV;+ if (i == 0)+ dss_pdev = pdev;
The above line is a bit tricky to understand, maybe something like this
may explain the parent-child setting better:
if (!strcmp(curr_dss_hwmod[i].oh_name, "dss_core"))
dss_pdev = pdev;
I agree that it's a bit confusing. But your suggestion is not very good
either, as the code does not work properly if the dss_core is not the
first one created. I'll look into it. Perhaps I can separate the code
into a small function, and then I can more easily do something like:
dss_pdev = create_the_device();
for () {
// create the rest of the devices
create_the_device();
}
and that would clarify what's going on.
I had another general question about the parent-child series. What is
the use of the platform device omap_display_device (with the name
"omapdss"). Is it just a way to get the board data?
Originally, before hwmods, we had only omapdss device, which contained
all the dss code. Then came hwmods, and the omapdss was split into
smaller devices, but omapdss was still there.
As I see it, omapdss is currently a "virtual" higher level device
(virtual in the sense that it doesn't correspond directly to any HW),
and the code for omapdss is more or less in the core.c file. It's used
to pass the board data, but also has some generic dss stuff that all dss
subdevices can use.
I think in the long run we should remove omapdss device, and probably
handle the generic stuff in dss_core (dss.c), which, as a parent to
other subdevices, should fit fine for the role.
For the time being we can't remove it. It's the only simple way to pass
callbacks from the arch code with device tree.
Tomi
On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
We currently use the id of the dsi platform device (dsidev->id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.
If this number is arbitrary we would need to change the "dsi_pdev_map"
approach of mapping a dsi module and it's corresponding platform device.
Currently dsi_pdev_map is:
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
So we either need to increase the array size to take larger arbitrary
numbers, or do something else.
We would also need to fix the usage of dsi_get_dsidev_from_id(), as
right now we manually pass 0 and 1 to it only, for example:
static void dsi1_dump_irqs(struct seq_file *s)
{
struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
dsi_dump_dsidev_irqs(dsidev, s);
}
The immediate solution that comes to mind is to maintain 2 id's, one
which is sequential, and the other which the DT has created, and keep an
array to map these. But this seems messy!
Archit
quoted hunk
Instead of using dsidev->id during operation, this patch stores the
value of dsidev->id to a private field of the dsi driver at probe(). The
future device tree code can thus set the private field with some other
way.
Signed-off-by: Tomi Valkeinen<redacted>
---
drivers/video/omap2/dss/dsi.c | 46 +++++++++++++++++++----------------------
1 file changed, 21 insertions(+), 25 deletions(-)
On Friday 04 May 2012 02:30 PM, Tomi Valkeinen wrote:
On Fri, 2012-05-04 at 13:47 +0530, Archit Taneja wrote:
quoted
On Thursday 03 May 2012 07:27 PM, Tomi Valkeinen wrote:
quoted
quoted
@@ -221,22 +279,24 @@ int __init omap_display_init(struct omap_dss_board_info *board_data) oh_count = ARRAY_SIZE(omap4_dss_hwmod_data); }- for (i = 0; i< oh_count; i++) {- oh = omap_hwmod_lookup(curr_dss_hwmod[i].oh_name);- if (!oh) {- pr_err("Could not look up %s\n",- curr_dss_hwmod[i].oh_name);- return -ENODEV;- }+ dss_pdev = NULL;- pdev = omap_device_build(curr_dss_hwmod[i].dev_name,- curr_dss_hwmod[i].id, oh,+ for (i = 0; i< oh_count; i++) {+ pdev = create_dss_pdev(curr_dss_hwmod[i].dev_name,+ curr_dss_hwmod[i].id,+ curr_dss_hwmod[i].oh_name, NULL, 0,- NULL, 0, 0);+ dss_pdev);++ if (IS_ERR(pdev)) {+ pr_err("Could not build omap_device for %s\n",+ curr_dss_hwmod[i].oh_name);++ return PTR_ERR(pdev);+ }- if (WARN((IS_ERR(pdev)), "Could not build omap_device for %s\n",- curr_dss_hwmod[i].oh_name))- return -ENODEV;+ if (i = 0)+ dss_pdev = pdev;
The above line is a bit tricky to understand, maybe something like this
may explain the parent-child setting better:
if (!strcmp(curr_dss_hwmod[i].oh_name, "dss_core"))
dss_pdev = pdev;
I agree that it's a bit confusing. But your suggestion is not very good
either, as the code does not work properly if the dss_core is not the
first one created. I'll look into it. Perhaps I can separate the code
into a small function, and then I can more easily do something like:
Right, my suggestion wont work either.
dss_pdev = create_the_device();
for () {
// create the rest of the devices
create_the_device();
}
and that would clarify what's going on.
Yes, or you could just add a comment saying i = 0 is the dss_core
hwmod, and we make sure dss_core is the first one on the list.
quoted
I had another general question about the parent-child series. What is
the use of the platform device omap_display_device (with the name
"omapdss"). Is it just a way to get the board data?
Originally, before hwmods, we had only omapdss device, which contained
all the dss code. Then came hwmods, and the omapdss was split into
smaller devices, but omapdss was still there.
As I see it, omapdss is currently a "virtual" higher level device
(virtual in the sense that it doesn't correspond directly to any HW),
and the code for omapdss is more or less in the core.c file. It's used
to pass the board data, but also has some generic dss stuff that all dss
subdevices can use.
I think in the long run we should remove omapdss device, and probably
handle the generic stuff in dss_core (dss.c), which, as a parent to
other subdevices, should fit fine for the role.
For the time being we can't remove it. It's the only simple way to pass
callbacks from the arch code with device tree.
From: Tomi Valkeinen <hidden> Date: 2012-05-04 09:53:49
On Fri, 2012-05-04 at 14:39 +0530, Archit Taneja wrote:
On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
quoted
We currently use the id of the dsi platform device (dsidev->id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.
If this number is arbitrary we would need to change the "dsi_pdev_map"
approach of mapping a dsi module and it's corresponding platform device.
Currently dsi_pdev_map is:
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
So we either need to increase the array size to take larger arbitrary
numbers, or do something else.
We would also need to fix the usage of dsi_get_dsidev_from_id(), as
right now we manually pass 0 and 1 to it only, for example:
static void dsi1_dump_irqs(struct seq_file *s)
{
struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
dsi_dump_dsidev_irqs(dsidev, s);
}
The immediate solution that comes to mind is to maintain 2 id's, one
which is sequential, and the other which the DT has created, and keep an
array to map these. But this seems messy!
This is only a problem with device tree, and I solved it so that I pass
a DSI module ID in the device tree data. So, with old pdata way I
initialize dsi->module_id from the pdev->id, but with DT I initialize
dsi->module_id from the DT data.
So basically we remove the use of pdev->id in this patch, and add
dsi->module_id field, which needs to be initialized to 0 or 1, depending
on the corresponding HW module. We just happen to use the pdev->id to
initialize it when using the old pdata method, as we know it tells the
right id. But we could initialize it from any other source.
This allows us to keep the 0 and 1 DSI IDs, and I think we need those
anyway. Some parts of the code could work fine with arbitrary ID, as
long as a pdev can be linked to/from this ID. However, there are things
where we must have the ID, like configuring the clock source settings in
dss_core, where we set a certain bit for DSI module 0, and certain bit
for module 1.
Perhaps even those could be handled without explicit ID of 0 or 1, but
that doesn't sound trivial and I didn't want to start tackling that in
this series.
I wish there was a way to get the module ID from the HW registers
somehow. Then we wouldn't need to pass the ID via SW, which doesn't feel
very correct. At least with DT it's a bit wrong, in my opinion, but best
I could come up with.
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-05-04 10:11:50
On Fri, 2012-05-04 at 15:35 +0530, Archit Taneja wrote:
quoted
This is only a problem with device tree, and I solved it so that I
pass
quoted
a DSI module ID in the device tree data. So, with old pdata way I
initialize dsi->module_id from the pdev->id, but with DT I
initialize
quoted
dsi->module_id from the DT data.
Oh ok, so the code which decides how dsi->module_id is
initialised(from
DT or pdata) is not in this series right? And it would come later?
Right
now it's just set to dsidev->id in probe.
Yes, there's no DT code in this series, only cleanups to make adding DT
support easier.
Tomi
On Friday 04 May 2012 03:23 PM, Tomi Valkeinen wrote:
On Fri, 2012-05-04 at 14:39 +0530, Archit Taneja wrote:
quoted
On Thursday 03 May 2012 07:28 PM, Tomi Valkeinen wrote:
quoted
We currently use the id of the dsi platform device (dsidev->id) as the
DSI hardware module ID. This works because we assign the ID manually in
arch/arm/mach-omap2/display.c at boot time.
However, with device tree the platform device IDs are automatically
assigned to an arbitrary number, and we can't use it.
If this number is arbitrary we would need to change the "dsi_pdev_map"
approach of mapping a dsi module and it's corresponding platform device.
Currently dsi_pdev_map is:
static struct platform_device *dsi_pdev_map[MAX_NUM_DSI];
So we either need to increase the array size to take larger arbitrary
numbers, or do something else.
We would also need to fix the usage of dsi_get_dsidev_from_id(), as
right now we manually pass 0 and 1 to it only, for example:
static void dsi1_dump_irqs(struct seq_file *s)
{
struct platform_device *dsidev = dsi_get_dsidev_from_id(0);
dsi_dump_dsidev_irqs(dsidev, s);
}
The immediate solution that comes to mind is to maintain 2 id's, one
which is sequential, and the other which the DT has created, and keep an
array to map these. But this seems messy!
This is only a problem with device tree, and I solved it so that I pass
a DSI module ID in the device tree data. So, with old pdata way I
initialize dsi->module_id from the pdev->id, but with DT I initialize
dsi->module_id from the DT data.
Oh ok, so the code which decides how dsi->module_id is initialised(from
DT or pdata) is not in this series right? And it would come later? Right
now it's just set to dsidev->id in probe.
So basically we remove the use of pdev->id in this patch, and add
dsi->module_id field, which needs to be initialized to 0 or 1, depending
on the corresponding HW module. We just happen to use the pdev->id to
initialize it when using the old pdata method, as we know it tells the
right id. But we could initialize it from any other source.
Right, I get it now.
This allows us to keep the 0 and 1 DSI IDs, and I think we need those
anyway. Some parts of the code could work fine with arbitrary ID, as
long as a pdev can be linked to/from this ID. However, there are things
where we must have the ID, like configuring the clock source settings in
dss_core, where we set a certain bit for DSI module 0, and certain bit
for module 1.
Perhaps even those could be handled without explicit ID of 0 or 1, but
that doesn't sound trivial and I didn't want to start tackling that in
this series.
I wish there was a way to get the module ID from the HW registers
somehow. Then we wouldn't need to pass the ID via SW, which doesn't feel
very correct. At least with DT it's a bit wrong, in my opinion, but best
I could come up with.
We could derive it via a parameter like number of lanes or something
similar through DSI_GNQ, but that doesn't seem very nice, and may not be
usable on future OMAPs.
Archit
From: Tony Lindgren <tony@atomide.com> Date: 2012-05-07 17:46:58
Hi,
* Tomi Valkeinen [off-list ref] [120503 07:01]:
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's the
first set of patches from that ordeal. There's nothing DT specific in these
patches, but they are mostly generic cleanups that make sense even without DT.
This is the second version of these patches, the previous version can be found
from: http://www.spinics.net/lists/linux-fbdev/msg05667.html
The first 21 patches, which were in the previous version, have only gotten
minor cleanups (and, of course, more testing). The last 4 patches are new. The
most important of those patches is the DSI pin config patch, which makes it
possible for the panel driver to configure the DSI pins it needs.
This series can also be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base
Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching
patches (and the drivers/video dependencies needed) into a separate branch
and send me a pull request. That is assuming those patches are now immutable.
Then I can pull it into cleanup-dss branch that we both can merge as
needed.
Regards,
Tony
From: Tomi Valkeinen <hidden> Date: 2012-05-08 08:44:28
On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote:
Hi,
* Tomi Valkeinen [off-list ref] [120503 07:01]:
quoted
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's the
first set of patches from that ordeal. There's nothing DT specific in these
patches, but they are mostly generic cleanups that make sense even without DT.
This is the second version of these patches, the previous version can be found
from: http://www.spinics.net/lists/linux-fbdev/msg05667.html
The first 21 patches, which were in the previous version, have only gotten
minor cleanups (and, of course, more testing). The last 4 patches are new. The
most important of those patches is the DSI pin config patch, which makes it
possible for the panel driver to configure the DSI pins it needs.
This series can also be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base
Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching
patches (and the drivers/video dependencies needed) into a separate branch
and send me a pull request. That is assuming those patches are now immutable.
Then I can pull it into cleanup-dss branch that we both can merge as
needed.
Ok, I'll see how it goes. Do I have your ack for the board file changes?
Do you want to have patches that touch only
arch/arm/mach-omap2/display.c, but not the board files? That's a dss
specific file, and I don't expect anyone else to make changes to it, so
chances for conflicts should be quite minimal.
Tomi
From: Tony Lindgren <tony@atomide.com> Date: 2012-05-08 16:00:50
* Tomi Valkeinen [off-list ref] [120508 01:48]:
On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote:
quoted
Hi,
* Tomi Valkeinen [off-list ref] [120503 07:01]:
quoted
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's the
first set of patches from that ordeal. There's nothing DT specific in these
patches, but they are mostly generic cleanups that make sense even without DT.
This is the second version of these patches, the previous version can be found
from: http://www.spinics.net/lists/linux-fbdev/msg05667.html
The first 21 patches, which were in the previous version, have only gotten
minor cleanups (and, of course, more testing). The last 4 patches are new. The
most important of those patches is the DSI pin config patch, which makes it
possible for the panel driver to configure the DSI pins it needs.
This series can also be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base
Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching
patches (and the drivers/video dependencies needed) into a separate branch
and send me a pull request. That is assuming those patches are now immutable.
Then I can pull it into cleanup-dss branch that we both can merge as
needed.
Ok, I'll see how it goes. Do I have your ack for the board file changes?
Acked-by: Tony Lindgren <tony@atomide.com>
Do you want to have patches that touch only
arch/arm/mach-omap2/display.c, but not the board files? That's a dss
specific file, and I don't expect anyone else to make changes to it, so
chances for conflicts should be quite minimal.
Yes probably board-*.c files are enough to avoid annoying merge conflicts.
Regards,
Tony
From: Tomi Valkeinen <hidden> Date: 2012-05-09 08:09:09
On Mon, 2012-05-07 at 10:46 -0700, Tony Lindgren wrote:
Hi,
* Tomi Valkeinen [off-list ref] [120503 07:01]:
quoted
Hi,
I started cleaning up and restructuring omapdss for device tree, and here's the
first set of patches from that ordeal. There's nothing DT specific in these
patches, but they are mostly generic cleanups that make sense even without DT.
This is the second version of these patches, the previous version can be found
from: http://www.spinics.net/lists/linux-fbdev/msg05667.html
The first 21 patches, which were in the previous version, have only gotten
minor cleanups (and, of course, more testing). The last 4 patches are new. The
most important of those patches is the DSI pin config patch, which makes it
possible for the panel driver to configure the DSI pins it needs.
This series can also be found from:
git://gitorious.org/linux-omap-dss2/linux.git work/devtree-base
Nice clean up. Can you please put the first 12 arch/arm/*omap*/* touching
patches (and the drivers/video dependencies needed) into a separate branch
and send me a pull request. That is assuming those patches are now immutable.
Then I can pull it into cleanup-dss branch that we both can merge as
needed.
Below is the pull request for board file related changes. Tested on
panda & 4430sdp.
How should I manage my tree related to this... Should I rebase my
original DT preparation series on top of this new branch, or can I just
ignore the new branch for now, as long as I merge it at some point
before sending a pull request to mainline?
Tomi
The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-l-o-3.5
for you to fetch changes up to e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07:
OMAPDSS: DSI: implement generic DSI pin config (2012-05-09 10:53:05 +0300)
----------------------------------------------------------------
Tomi Valkeinen (6):
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi -> tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: DSI: implement generic DSI pin config
arch/arm/mach-omap2/board-3430sdp.c | 38 +-----
arch/arm/mach-omap2/board-4430sdp.c | 37 ++----
arch/arm/mach-omap2/board-am3517evm.c | 25 +---
arch/arm/mach-omap2/board-cm-t35.c | 30 +----
arch/arm/mach-omap2/board-devkit8000.c | 30 +----
arch/arm/mach-omap2/board-igep0020.c | 32 +----
arch/arm/mach-omap2/board-omap3beagle.c | 37 +-----
arch/arm/mach-omap2/board-omap3evm.c | 29 +----
arch/arm/mach-omap2/board-omap3stalker.c | 29 +----
arch/arm/mach-omap2/board-omap4panda.c | 39 +-----
arch/arm/mach-omap2/board-overo.c | 25 +---
drivers/video/omap2/displays/Kconfig | 8 +-
drivers/video/omap2/displays/Makefile | 2 +-
drivers/video/omap2/displays/panel-taal.c | 22 ++++
.../omap2/displays/{panel-dvi.c => panel-tfp410.c} | 134 +++++++++++---------
drivers/video/omap2/dss/dsi.c | 133 +++++++++----------
include/video/omap-panel-nokia-dsi.h | 3 +
.../{omap-panel-dvi.h => omap-panel-tfp410.h} | 18 ++-
include/video/omapdss.h | 28 ++--
19 files changed, 251 insertions(+), 448 deletions(-)
rename drivers/video/omap2/displays/{panel-dvi.c => panel-tfp410.c} (63%)
rename include/video/{omap-panel-dvi.h => omap-panel-tfp410.h} (63%)
From: Tony Lindgren <tony@atomide.com> Date: 2012-05-09 15:45:43
* Tomi Valkeinen [off-list ref] [120509 01:12]:
Below is the pull request for board file related changes. Tested on
panda & 4430sdp.
Thanks, I've merged that into clenaup-dss branch and will send it
along with other still pending cleanup branches.
How should I manage my tree related to this... Should I rebase my
original DT preparation series on top of this new branch, or can I just
ignore the new branch for now, as long as I merge it at some point
before sending a pull request to mainline?
Yes you need to rebase on this now. And not touch these commits.
Otherwise we'll end up with duplicate commits in the mainline tree,
which is a big no-no. If something shows up that needs fixing in this
series, it must now be separate patches on top of this series.
When doing pull requests we both just have to make note that there's
a dependency to this branch, and it will find it's way to mainline
via arm-soc pull request. Or if no conflicts need sorting out, then
it will just get merged with your pull request.
Regards,
Tony
Tomi
The following changes since commit 66f75a5d028beaf67c931435fdc3e7823125730c:
Linux 3.4-rc4 (2012-04-21 14:47:52 -0700)
are available in the git repository at:
git://gitorious.org/linux-omap-dss2/linux.git for-l-o-3.5
for you to fetch changes up to e4a9e94cc58ed6e4efb02b80be3a9bf57f448d07:
OMAPDSS: DSI: implement generic DSI pin config (2012-05-09 10:53:05 +0300)
----------------------------------------------------------------
Tomi Valkeinen (6):
OMAPDSS: panel-dvi: add PD gpio handling
OMAP: board-files: remove custom PD GPIO handling for DVI output
OMAPDSS: TFP410: rename dvi -> tfp410
OMAPDSS: TFP410: rename dvi files to tfp410
OMAPDSS: Taal: move reset gpio handling to taal driver
OMAPDSS: DSI: implement generic DSI pin config
arch/arm/mach-omap2/board-3430sdp.c | 38 +-----
arch/arm/mach-omap2/board-4430sdp.c | 37 ++----
arch/arm/mach-omap2/board-am3517evm.c | 25 +---
arch/arm/mach-omap2/board-cm-t35.c | 30 +----
arch/arm/mach-omap2/board-devkit8000.c | 30 +----
arch/arm/mach-omap2/board-igep0020.c | 32 +----
arch/arm/mach-omap2/board-omap3beagle.c | 37 +-----
arch/arm/mach-omap2/board-omap3evm.c | 29 +----
arch/arm/mach-omap2/board-omap3stalker.c | 29 +----
arch/arm/mach-omap2/board-omap4panda.c | 39 +-----
arch/arm/mach-omap2/board-overo.c | 25 +---
drivers/video/omap2/displays/Kconfig | 8 +-
drivers/video/omap2/displays/Makefile | 2 +-
drivers/video/omap2/displays/panel-taal.c | 22 ++++
.../omap2/displays/{panel-dvi.c => panel-tfp410.c} | 134 +++++++++++---------
drivers/video/omap2/dss/dsi.c | 133 +++++++++----------
include/video/omap-panel-nokia-dsi.h | 3 +
.../{omap-panel-dvi.h => omap-panel-tfp410.h} | 18 ++-
include/video/omapdss.h | 28 ++--
19 files changed, 251 insertions(+), 448 deletions(-)
rename drivers/video/omap2/displays/{panel-dvi.c => panel-tfp410.c} (63%)
rename include/video/{omap-panel-dvi.h => omap-panel-tfp410.h} (63%)
On Thu, May 3, 2012 at 6:57 AM, Tomi Valkeinen [off-list ref] wrote:
quoted hunk
The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/displays/panel-dvi.c | 31 ++++++++++++++++++++++++++++++
include/video/omap-panel-dvi.h | 2 ++
2 files changed, 33 insertions(+)
* @platform_enable: platform specific panel enable function
* @platform_disable: platform specific panel disable function
* @i2c_bus_num: i2c bus id for the panel
+ * @power_down_gpio: gpio number for PD pin (or -1 if not available)
*/
struct panel_dvi_platform_data {
int (*platform_enable)(struct omap_dss_device *dssdev);
void (*platform_disable)(struct omap_dss_device *dssdev);
u16 i2c_bus_num;
+ int power_down_gpio;
};
#endif /* __OMAP_PANEL_DVI_H */
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From: Tomi Valkeinen <hidden> Date: 2012-05-09 17:32:40
On Wed, 2012-05-09 at 09:50 -0700, Russ Dill wrote:
On Thu, May 3, 2012 at 6:57 AM, Tomi Valkeinen [off-list ref] wrote:
quoted
The driver for the TFP410 chip should handle the power-down signal of
the chip, instead of the current way of handling it in the board files.
This patch adds power_down_gpio into the device's platform data, and
adds the necessary code in the driver to request and handle the GPIO.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/displays/panel-dvi.c | 31 ++++++++++++++++++++++++++++++
include/video/omap-panel-dvi.h | 2 ++
2 files changed, 33 insertions(+)
@@ -70,6 +74,9 @@ static int panel_dvi_power_on(struct omap_dss_device *dssdev)gotoerr1;}+if(gpio_is_valid(ddata->pd_gpio))+gpio_set_value(ddata->pd_gpio,1);+
On Beagleboard xM, this GPIO is connected though an I2C chip so it
sleeps. Can you change these to gpio_set_value_cansleep?
This patch has already been applied, so we have to do follow up patches
for this. I can look at this tomorrow, but if you update your "ARM:
OMAP: Cleanup Beagleboard DVI reset gpio" patch, will you take a look at
this also?
The applied patches can be found from here, so the follow up patches
should be based on this: git://gitorious.org/linux-omap-dss2/linux.git
for-l-o-3.5
Tomi
From: Tomi Valkeinen <hidden> Date: 2012-05-10 07:11:28
On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote:
* Tomi Valkeinen [off-list ref] [120509 01:12]:
quoted
Below is the pull request for board file related changes. Tested on
panda & 4430sdp.
Thanks, I've merged that into clenaup-dss branch and will send it
along with other still pending cleanup branches.
quoted
How should I manage my tree related to this... Should I rebase my
original DT preparation series on top of this new branch, or can I just
ignore the new branch for now, as long as I merge it at some point
before sending a pull request to mainline?
Yes you need to rebase on this now. And not touch these commits.
Otherwise we'll end up with duplicate commits in the mainline tree,
which is a big no-no. If something shows up that needs fixing in this
series, it must now be separate patches on top of this series.
When doing pull requests we both just have to make note that there's
a dependency to this branch, and it will find it's way to mainline
via arm-soc pull request. Or if no conflicts need sorting out, then
it will just get merged with your pull request.
Hmm, I'm still not totally sure how to proceed. What do you mean with
"make a note"?
I understand that I can't change the commits, but is it ok for me to now
merge the for-l-o-3.5 branch into my master branch (which is my "stable"
branch, for which I'll send a pull request)?
If the same commits are both in my tree and in l-o (or arm-soc), doesn't
it mean that the commits seem to come into Linus's tree from whoever
happens to send their pull request first? Then again, does it matter..
And if there are conflicts in the board files between for-l-o-3.5 and
some other commits, and you or Arnd resolve those for l-o or arm-soc,
what happens when the same, but unresolved, commits come from my pull
request?
Sorry if this should be obvious, but I haven't done such merging before
and I'd rather not mess it up =).
Tomi
From: Tony Lindgren <tony@atomide.com> Date: 2012-05-10 16:13:27
* Tomi Valkeinen [off-list ref] [120510 00:15]:
On Wed, 2012-05-09 at 08:45 -0700, Tony Lindgren wrote:
quoted
* Tomi Valkeinen [off-list ref] [120509 01:12]:
quoted
Below is the pull request for board file related changes. Tested on
panda & 4430sdp.
Thanks, I've merged that into clenaup-dss branch and will send it
along with other still pending cleanup branches.
quoted
How should I manage my tree related to this... Should I rebase my
original DT preparation series on top of this new branch, or can I just
ignore the new branch for now, as long as I merge it at some point
before sending a pull request to mainline?
Yes you need to rebase on this now. And not touch these commits.
Otherwise we'll end up with duplicate commits in the mainline tree,
which is a big no-no. If something shows up that needs fixing in this
series, it must now be separate patches on top of this series.
When doing pull requests we both just have to make note that there's
a dependency to this branch, and it will find it's way to mainline
via arm-soc pull request. Or if no conflicts need sorting out, then
it will just get merged with your pull request.
Hmm, I'm still not totally sure how to proceed. What do you mean with
"make a note"?
Well let's say I had some conflicting platform data clean up patches,
I would pull in your branch, then when sending a pull request I would
mention that it depends on your branch being pulled in.
I understand that I can't change the commits, but is it ok for me to now
merge the for-l-o-3.5 branch into my master branch (which is my "stable"
branch, for which I'll send a pull request)?
Yes. But I suggest you first add add that panda xm gpio fix into your
for-l-o-3.5 and that way it's safer for me to merge too.
If the same commits are both in my tree and in l-o (or arm-soc), doesn't
it mean that the commits seem to come into Linus's tree from whoever
happens to send their pull request first? Then again, does it matter..
Yes, that's OK.
And if there are conflicts in the board files between for-l-o-3.5 and
some other commits, and you or Arnd resolve those for l-o or arm-soc,
what happens when the same, but unresolved, commits come from my pull
request?
Well in that case it makes sense to get the arm-soc changes merged
first, who wants to resolve conflicts multiple times? Of course more
branches can be pulled into both trees as needed too.
Sorry if this should be obvious, but I haven't done such merging before
and I'd rather not mess it up =).