From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:24
read_edid() can be used to get the EDID information from the display.
Signed-off-by: Tomi Valkeinen <redacted>
---
include/video/omapdss.h | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:25
detect() can be used to probe if the display is connected.
Signed-off-by: Tomi Valkeinen <redacted>
---
include/video/omapdss.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:26
Currently the set_timings code for hdmi is quite strange. The display is
disabled in hdmi_omap4_panel.c before setting timings, and enabled in
hdmi.c after setting the timings. Furthermore, the timings were not
permanent, and disabling and enabling the display would lose them.
This patch makes the set_timings handling a bit better.
Cc: Mythri P K <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/hdmi.c | 13 +++++++++++--
drivers/video/omap2/dss/hdmi_panel.c | 7 +------
2 files changed, 12 insertions(+), 8 deletions(-)
@@ -571,11 +571,20 @@ void omapdss_hdmi_display_set_timing(struct omap_dss_device *dssdev)structhdmi_cmcm;hdmi.custom_set=1;+cm=hdmi_get_code(&dssdev->panel.timings);hdmi.code=cm.code;hdmi.mode=cm.mode;-omapdss_hdmi_display_enable(dssdev);-hdmi.custom_set=0;++if(dssdev->state=OMAP_DSS_DISPLAY_ACTIVE){+intr;++hdmi_power_off(dssdev);++r=hdmi_power_on(dssdev);+if(r)+DSSERR("failed to power on device\n");+}}intomapdss_hdmi_display_enable(structomap_dss_device*dssdev)
@@ -161,12 +161,7 @@ static void hdmi_set_timings(struct omap_dss_device *dssdev,mutex_lock(&hdmi.hdmi_lock);dssdev->panel.timings=*timings;--if(dssdev->state=OMAP_DSS_DISPLAY_ACTIVE){-/* turn the hdmi off and on to get new timings to use */-omapdss_hdmi_display_disable(dssdev);-omapdss_hdmi_display_set_timing(dssdev);-}+omapdss_hdmi_display_set_timing(dssdev);mutex_unlock(&hdmi.hdmi_lock);}
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:28
OMAPFB handles EDID parsing now, using the common helper functions in
fbdev. We can remove the EDID parsing from HDMI driver.
Cc: Mythri P K <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/hdmi.c | 154 ----------------------------------
drivers/video/omap2/dss/hdmi_panel.c | 8 +--
2 files changed, 1 insertions(+), 161 deletions(-)
@@ -162,8 +159,6 @@ static const int code_vesa[85] = {-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,-1,27,28,-1,33};-staticconstu8edid_header[8]={0x0,0xff,0xff,0xff,0xff,0xff,0xff,0x0};-staticinthdmi_runtime_get(void){intr;
@@ -193,21 +188,6 @@ int hdmi_init_display(struct omap_dss_device *dssdev)return0;}-staticvoidcopy_hdmi_to_dss_timings(-conststructhdmi_video_timings*hdmi_timings,-structomap_video_timings*timings)-{-timings->x_res=hdmi_timings->x_res;-timings->y_res=hdmi_timings->y_res;-timings->pixel_clock=hdmi_timings->pixel_clock;-timings->hbp=hdmi_timings->hbp;-timings->hfp=hdmi_timings->hfp;-timings->hsw=hdmi_timings->hsw;-timings->vbp=hdmi_timings->vbp;-timings->vfp=hdmi_timings->vfp;-timings->vsw=hdmi_timings->vsw;-}-staticintget_timings_index(void){intcode;
@@ -270,130 +250,6 @@ static struct hdmi_cm hdmi_get_code(struct omap_video_timings *timing)returncm;}-staticvoidget_horz_vert_timing_info(intcurrent_descriptor_addrs,u8*edid,-structomap_video_timings*timings)-{-/* X and Y resolution */-timings->x_res=(((edid[current_descriptor_addrs+4]&0xF0)<<4)|-edid[current_descriptor_addrs+2]);-timings->y_res=(((edid[current_descriptor_addrs+7]&0xF0)<<4)|-edid[current_descriptor_addrs+5]);--timings->pixel_clock=((edid[current_descriptor_addrs+1]<<8)|-edid[current_descriptor_addrs]);--timings->pixel_clock=10*timings->pixel_clock;--/* HORIZONTAL FRONT PORCH */-timings->hfp=edid[current_descriptor_addrs+8]|-((edid[current_descriptor_addrs+11]&0xc0)<<2);-/* HORIZONTAL SYNC WIDTH */-timings->hsw=edid[current_descriptor_addrs+9]|-((edid[current_descriptor_addrs+11]&0x30)<<4);-/* HORIZONTAL BACK PORCH */-timings->hbp=(((edid[current_descriptor_addrs+4]&0x0F)<<8)|-edid[current_descriptor_addrs+3])--(timings->hfp+timings->hsw);-/* VERTICAL FRONT PORCH */-timings->vfp=((edid[current_descriptor_addrs+10]&0xF0)>>4)|-((edid[current_descriptor_addrs+11]&0x0f)<<2);-/* VERTICAL SYNC WIDTH */-timings->vsw=(edid[current_descriptor_addrs+10]&0x0F)|-((edid[current_descriptor_addrs+11]&0x03)<<4);-/* VERTICAL BACK PORCH */-timings->vbp=(((edid[current_descriptor_addrs+7]&0x0F)<<8)|-edid[current_descriptor_addrs+6])--(timings->vfp+timings->vsw);--}--/* Description : This function gets the resolution information from EDID */-staticvoidget_edid_timing_data(u8*edid)-{-u8count;-u16current_descriptor_addrs;-structhdmi_cmcm;-structomap_video_timingsedid_timings;--/* search block 0, there are 4 DTDs arranged in priority order */-for(count=0;count<EDID_SIZE_BLOCK0_TIMING_DESCRIPTOR;count++){-current_descriptor_addrs-EDID_DESCRIPTOR_BLOCK0_ADDRESS+-count*EDID_TIMING_DESCRIPTOR_SIZE;-get_horz_vert_timing_info(current_descriptor_addrs,-edid,&edid_timings);-cm=hdmi_get_code(&edid_timings);-DSSDBG("Block0[%d] value matches code = %d , mode = %d\n",-count,cm.code,cm.mode);-if(cm.code=-1){-continue;-}else{-hdmi.code=cm.code;-hdmi.mode=cm.mode;-DSSDBG("code = %d , mode = %d\n",-hdmi.code,hdmi.mode);-return;-}-}-if(edid[0x7e]!=0x00){-for(count=0;count<EDID_SIZE_BLOCK1_TIMING_DESCRIPTOR;-count++){-current_descriptor_addrs-EDID_DESCRIPTOR_BLOCK1_ADDRESS+-count*EDID_TIMING_DESCRIPTOR_SIZE;-get_horz_vert_timing_info(current_descriptor_addrs,-edid,&edid_timings);-cm=hdmi_get_code(&edid_timings);-DSSDBG("Block1[%d] value matches code = %d, mode = %d",-count,cm.code,cm.mode);-if(cm.code=-1){-continue;-}else{-hdmi.code=cm.code;-hdmi.mode=cm.mode;-DSSDBG("code = %d , mode = %d\n",-hdmi.code,hdmi.mode);-return;-}-}-}--DSSINFO("no valid timing found , falling back to VGA\n");-hdmi.code=4;/* setting default value of 640 480 VGA */-hdmi.mode=HDMI_DVI;-}--staticvoidhdmi_read_edid(structomap_video_timings*dp)-{-intret=0,code;--memset(hdmi.edid,0,HDMI_EDID_MAX_LENGTH);--if(!hdmi.edid_set)-ret=hdmi.ip_data.ops->read_edid(&hdmi.ip_data,hdmi.edid,-HDMI_EDID_MAX_LENGTH);-if(ret>0){-if(!memcmp(hdmi.edid,edid_header,sizeof(edid_header))){-/* search for timings of default resolution */-get_edid_timing_data(hdmi.edid);-hdmi.edid_set=true;-}-}else{-DSSWARN("failed to read E-EDID\n");-}--if(!hdmi.edid_set){-DSSINFO("fallback to VGA\n");-hdmi.code=4;/* setting default value of 640 480 VGA */-hdmi.mode=HDMI_DVI;-}--code=get_timings_index();--copy_hdmi_to_dss_timings(&cea_vesa_timings[code].timings,dp);--}-staticvoidupdate_hdmi_timings(structhdmi_config*cfg,structomap_video_timings*timings,intcode){
@@ -479,13 +335,7 @@ static int hdmi_power_on(struct omap_dss_device *dssdev)dssdev->panel.timings.x_res,dssdev->panel.timings.y_res);-if(!hdmi.custom_set){-DSSDBG("Read EDID as no EDID is not set on poweron\n");-hdmi_read_edid(p);-}code=get_timings_index();-copy_hdmi_to_dss_timings(&cea_vesa_timings[code].timings,-&dssdev->panel.timings);update_hdmi_timings(&hdmi.ip_data.cfg,p,code);phy=p->pixel_clock;
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:29
Split the DDC initialization off from hdmi_core_ddc_edid() into a
separate function hdmi_core_ddc_init(). This cleans up the
implementation.
Cc: Mythri P K <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 117 ++++++++++++++++------------
1 files changed, 67 insertions(+), 50 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:30
Clean up reading of EDID by passing direct address to the block being
read, instead of start address of the whole EDID memory area. Rewrite
the loop which reads the EDID.
This also fixes the checksum calculation, which used to calculate the
checksum only for the first block.
Cc: Mythri P K <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/ti_hdmi.h | 6 +--
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 67 +++++++++++++++--------------
2 files changed, 36 insertions(+), 37 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:31
check_timings() is supposed to be used to verify if timings are ok or
not. Currently the HDMI driver prints error messages if the timings are
not ok. This is not right, as it is no error to give invalid timings to
check_timings().
Remove the error prints.
Cc: Mythri P K <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/hdmi.c | 1 -
drivers/video/omap2/dss/hdmi_panel.c | 6 +-----
2 files changed, 1 insertions(+), 6 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:32
Implement detect() by checking the hot plug detect status.
The implementation is not very good, as it always turns on the HDMI
output to get the detection working. HDMI driver needs improvements so
that we could enable only core parts of it.
Cc: Mythri P K <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dss.h | 1 +
drivers/video/omap2/dss/dss_features.c | 1 +
drivers/video/omap2/dss/hdmi.c | 17 +++++++++++++++++
drivers/video/omap2/dss/hdmi_panel.c | 25 +++++++++++++++++++++++++
drivers/video/omap2/dss/ti_hdmi.h | 3 +++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 12 ++++++++++++
6 files changed, 59 insertions(+), 0 deletions(-)
@@ -449,6 +449,23 @@ int omapdss_hdmi_read_edid(u8 *buf, int len)returnr;}+boolomapdss_hdmi_detect(void)+{+intr;++mutex_lock(&hdmi.lock);++r=hdmi_runtime_get();+BUG_ON(r);++r=hdmi.ip_data.ops->detect(&hdmi.ip_data);++hdmi_runtime_put();+mutex_unlock(&hdmi.lock);++returnr=1;+}+intomapdss_hdmi_display_enable(structomap_dss_device*dssdev){intr=0;
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:33
We have currently panel-generic-dpi driver, which is a combined driver
for dummy panels and also for DVI output.
The aim is to split the panel-generic-dpi into two, one for fixed size
dummy panels connected via DPI, and the other (this) for variable
resolution output which supports DDC channel (in practice a DVI framer
chip connected to DPI output).
Original i2c code by: Ricardo Salveti de Araujo
[off-list ref]
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/displays/Kconfig | 7 +
drivers/video/omap2/displays/Makefile | 1 +
drivers/video/omap2/displays/panel-dvi.c | 363 ++++++++++++++++++++++++++++++
include/video/omap-panel-dvi.h | 37 +++
4 files changed, 408 insertions(+), 0 deletions(-)
create mode 100644 drivers/video/omap2/displays/panel-dvi.c
create mode 100644 include/video/omap-panel-dvi.h
@@ -0,0 +1,363 @@+/*+*DVIoutputsupport+*+*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<drm/drm_edid.h>++#include<video/omap-panel-dvi.h>++staticconststructomap_video_timingspanel_dvi_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;+};++staticinlinestructpanel_dvi_platform_data+*get_pdata(conststructomap_dss_device*dssdev)+{+returndssdev->data;+}++staticintpanel_dvi_power_on(structomap_dss_device*dssdev)+{+structpanel_dvi_platform_data*pdata=get_pdata(dssdev);+intr;++if(dssdev->state=OMAP_DSS_DISPLAY_ACTIVE)+return0;++r=omapdss_dpi_display_enable(dssdev);+if(r)+gotoerr0;++if(pdata->platform_enable){+r=pdata->platform_enable(dssdev);+if(r)+gotoerr1;+}++return0;+err1:+omapdss_dpi_display_disable(dssdev);+err0:+returnr;+}++staticvoidpanel_dvi_power_off(structomap_dss_device*dssdev)+{+structpanel_dvi_platform_data*pdata=get_pdata(dssdev);++if(dssdev->state!=OMAP_DSS_DISPLAY_ACTIVE)+return;++if(pdata->platform_disable)+pdata->platform_disable(dssdev);++omapdss_dpi_display_disable(dssdev);+}++staticintpanel_dvi_probe(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata;++ddata=kzalloc(sizeof(*ddata),GFP_KERNEL);+if(!ddata)+return-ENOMEM;++dssdev->panel.timings=panel_dvi_default_timings;+dssdev->panel.config=OMAP_DSS_LCD_TFT;++ddata->dssdev=dssdev;+mutex_init(&ddata->lock);++dev_set_drvdata(&dssdev->dev,ddata);++return0;+}++staticvoid__exitpanel_dvi_remove(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++mutex_lock(&ddata->lock);++dev_set_drvdata(&dssdev->dev,NULL);++mutex_unlock(&ddata->lock);++kfree(ddata);+}++staticintpanel_dvi_enable(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+intr;++mutex_lock(&ddata->lock);++r=panel_dvi_power_on(dssdev);+if(r=0)+dssdev->state=OMAP_DSS_DISPLAY_ACTIVE;++mutex_unlock(&ddata->lock);++returnr;+}++staticvoidpanel_dvi_disable(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++mutex_lock(&ddata->lock);++panel_dvi_power_off(dssdev);++dssdev->state=OMAP_DSS_DISPLAY_DISABLED;++mutex_unlock(&ddata->lock);+}++staticintpanel_dvi_suspend(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);++mutex_lock(&ddata->lock);++panel_dvi_power_off(dssdev);++dssdev->state=OMAP_DSS_DISPLAY_SUSPENDED;++mutex_unlock(&ddata->lock);++return0;+}++staticintpanel_dvi_resume(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+intr;++mutex_lock(&ddata->lock);++r=panel_dvi_power_on(dssdev);+if(r=0)+dssdev->state=OMAP_DSS_DISPLAY_ACTIVE;++mutex_unlock(&ddata->lock);++returnr;+}++staticvoidpanel_dvi_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);+}++staticvoidpanel_dvi_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);+}++staticintpanel_dvi_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;+}+++staticintpanel_dvi_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;+}++staticintpanel_dvi_read_edid(structomap_dss_device*dssdev,+u8*edid,intlen)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+structpanel_dvi_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=panel_dvi_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=panel_dvi_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;+}++staticboolpanel_dvi_detect(structomap_dss_device*dssdev)+{+structpanel_drv_data*ddata=dev_get_drvdata(&dssdev->dev);+structpanel_dvi_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=panel_dvi_ddc_read(adapter,&out,1,0);++mutex_unlock(&ddata->lock);++returnr=0;++out:+mutex_unlock(&ddata->lock);+returntrue;+}++staticstructomap_dss_driverpanel_dvi_driver={+.probe=panel_dvi_probe,+.remove=__exit_p(panel_dvi_remove),++.enable=panel_dvi_enable,+.disable=panel_dvi_disable,+.suspend=panel_dvi_suspend,+.resume=panel_dvi_resume,++.set_timings=panel_dvi_set_timings,+.get_timings=panel_dvi_get_timings,+.check_timings=panel_dvi_check_timings,++.read_edid=panel_dvi_read_edid,+.detect=panel_dvi_detect,++.driver={+.name="dvi",+.owner=THIS_MODULE,+},+};++staticint__initpanel_dvi_init(void)+{+returnomap_dss_register_driver(&panel_dvi_driver);+}++staticvoid__exitpanel_dvi_exit(void)+{+omap_dss_unregister_driver(&panel_dvi_driver);+}++module_init(panel_dvi_init);+module_exit(panel_dvi_exit);+MODULE_LICENSE("GPL");
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:35
OMAP3 Stalker board has definitions for LCD, but uses the generic driver
without any information what kind of LCD it has. The board should use a
particular panel type from panel-generic-dpi driver, not the generic
one.
As I haven't gotten response the signer-off of stalker board about the
issue, this patch removes the LCD support from the board file. This will
allow us to clean up the panel-generic-dpi driver and make it support
only fixed size panels.
CC: Jason Lam <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/board-omap3stalker.c | 34 ------------------------------
1 files changed, 0 insertions(+), 34 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:37
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/board-omap3beagle.c | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 1 +
arch/arm/mach-omap2/board-overo.c | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
From: Tomi Valkeinen <hidden> Date: 2011-09-12 09:13:38
Use the new read_edid() function to get EDID information from the
display (when available), and use the information to use a suitable mode
at initialization time.
Hot-plug is not yet supported, so the timings selected at init time will
stay even if the monitor would be changed.
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/omapfb/omapfb-main.c | 109 +++++++++++++++++++++++++++---
1 files changed, 99 insertions(+), 10 deletions(-)
@@ -2404,9 +2485,27 @@ 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);+/* gfx overlay should be the default one. find a display+*connectedtothat,anduseitasdefaultdisplay*/+ovl=omap_dss_get_overlay(0);+if(ovl->manager&&ovl->manager->device){+def_display=ovl->manager->device;+}else{+dev_warn(&pdev->dev,"cannot find default display\n");+def_display=NULL;+}+if(def_mode&&strlen(def_mode)>0){if(omapfb_parse_def_modes(fbdev))dev_warn(&pdev->dev,"cannot parse default modes\n");+}elseif(def_display&&def_display->driver->set_timings&&+def_display->driver->check_timings){+structomap_video_timingst;++r=omapfb_find_best_mode(def_display,&t);++if(r=0)+def_display->driver->set_timings(def_display,&t);}r=omapfb_create_framebuffers(fbdev);
@@ -2423,16 +2522,6 @@ static int omapfb_probe(struct platform_device *pdev)DBG("mgr->apply'ed\n");-/* gfx overlay should be the default one. find a display-*connectedtothat,anduseitasdefaultdisplay*/-ovl=omap_dss_get_overlay(0);-if(ovl->manager&&ovl->manager->device){-def_display=ovl->manager->device;-}else{-dev_warn(&pdev->dev,"cannot find default display\n");-def_display=NULL;-}-if(def_display){r=omapfb_init_display(fbdev,def_display);if(r){
From: Enric Balletbò i Serra <eballetbo@gmail.com> Date: 2011-09-12 09:58:21
2011/9/12 Tomi Valkeinen [off-list ref]:
quoted hunk
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/board-omap3beagle.c | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 1 +
arch/arm/mach-omap2/board-overo.c | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
static struct panel_dvi_platform_data dvi_panel = {
.platform_enable = overo_panel_enable_dvi,
.platform_disable = overo_panel_disable_dvi,
+ .i2c_bus_num = 3,
};
static struct omap_dss_device overo_dvi_device = {
--
1.7.4.1
--
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
Please, can also include the same modification for IGEP v2 board
(arch/arm/mach-omap2/board-igep0020.c) ?
Best regards,
Enric
From: Tomi Valkeinen <hidden> Date: 2011-09-12 10:17:25
On Mon, 2011-09-12 at 11:58 +0200, Enric Balletbò i Serra wrote:
2011/9/12 Tomi Valkeinen [off-list ref]:
quoted
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/board-omap3beagle.c | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 1 +
arch/arm/mach-omap2/board-overo.c | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
1.7.4.1
--
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
Please, can also include the same modification for IGEP v2 board
(arch/arm/mach-omap2/board-igep0020.c) ?
Sure. You have tested that the i2c bus is 3 and it works?
Tomi
From: Enric Balletbò i Serra <eballetbo@gmail.com> Date: 2011-09-12 11:13:57
2011/9/12 Tomi Valkeinen [off-list ref]:
On Mon, 2011-09-12 at 11:58 +0200, Enric Balletbò i Serra wrote:
quoted
2011/9/12 Tomi Valkeinen [off-list ref]:
quoted
Add i2c bus number for DVI output. The driver uses this to detect if a
panel is connected and to read EDID.
Signed-off-by: Tomi Valkeinen <redacted>
---
arch/arm/mach-omap2/board-omap3beagle.c | 1 +
arch/arm/mach-omap2/board-omap4panda.c | 1 +
arch/arm/mach-omap2/board-overo.c | 1 +
3 files changed, 3 insertions(+), 0 deletions(-)
static struct panel_dvi_platform_data dvi_panel = {
.platform_enable = overo_panel_enable_dvi,
.platform_disable = overo_panel_disable_dvi,
+ .i2c_bus_num = 3,
};
static struct omap_dss_device overo_dvi_device = {
--
1.7.4.1
--
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
Please, can also include the same modification for IGEP v2 board
(arch/arm/mach-omap2/board-igep0020.c) ?
Sure. You have tested that the i2c bus is 3 and it works?
Yes, the i2c bus is 3 on IGEP v2 board and I'm just testing and seem is working.
From: K, Mythri P <hidden> Date: 2011-09-12 13:36:33
Hi Tomi,
On Mon, Sep 12, 2011 at 2:43 PM, Tomi Valkeinen [off-list ref] wrote:
quoted hunk
Implement detect() by checking the hot plug detect status.
The implementation is not very good, as it always turns on the HDMI
output to get the detection working. HDMI driver needs improvements so
that we could enable only core parts of it.
Cc: Mythri P K <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
drivers/video/omap2/dss/dss.h | 1 +
drivers/video/omap2/dss/dss_features.c | 1 +
drivers/video/omap2/dss/hdmi.c | 17 +++++++++++++++++
drivers/video/omap2/dss/hdmi_panel.c | 25 +++++++++++++++++++++++++
drivers/video/omap2/dss/ti_hdmi.h | 3 +++
drivers/video/omap2/dss/ti_hdmi_4xxx_ip.c | 12 ++++++++++++
6 files changed, 59 insertions(+), 0 deletions(-)
int omapdss_hdmi_display_check_timing(struct omap_dss_device *dssdev,
struct omap_video_timings *timings);
int omapdss_hdmi_read_edid(u8 *buf, int len);
+bool omapdss_hdmi_detect(void);
int hdmi_panel_init(void);
void hdmi_panel_exit(void);
For HPD the probe should also be on the core interrupt first , and the
detect should be dynamic, ie based on the cable connect and disconnect
event.So this approach for HPD is not really the way.
Also that should be based on the GPIO(63) , I am planning to push a
patch on that shortly.
From: Tomi Valkeinen <hidden> Date: 2011-09-12 16:18:01
On Mon, 2011-09-12 at 18:54 +0530, K, Mythri P wrote:
Hi Tomi,
On Mon, Sep 12, 2011 at 2:43 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
Implement detect() by checking the hot plug detect status.
The implementation is not very good, as it always turns on the HDMI
output to get the detection working. HDMI driver needs improvements so
that we could enable only core parts of it.
Cc: Mythri P K <redacted>
Signed-off-by: Tomi Valkeinen <redacted>
---
For HPD the probe should also be on the core interrupt first , and the
detect should be dynamic, ie based on the cable connect and disconnect
event.So this approach for HPD is not really the way.
This is not for the event, this is for polling. There is currently no
hot plug event mechanism in the DSS.
Do we get an interrupt when the driver is loaded and the cable is
already connected? And do you plan to keep the plugged in/out state
stored somewhere, or how do you implement detect()?
Also that should be based on the GPIO(63) , I am planning to push a
patch on that shortly.
What is gpio 63? What does the HDMI_CORE_SYS_STAT HDP bit tell us then?
Tomi
For HPD the probe should also be on the core interrupt first , and the
detect should be dynamic, ie based on the cable connect and disconnect
event.So this approach for HPD is not really the way.
Also that should be based on the GPIO(63) , I am planning to push a
patch on that shortly.
Fwiw, we do still need a dssdrv->detect() function from omapdrm
driver.. if there is another way to implement that function, such as
with a GPIO, that is great. But somehow or another we need the detect
function. The implementation can always change later.
BR,
-R
For HPD the probe should also be on the core interrupt first , and the
detect should be dynamic, ie based on the cable connect and disconnect
event.So this approach for HPD is not really the way.
Also that should be based on the GPIO(63) , I am planning to push a
patch on that shortly.
Fwiw, we do still need a dssdrv->detect() function from omapdrm
driver.. if there is another way to implement that function, such as
with a GPIO, that is great. But somehow or another we need the detect
function. The implementation can always change later.
Yes we still need a detect , but the implementation would be different
, from the prior experience with the Hot-plug detection it wad found
that the interrupt based way to handle HPD was not the best ,but if
this is just to poll the status then it should be fine.
For HPD the probe should also be on the core interrupt first , and the
detect should be dynamic, ie based on the cable connect and disconnect
event.So this approach for HPD is not really the way.
Also that should be based on the GPIO(63) , I am planning to push a
patch on that shortly.
Fwiw, we do still need a dssdrv->detect() function from omapdrm
driver.. if there is another way to implement that function, such as
with a GPIO, that is great. But somehow or another we need the detect
function. The implementation can always change later.
Yes we still need a detect , but the implementation would be different
, from the prior experience with the Hot-plug detection it wad found
that the interrupt based way to handle HPD was not the best ,but if
this is just to poll the status then it should be fine.
I'm not sure I understood. First you say the implementation should be
different, but then you say this should be fine. So is this a valid
implementation for detect() or is there a better way to do it?
Tomi
For HPD the probe should also be on the core interrupt first , and the
detect should be dynamic, ie based on the cable connect and disconnect
event.So this approach for HPD is not really the way.
Also that should be based on the GPIO(63) , I am planning to push a
patch on that shortly.
Fwiw, we do still need a dssdrv->detect() function from omapdrm
driver.. if there is another way to implement that function, such as
with a GPIO, that is great. But somehow or another we need the detect
function. The implementation can always change later.
Yes we still need a detect , but the implementation would be different
, from the prior experience with the Hot-plug detection it wad found
that the interrupt based way to handle HPD was not the best ,but if
this is just to poll the status then it should be fine.
I'm not sure I understood. First you say the implementation should be
different, but then you say this should be fine. So is this a valid
implementation for detect() or is there a better way to do it?
There is a better way to handle Hot-plug detection and notification..
But depends on what is the purpose of this function, Ideally a detect
The purpose of the detect function is to return true or false, depending
on whether a (preferably powered-on) monitor is connecter via a cable or
not. So it tells if there's a display that can be used or not.
would be the case to dynamically detect whether the cable is connected
on not , But all this function does is to see the state of the HPD bit
in core state statically.
I don't understand this one. How could this be more dynamic? The
function checks the HPD bit, which (based on my observation) shows the
status whether a display is connected or not.
So I said if the purpose of this function is only to check for the HPD
state bit it is fine.
For HPD the probe should also be on the core interrupt first , and the
detect should be dynamic, ie based on the cable connect and disconnect
event.So this approach for HPD is not really the way.
Also that should be based on the GPIO(63) , I am planning to push a
patch on that shortly.
Fwiw, we do still need a dssdrv->detect() function from omapdrm
driver.. if there is another way to implement that function, such as
with a GPIO, that is great. But somehow or another we need the detect
function. The implementation can always change later.
Yes we still need a detect , but the implementation would be different
, from the prior experience with the Hot-plug detection it wad found
that the interrupt based way to handle HPD was not the best ,but if
this is just to poll the status then it should be fine.
I'm not sure I understood. First you say the implementation should be
different, but then you say this should be fine. So is this a valid
implementation for detect() or is there a better way to do it?
There is a better way to handle Hot-plug detection and notification..
But depends on what is the purpose of this function, Ideally a detect
would be the case to dynamically detect whether the cable is connected
on not , But all this function does is to see the state of the HPD bit
in core state statically.
So I said if the purpose of this function is only to check for the HPD
state bit it is fine.
Thanks and regards,
Mythri.
For HPD the probe should also be on the core interrupt first , and the
detect should be dynamic, ie based on the cable connect and disconnect
event.So this approach for HPD is not really the way.
Also that should be based on the GPIO(63) , I am planning to push a
patch on that shortly.
Fwiw, we do still need a dssdrv->detect() function from omapdrm
driver.. if there is another way to implement that function, such as
with a GPIO, that is great. But somehow or another we need the detect
function. The implementation can always change later.
Yes we still need a detect , but the implementation would be different
, from the prior experience with the Hot-plug detection it wad found
that the interrupt based way to handle HPD was not the best ,but if
this is just to poll the status then it should be fine.
I'm not sure I understood. First you say the implementation should be
different, but then you say this should be fine. So is this a valid
implementation for detect() or is there a better way to do it?
There is a better way to handle Hot-plug detection and notification..
But depends on what is the purpose of this function, Ideally a detect
The purpose of the detect function is to return true or false, depending
on whether a (preferably powered-on) monitor is connecter via a cable or
not. So it tells if there's a display that can be used or not.
quoted
would be the case to dynamically detect whether the cable is connected
on not , But all this function does is to see the state of the HPD bit
in core state statically.
I don't understand this one. How could this be more dynamic? The
function checks the HPD bit, which (based on my observation) shows the
status whether a display is connected or not.
There is a GPIO which detects the +3.3V on the line and detects the
cable connect , there is also an interrupt based way.This is ideally
called a Hot-plug detect event according to the spec in HDMI terms.
But what you are saying here is that it is just a poll on the state?
quoted
So I said if the purpose of this function is only to check for the HPD
state bit it is fine.
What does HPD bit tell us then?
HPD state bit tells whether the cable is connected and whether EDID is
ready to be read, But this is a static check that is done in this
function.
Thanks and regards,
Mythri.
From: Tomi Valkeinen <hidden> Date: 2011-09-14 08:57:10
On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote:
On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
quoted
On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen [off-list ref] wrote:
<snip>
quoted
I don't understand this one. How could this be more dynamic? The
function checks the HPD bit, which (based on my observation) shows the
status whether a display is connected or not.
There is a GPIO which detects the +3.3V on the line and detects the
cable connect , there is also an interrupt based way.This is ideally
called a Hot-plug detect event according to the spec in HDMI terms.
But what you are saying here is that it is just a poll on the state?
Yes, it's just for polling, but I don't quite see the difference. A
hot-plug event notifies when the display is connected or disconnected,
and detect() tells if a display is connected. They are all about the
same thing.
quoted
quoted
So I said if the purpose of this function is only to check for the HPD
state bit it is fine.
What does HPD bit tell us then?
HPD state bit tells whether the cable is connected and whether EDID is
This sounds like a good bit to test then. So is there something wrong
with using HPD? How does the GPIO differ from HPD bit?
ready to be read, But this is a static check that is done in this
function.
I don't understand what you mean with "static". The bit changes
dynamically according to the connect/disconnect state, and the bit is
checked dynamically when detect() is called.
Tomi
From: K, Mythri P <hidden> Date: 2011-09-14 12:32:03
Hi,
On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen [off-list ref] wrote:
On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote:
quoted
On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
quoted
On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen [off-list ref] wrote:
<snip>
quoted
quoted
I don't understand this one. How could this be more dynamic? The
function checks the HPD bit, which (based on my observation) shows the
status whether a display is connected or not.
There is a GPIO which detects the +3.3V on the line and detects the
cable connect , there is also an interrupt based way.This is ideally
called a Hot-plug detect event according to the spec in HDMI terms.
But what you are saying here is that it is just a poll on the state?
Yes, it's just for polling, but I don't quite see the difference. A
hot-plug event notifies when the display is connected or disconnected,
and detect() tells if a display is connected. They are all about the
same thing.
quoted
quoted
quoted
So I said if the purpose of this function is only to check for the HPD
state bit it is fine.
What does HPD bit tell us then?
HPD state bit tells whether the cable is connected and whether EDID is
This sounds like a good bit to test then. So is there something wrong
with using HPD? How does the GPIO differ from HPD bit?
quoted
ready to be read, But this is a static check that is done in this
function.
I don't understand what you mean with "static". The bit changes
dynamically according to the connect/disconnect state, and the bit is
checked dynamically when detect() is called.
Well ! Who would call the detect and why ? By Dynamic i meant when the
cable is physically disconnected and connected there is detection
logic which can be implemented either by GPIo/Interrupts.
When you say the cable is connected , what happens in this case when
the cable is connected to say monitor of one resolution and then
plugged out and put to the other. Instead with dynamic method the
based on the physical connect and disconnect the notification would be
sent to any listener.
Thanks and regards,
Mythri.
From: Tomi Valkeinen <hidden> Date: 2011-09-14 14:11:49
On Wed, 2011-09-14 at 17:50 +0530, K, Mythri P wrote:
Hi,
On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote:
quoted
On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
quoted
On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen [off-list ref] wrote:
<snip>
quoted
quoted
I don't understand this one. How could this be more dynamic? The
function checks the HPD bit, which (based on my observation) shows the
status whether a display is connected or not.
There is a GPIO which detects the +3.3V on the line and detects the
cable connect , there is also an interrupt based way.This is ideally
called a Hot-plug detect event according to the spec in HDMI terms.
But what you are saying here is that it is just a poll on the state?
Yes, it's just for polling, but I don't quite see the difference. A
hot-plug event notifies when the display is connected or disconnected,
and detect() tells if a display is connected. They are all about the
same thing.
quoted
quoted
quoted
So I said if the purpose of this function is only to check for the HPD
state bit it is fine.
What does HPD bit tell us then?
HPD state bit tells whether the cable is connected and whether EDID is
This sounds like a good bit to test then. So is there something wrong
with using HPD? How does the GPIO differ from HPD bit?
quoted
ready to be read, But this is a static check that is done in this
function.
I don't understand what you mean with "static". The bit changes
dynamically according to the connect/disconnect state, and the bit is
checked dynamically when detect() is called.
Well ! Who would call the detect and why ? By Dynamic i meant when the
cable is physically disconnected and connected there is detection
logic which can be implemented either by GPIo/Interrupts.
When you say the cable is connected , what happens in this case when
the cable is connected to say monitor of one resolution and then
plugged out and put to the other. Instead with dynamic method the
based on the physical connect and disconnect the notification would be
sent to any listener.
Ok, I see now what you mean.
Yes, you are right, detect() does not "know" if the monitor has changed
between polls, so both notification and polling are needed. I
implemented only polling as there's no HPD event mechanism yet in
omapdss, and also because this was simple and gives DRM basic ability to
detect a monitor.
Tomi
From: K, Mythri P <hidden> Date: 2011-09-15 05:53:43
Hi,
On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen [off-list ref] wrote:
On Wed, 2011-09-14 at 17:50 +0530, K, Mythri P wrote:
quoted
Hi,
On Wed, Sep 14, 2011 at 2:27 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
On Wed, 2011-09-14 at 14:18 +0530, K, Mythri P wrote:
quoted
On Wed, Sep 14, 2011 at 2:04 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
On Wed, 2011-09-14 at 13:57 +0530, K, Mythri P wrote:
quoted
On Wed, Sep 14, 2011 at 12:44 PM, Tomi Valkeinen [off-list ref] wrote:
<snip>
quoted
quoted
I don't understand this one. How could this be more dynamic? The
function checks the HPD bit, which (based on my observation) shows the
status whether a display is connected or not.
There is a GPIO which detects the +3.3V on the line and detects the
cable connect , there is also an interrupt based way.This is ideally
called a Hot-plug detect event according to the spec in HDMI terms.
But what you are saying here is that it is just a poll on the state?
Yes, it's just for polling, but I don't quite see the difference. A
hot-plug event notifies when the display is connected or disconnected,
and detect() tells if a display is connected. They are all about the
same thing.
quoted
quoted
quoted
So I said if the purpose of this function is only to check for the HPD
state bit it is fine.
What does HPD bit tell us then?
HPD state bit tells whether the cable is connected and whether EDID is
This sounds like a good bit to test then. So is there something wrong
with using HPD? How does the GPIO differ from HPD bit?
quoted
ready to be read, But this is a static check that is done in this
function.
I don't understand what you mean with "static". The bit changes
dynamically according to the connect/disconnect state, and the bit is
checked dynamically when detect() is called.
Well ! Who would call the detect and why ? By Dynamic i meant when the
cable is physically disconnected and connected there is detection
logic which can be implemented either by GPIo/Interrupts.
When you say the cable is connected , what happens in this case when
the cable is connected to say monitor of one resolution and then
plugged out and put to the other. Instead with dynamic method the
based on the physical connect and disconnect the notification would be
sent to any listener.
Ok, I see now what you mean.
Yes, you are right, detect() does not "know" if the monitor has changed
between polls, so both notification and polling are needed. I
implemented only polling as there's no HPD event mechanism yet in
omapdss, and also because this was simple and gives DRM basic ability to
detect a monitor.
If it is needed for DRM then it is fine, but with detect renamed to
poll. By next week i should have a patch ready for HPD event
mechanism.
From: Tomi Valkeinen <hidden> Date: 2011-09-15 05:57:45
On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote:
Hi,
On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
Yes, you are right, detect() does not "know" if the monitor has changed
between polls, so both notification and polling are needed. I
implemented only polling as there's no HPD event mechanism yet in
omapdss, and also because this was simple and gives DRM basic ability to
detect a monitor.
If it is needed for DRM then it is fine, but with detect renamed to
poll. By next week i should have a patch ready for HPD event
mechanism.
What is wrong with "detect"? It detects if there's a display connected.
It can be used in polling manner, trying it every n seconds, but it
should also be used even if you use HPD event. I think the normal
sequence would be something like:
1) register HPD event
2) use detect() to see if a monitor is already connected
Tomi
From: Tomi Valkeinen <hidden> Date: 2011-09-15 06:32:51
On Thu, 2011-09-15 at 11:54 +0530, K, Mythri P wrote:
Hi,
On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen [off-list ref] wrote:
quoted
On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote:
quoted
Hi,
On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
quoted
Yes, you are right, detect() does not "know" if the monitor has changed
between polls, so both notification and polling are needed. I
implemented only polling as there's no HPD event mechanism yet in
omapdss, and also because this was simple and gives DRM basic ability to
detect a monitor.
If it is needed for DRM then it is fine, but with detect renamed to
poll. By next week i should have a patch ready for HPD event
mechanism.
What is wrong with "detect"? It detects if there's a display connected.
It can be used in polling manner, trying it every n seconds, but it
should also be used even if you use HPD event. I think the normal
sequence would be something like:
1) register HPD event
2) use detect() to see if a monitor is already connected
I guess polling ever few seconds to detect would be waste of CPU
cycles when there is already a mechanism in the H/w to detect the
connection.
Obviously. Polling is only used if hot-plug-detect is not available. But
detect function can be used even when HPD is available.
Current sequence :
Enable display ( Irrespective of whether the cable is connected on not)
Sequence with HPD:
1.Register for HPD connect.
2.Enable display
3.Notify DRM/Audio/Kernel component that wants to listen to this event.
Why would you enable the display even if there's no monitor connected?
And when the DRM starts, how does DRM know if the display was already
connected? Would you send a HPD event when DRM registers to the event
even if there's no actual plug-in event done (i.e. user actually
connecting the cable)?
And just to clarify, my sequence example was from DRM's point of view.
The HDMI driver shouldn't do anything before DRM/omapfb asks it to do
something.
Tomi
From: K, Mythri P <hidden> Date: 2011-09-15 06:36:43
Hi,
On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen [off-list ref] wrote:
On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote:
quoted
Hi,
On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
quoted
Yes, you are right, detect() does not "know" if the monitor has changed
between polls, so both notification and polling are needed. I
implemented only polling as there's no HPD event mechanism yet in
omapdss, and also because this was simple and gives DRM basic ability to
detect a monitor.
If it is needed for DRM then it is fine, but with detect renamed to
poll. By next week i should have a patch ready for HPD event
mechanism.
What is wrong with "detect"? It detects if there's a display connected.
It can be used in polling manner, trying it every n seconds, but it
should also be used even if you use HPD event. I think the normal
sequence would be something like:
1) register HPD event
2) use detect() to see if a monitor is already connected
I guess polling ever few seconds to detect would be waste of CPU
cycles when there is already a mechanism in the H/w to detect the
connection.
Current sequence :
Enable display ( Irrespective of whether the cable is connected on not)
Sequence with HPD:
1.Register for HPD connect.
2.Enable display
3.Notify DRM/Audio/Kernel component that wants to listen to this event.
Thanks and regards,
Mythri.
From: K, Mythri P <hidden> Date: 2011-09-16 12:53:53
Hi,
On Thu, Sep 15, 2011 at 12:02 PM, Tomi Valkeinen [off-list ref] wrote:
On Thu, 2011-09-15 at 11:54 +0530, K, Mythri P wrote:
quoted
Hi,
On Thu, Sep 15, 2011 at 11:27 AM, Tomi Valkeinen [off-list ref] wrote:
quoted
On Thu, 2011-09-15 at 11:11 +0530, K, Mythri P wrote:
quoted
Hi,
On Wed, Sep 14, 2011 at 7:41 PM, Tomi Valkeinen [off-list ref] wrote:
quoted
quoted
Yes, you are right, detect() does not "know" if the monitor has changed
between polls, so both notification and polling are needed. I
implemented only polling as there's no HPD event mechanism yet in
omapdss, and also because this was simple and gives DRM basic ability to
detect a monitor.
If it is needed for DRM then it is fine, but with detect renamed to
poll. By next week i should have a patch ready for HPD event
mechanism.
What is wrong with "detect"? It detects if there's a display connected.
It can be used in polling manner, trying it every n seconds, but it
should also be used even if you use HPD event. I think the normal
sequence would be something like:
1) register HPD event
2) use detect() to see if a monitor is already connected
I guess polling ever few seconds to detect would be waste of CPU
cycles when there is already a mechanism in the H/w to detect the
connection.
Obviously. Polling is only used if hot-plug-detect is not available. But
detect function can be used even when HPD is available.
quoted
Current sequence :
Enable display ( Irrespective of whether the cable is connected on not)
Sequence with HPD:
1.Register for HPD connect.
2.Enable display
3.Notify DRM/Audio/Kernel component that wants to listen to this event.
Why would you enable the display even if there's no monitor connected?
And when the DRM starts, how does DRM know if the display was already
connected? Would you send a HPD event when DRM registers to the event
even if there's no actual plug-in event done (i.e. user actually
connecting the cable)?
HPD event would be triggered only when the cable is connected , and
the EDID is ready to be read by the monitor. So the question enabling
display doesnt exist. When HDMI is enabled in the HPD mode it will be
in minimal power mode.
Yes then the driver will notify DRM/any module that cable(monitor) is
now connected.
And just to clarify, my sequence example was from DRM's point of view.
The HDMI driver shouldn't do anything before DRM/omapfb asks it to do
something.
Tomi
From: Tomi Valkeinen <hidden> Date: 2011-09-19 06:50:46
On Fri, 2011-09-16 at 18:11 +0530, K, Mythri P wrote:
Hi,
quoted
quoted
Sequence with HPD:
1.Register for HPD connect.
2.Enable display
3.Notify DRM/Audio/Kernel component that wants to listen to this event.
Why would you enable the display even if there's no monitor connected?
And when the DRM starts, how does DRM know if the display was already
connected? Would you send a HPD event when DRM registers to the event
even if there's no actual plug-in event done (i.e. user actually
connecting the cable)?
HPD event would be triggered only when the cable is connected , and
the EDID is ready to be read by the monitor. So the question enabling
display doesnt exist. When HDMI is enabled in the HPD mode it will be
in minimal power mode.
I don't think that will work correctly. "enable" in the current driver
means that the DISPC output will be enabled, and the display is showing
an image.
How would you implement the case with your model where the user wants to
get the EDID information, but doesn't want to enable the display yet
(send an output signal)?
I think we need a new power state for the displays. DSI panels could use
it also, as there's a need to turn them on for configuration before
actually turning on the actual display.
Tomi