* [PATCH v3 0/4] OMAP_VOUT: Misc fixes and cleanup patches for 3.2
@ 2011-09-26 11:59 Archit Taneja
2011-09-26 11:59 ` [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation Archit Taneja
` (3 more replies)
0 siblings, 4 replies; 12+ messages in thread
From: Archit Taneja @ 2011-09-26 11:59 UTC (permalink / raw)
To: hvaibhav
Cc: tomi.valkeinen, linux-omap, sumit.semwal, linux-media,
Archit Taneja
This set includes patches which do the following:
- Fix crash if a we call dssdev->driver->update for a disabled panel.
- Fix the issue of not being able to request for a buffer which is larger than
what we did the last time.
- Remove some redundant code in omap_vout_isr()
- Add basic support for DSI panels
Changes in v3:
- Remove patch "OMAP_VOUT: Fix VSYNC IRQ handling in omap_vout_isr" since its
still not clear whether its needed or not.
Refernce base:
git@gitorious.org:~boddob/linux-omap-dss2/archit-dss2-clone.git 'for_omap_vout2'
Archit Taneja (4):
OMAP_VOUT: Fix check in reqbuf for buf_size allocation
OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr
OMAP_VOUT: Add support for DSI panels
OMAP_VOUT: Don't trigger updates in omap_vout_probe
drivers/media/video/omap/omap_vout.c | 191 ++++++++++++++++------------------
1 files changed, 91 insertions(+), 100 deletions(-)
^ permalink raw reply [flat|nested] 12+ messages in thread* [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation 2011-09-26 11:59 [PATCH v3 0/4] OMAP_VOUT: Misc fixes and cleanup patches for 3.2 Archit Taneja @ 2011-09-26 11:59 ` Archit Taneja 2011-09-27 7:19 ` Hiremath, Vaibhav 2011-09-26 11:59 ` [PATCH v3 2/4] OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr Archit Taneja ` (2 subsequent siblings) 3 siblings, 1 reply; 12+ messages in thread From: Archit Taneja @ 2011-09-26 11:59 UTC (permalink / raw) To: hvaibhav Cc: tomi.valkeinen, linux-omap, sumit.semwal, linux-media, Archit Taneja The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent requesting a larger size buffer than what is allocated at kernel boot during omap_vout_probe. The requested size is compared with vout->buffer_size, this isn't correct as vout->buffer_size is later set to the size requested in reqbuf. When the video device is opened the next time, this check will prevent us to allocate a buffer which is larger than what we requested the last time. Don't use vout->buffer_size, always check with the parameters video1_bufsize or video2_bufsize. Signed-off-by: Archit Taneja <archit@ti.com> --- drivers/media/video/omap/omap_vout.c | 10 ++++++++-- 1 files changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index d9e64f3..16ebff6 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, u32 phy_addr = 0, virt_addr = 0; struct omap_vout_device *vout = q->priv_data; struct omapvideo_info *ovid = &vout->vid_info; + int vid_max_buf_size; if (!vout) return -EINVAL; + vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : + video2_bufsize; + if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type) return -EINVAL; @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct videobuf_queue *q, unsigned int *count, video1_numbuffers : video2_numbuffers; /* Check the size of the buffer */ - if (*size > vout->buffer_size) { + if (*size > vid_max_buf_size) { v4l2_err(&vout->vid_dev->v4l2_dev, "buffer allocation mismatch [%u] [%u]\n", *size, vout->buffer_size); @@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) unsigned long size = (vma->vm_end - vma->vm_start); struct omap_vout_device *vout = file->private_data; struct videobuf_queue *q = &vout->vbq; + int vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : + video2_bufsize; v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, " %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n", __func__, @@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct vm_area_struct *vma) return -EINVAL; } /* Check the size of the buffer */ - if (size > vout->buffer_size) { + if (size > vid_max_buf_size) { v4l2_err(&vout->vid_dev->v4l2_dev, "insufficient memory [%lu] [%u]\n", size, vout->buffer_size); -- 1.7.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* RE: [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation 2011-09-26 11:59 ` [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation Archit Taneja @ 2011-09-27 7:19 ` Hiremath, Vaibhav 2011-09-27 7:23 ` Archit Taneja 0 siblings, 1 reply; 12+ messages in thread From: Hiremath, Vaibhav @ 2011-09-27 7:19 UTC (permalink / raw) To: Taneja, Archit Cc: Valkeinen, Tomi, linux-omap@vger.kernel.org, Semwal, Sumit, linux-media@vger.kernel.org > -----Original Message----- > From: Taneja, Archit > Sent: Monday, September 26, 2011 5:29 PM > To: Hiremath, Vaibhav > Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- > media@vger.kernel.org; Taneja, Archit > Subject: [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size > allocation > > The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent > requesting a larger size buffer than what is allocated at kernel boot > during > omap_vout_probe. > > The requested size is compared with vout->buffer_size, this isn't correct > as > vout->buffer_size is later set to the size requested in reqbuf. When the > video > device is opened the next time, this check will prevent us to allocate a > buffer > which is larger than what we requested the last time. > > Don't use vout->buffer_size, always check with the parameters > video1_bufsize > or video2_bufsize. > > Signed-off-by: Archit Taneja <archit@ti.com> > --- > drivers/media/video/omap/omap_vout.c | 10 ++++++++-- > 1 files changed, 8 insertions(+), 2 deletions(-) > > diff --git a/drivers/media/video/omap/omap_vout.c > b/drivers/media/video/omap/omap_vout.c > index d9e64f3..16ebff6 100644 > --- a/drivers/media/video/omap/omap_vout.c > +++ b/drivers/media/video/omap/omap_vout.c > @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct > videobuf_queue *q, unsigned int *count, > u32 phy_addr = 0, virt_addr = 0; > struct omap_vout_device *vout = q->priv_data; > struct omapvideo_info *ovid = &vout->vid_info; > + int vid_max_buf_size; > > if (!vout) > return -EINVAL; > > + vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : > + video2_bufsize; > + > if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type) > return -EINVAL; > > @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct > videobuf_queue *q, unsigned int *count, > video1_numbuffers : video2_numbuffers; > > /* Check the size of the buffer */ > - if (*size > vout->buffer_size) { > + if (*size > vid_max_buf_size) { > v4l2_err(&vout->vid_dev->v4l2_dev, > "buffer allocation mismatch [%u] [%u]\n", > *size, vout->buffer_size); > @@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct > vm_area_struct *vma) > unsigned long size = (vma->vm_end - vma->vm_start); > struct omap_vout_device *vout = file->private_data; > struct videobuf_queue *q = &vout->vbq; > + int vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : > + video2_bufsize; > > v4l2_dbg(1, debug, &vout->vid_dev->v4l2_dev, > " %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n", __func__, > @@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct > vm_area_struct *vma) > return -EINVAL; > } > /* Check the size of the buffer */ > - if (size > vout->buffer_size) { > + if (size > vid_max_buf_size) { I think we agreed in your last version patch patch-series that, the check in mmap should be against vout->buffer_size. Am I missing something here? Thanks, Vaibhav > v4l2_err(&vout->vid_dev->v4l2_dev, > "insufficient memory [%lu] [%u]\n", > size, vout->buffer_size); > -- > 1.7.1 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation 2011-09-27 7:19 ` Hiremath, Vaibhav @ 2011-09-27 7:23 ` Archit Taneja 0 siblings, 0 replies; 12+ messages in thread From: Archit Taneja @ 2011-09-27 7:23 UTC (permalink / raw) To: Hiremath, Vaibhav Cc: Valkeinen, Tomi, linux-omap@vger.kernel.org, Semwal, Sumit, linux-media@vger.kernel.org Hi, On Tuesday 27 September 2011 12:49 PM, Hiremath, Vaibhav wrote: > >> -----Original Message----- >> From: Taneja, Archit >> Sent: Monday, September 26, 2011 5:29 PM >> To: Hiremath, Vaibhav >> Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- >> media@vger.kernel.org; Taneja, Archit >> Subject: [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size >> allocation >> >> The commit 383e4f69879d11c86ebdd38b3356f6d0690fb4cc makes reqbuf prevent >> requesting a larger size buffer than what is allocated at kernel boot >> during >> omap_vout_probe. >> >> The requested size is compared with vout->buffer_size, this isn't correct >> as >> vout->buffer_size is later set to the size requested in reqbuf. When the >> video >> device is opened the next time, this check will prevent us to allocate a >> buffer >> which is larger than what we requested the last time. >> >> Don't use vout->buffer_size, always check with the parameters >> video1_bufsize >> or video2_bufsize. >> >> Signed-off-by: Archit Taneja<archit@ti.com> >> --- >> drivers/media/video/omap/omap_vout.c | 10 ++++++++-- >> 1 files changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/media/video/omap/omap_vout.c >> b/drivers/media/video/omap/omap_vout.c >> index d9e64f3..16ebff6 100644 >> --- a/drivers/media/video/omap/omap_vout.c >> +++ b/drivers/media/video/omap/omap_vout.c >> @@ -664,10 +664,14 @@ static int omap_vout_buffer_setup(struct >> videobuf_queue *q, unsigned int *count, >> u32 phy_addr = 0, virt_addr = 0; >> struct omap_vout_device *vout = q->priv_data; >> struct omapvideo_info *ovid =&vout->vid_info; >> + int vid_max_buf_size; >> >> if (!vout) >> return -EINVAL; >> >> + vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : >> + video2_bufsize; >> + >> if (V4L2_BUF_TYPE_VIDEO_OUTPUT != q->type) >> return -EINVAL; >> >> @@ -690,7 +694,7 @@ static int omap_vout_buffer_setup(struct >> videobuf_queue *q, unsigned int *count, >> video1_numbuffers : video2_numbuffers; >> >> /* Check the size of the buffer */ >> - if (*size> vout->buffer_size) { >> + if (*size> vid_max_buf_size) { >> v4l2_err(&vout->vid_dev->v4l2_dev, >> "buffer allocation mismatch [%u] [%u]\n", >> *size, vout->buffer_size); >> @@ -865,6 +869,8 @@ static int omap_vout_mmap(struct file *file, struct >> vm_area_struct *vma) >> unsigned long size = (vma->vm_end - vma->vm_start); >> struct omap_vout_device *vout = file->private_data; >> struct videobuf_queue *q =&vout->vbq; >> + int vid_max_buf_size = vout->vid == OMAP_VIDEO1 ? video1_bufsize : >> + video2_bufsize; >> >> v4l2_dbg(1, debug,&vout->vid_dev->v4l2_dev, >> " %s pgoff=0x%lx, start=0x%lx, end=0x%lx\n", __func__, >> @@ -887,7 +893,7 @@ static int omap_vout_mmap(struct file *file, struct >> vm_area_struct *vma) >> return -EINVAL; >> } >> /* Check the size of the buffer */ >> - if (size> vout->buffer_size) { >> + if (size> vid_max_buf_size) { > > I think we agreed in your last version patch patch-series that, the check in mmap should be against vout->buffer_size. Am I missing something here? I totally missed this out for some reason. I'll correct this in the next set. Sorry about this. Archit > > Thanks, > Vaibhav > >> v4l2_err(&vout->vid_dev->v4l2_dev, >> "insufficient memory [%lu] [%u]\n", >> size, vout->buffer_size); >> -- >> 1.7.1 > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH v3 2/4] OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr 2011-09-26 11:59 [PATCH v3 0/4] OMAP_VOUT: Misc fixes and cleanup patches for 3.2 Archit Taneja 2011-09-26 11:59 ` [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation Archit Taneja @ 2011-09-26 11:59 ` Archit Taneja 2011-09-26 11:59 ` [PATCH v3 3/4] OMAP_VOUT: Add support for DSI panels Archit Taneja 2011-09-26 11:59 ` [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe Archit Taneja 3 siblings, 0 replies; 12+ messages in thread From: Archit Taneja @ 2011-09-26 11:59 UTC (permalink / raw) To: hvaibhav Cc: tomi.valkeinen, linux-omap, sumit.semwal, linux-media, Archit Taneja Currently, there is a lot of redundant code is between DPI and VENC panels, this can be made common by moving out field/interlace specific code to a separate function called omapvid_handle_interlace_display(). There is no functional change made. Signed-off-by: Archit Taneja <archit@ti.com> --- drivers/media/video/omap/omap_vout.c | 172 ++++++++++++++++------------------ 1 files changed, 82 insertions(+), 90 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 16ebff6..01c24a4 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -524,10 +524,50 @@ static int omapvid_apply_changes(struct omap_vout_device *vout) return 0; } +static int omapvid_handle_interlace_display(struct omap_vout_device *vout, + unsigned int irqstatus, struct timeval timevalue) +{ + u32 fid; + + if (vout->first_int) { + vout->first_int = 0; + goto err; + } + + if (irqstatus & DISPC_IRQ_EVSYNC_ODD) + fid = 1; + else if (irqstatus & DISPC_IRQ_EVSYNC_EVEN) + fid = 0; + else + goto err; + + vout->field_id ^= 1; + if (fid != vout->field_id) { + if (fid == 0) + vout->field_id = fid; + } else if (0 == fid) { + if (vout->cur_frm == vout->next_frm) + goto err; + + vout->cur_frm->ts = timevalue; + vout->cur_frm->state = VIDEOBUF_DONE; + wake_up_interruptible(&vout->cur_frm->done); + vout->cur_frm = vout->next_frm; + } else { + if (list_empty(&vout->dma_queue) || + (vout->cur_frm != vout->next_frm)) + goto err; + } + + return vout->field_id; +err: + return 0; +} + static void omap_vout_isr(void *arg, unsigned int irqstatus) { - int ret; - u32 addr, fid; + int ret, fid; + u32 addr; struct omap_overlay *ovl; struct timeval timevalue; struct omapvideo_info *ovid; @@ -548,107 +588,59 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) spin_lock(&vout->vbq_lock); do_gettimeofday(&timevalue); - if (cur_display->type != OMAP_DISPLAY_TYPE_VENC) { - switch (cur_display->type) { - case OMAP_DISPLAY_TYPE_DPI: - if (!(irqstatus & (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) - goto vout_isr_err; - break; - case OMAP_DISPLAY_TYPE_HDMI: - if (!(irqstatus & DISPC_IRQ_EVSYNC_EVEN)) - goto vout_isr_err; - break; - default: + switch (cur_display->type) { + case OMAP_DISPLAY_TYPE_DPI: + if (!(irqstatus & (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) goto vout_isr_err; - } - if (!vout->first_int && (vout->cur_frm != vout->next_frm)) { - vout->cur_frm->ts = timevalue; - vout->cur_frm->state = VIDEOBUF_DONE; - wake_up_interruptible(&vout->cur_frm->done); - vout->cur_frm = vout->next_frm; - } - vout->first_int = 0; - if (list_empty(&vout->dma_queue)) + break; + case OMAP_DISPLAY_TYPE_VENC: + fid = omapvid_handle_interlace_display(vout, irqstatus, + timevalue); + if (!fid) goto vout_isr_err; + break; + case OMAP_DISPLAY_TYPE_HDMI: + if (!(irqstatus & DISPC_IRQ_EVSYNC_EVEN)) + goto vout_isr_err; + break; + default: + goto vout_isr_err; + } - vout->next_frm = list_entry(vout->dma_queue.next, - struct videobuf_buffer, queue); - list_del(&vout->next_frm->queue); - - vout->next_frm->state = VIDEOBUF_ACTIVE; - - addr = (unsigned long) vout->queued_buf_addr[vout->next_frm->i] - + vout->cropped_offset; + if (!vout->first_int && (vout->cur_frm != vout->next_frm)) { + vout->cur_frm->ts = timevalue; + vout->cur_frm->state = VIDEOBUF_DONE; + wake_up_interruptible(&vout->cur_frm->done); + vout->cur_frm = vout->next_frm; + } - /* First save the configuration in ovelray structure */ - ret = omapvid_init(vout, addr); - if (ret) - printk(KERN_ERR VOUT_NAME - "failed to set overlay info\n"); - /* Enable the pipeline and set the Go bit */ - ret = omapvid_apply_changes(vout); - if (ret) - printk(KERN_ERR VOUT_NAME "failed to change mode\n"); - } else { + vout->first_int = 0; + if (list_empty(&vout->dma_queue)) + goto vout_isr_err; - if (vout->first_int) { - vout->first_int = 0; - goto vout_isr_err; - } - if (irqstatus & DISPC_IRQ_EVSYNC_ODD) - fid = 1; - else if (irqstatus & DISPC_IRQ_EVSYNC_EVEN) - fid = 0; - else - goto vout_isr_err; + vout->next_frm = list_entry(vout->dma_queue.next, + struct videobuf_buffer, queue); + list_del(&vout->next_frm->queue); - vout->field_id ^= 1; - if (fid != vout->field_id) { - if (0 == fid) - vout->field_id = fid; + vout->next_frm->state = VIDEOBUF_ACTIVE; - goto vout_isr_err; - } - if (0 == fid) { - if (vout->cur_frm == vout->next_frm) - goto vout_isr_err; - - vout->cur_frm->ts = timevalue; - vout->cur_frm->state = VIDEOBUF_DONE; - wake_up_interruptible(&vout->cur_frm->done); - vout->cur_frm = vout->next_frm; - } else if (1 == fid) { - if (list_empty(&vout->dma_queue) || - (vout->cur_frm != vout->next_frm)) - goto vout_isr_err; - - vout->next_frm = list_entry(vout->dma_queue.next, - struct videobuf_buffer, queue); - list_del(&vout->next_frm->queue); - - vout->next_frm->state = VIDEOBUF_ACTIVE; - addr = (unsigned long) - vout->queued_buf_addr[vout->next_frm->i] + - vout->cropped_offset; - /* First save the configuration in ovelray structure */ - ret = omapvid_init(vout, addr); - if (ret) - printk(KERN_ERR VOUT_NAME - "failed to set overlay info\n"); - /* Enable the pipeline and set the Go bit */ - ret = omapvid_apply_changes(vout); - if (ret) - printk(KERN_ERR VOUT_NAME - "failed to change mode\n"); - } + addr = (unsigned long) vout->queued_buf_addr[vout->next_frm->i] + + vout->cropped_offset; - } + /* First save the configuration in ovelray structure */ + ret = omapvid_init(vout, addr); + if (ret) + printk(KERN_ERR VOUT_NAME + "failed to set overlay info\n"); + /* Enable the pipeline and set the Go bit */ + ret = omapvid_apply_changes(vout); + if (ret) + printk(KERN_ERR VOUT_NAME "failed to change mode\n"); vout_isr_err: spin_unlock(&vout->vbq_lock); } - /* Video buffer call backs */ /* -- 1.7.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v3 3/4] OMAP_VOUT: Add support for DSI panels 2011-09-26 11:59 [PATCH v3 0/4] OMAP_VOUT: Misc fixes and cleanup patches for 3.2 Archit Taneja 2011-09-26 11:59 ` [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation Archit Taneja 2011-09-26 11:59 ` [PATCH v3 2/4] OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr Archit Taneja @ 2011-09-26 11:59 ` Archit Taneja 2011-09-26 11:59 ` [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe Archit Taneja 3 siblings, 0 replies; 12+ messages in thread From: Archit Taneja @ 2011-09-26 11:59 UTC (permalink / raw) To: hvaibhav Cc: tomi.valkeinen, linux-omap, sumit.semwal, linux-media, Archit Taneja Add support for DSI panels. DSI video mode panels will work directly. For command mode panels, we will need to trigger updates regularly. This isn't done by the omap_vout driver currently. It can still be supported if we connect a framebuffer device to the panel and configure it in auto update mode. Signed-off-by: Archit Taneja <archit@ti.com> --- drivers/media/video/omap/omap_vout.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 01c24a4..7b8e87a 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -589,6 +589,7 @@ static void omap_vout_isr(void *arg, unsigned int irqstatus) do_gettimeofday(&timevalue); switch (cur_display->type) { + case OMAP_DISPLAY_TYPE_DSI: case OMAP_DISPLAY_TYPE_DPI: if (!(irqstatus & (DISPC_IRQ_VSYNC | DISPC_IRQ_VSYNC2))) goto vout_isr_err; -- 1.7.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe 2011-09-26 11:59 [PATCH v3 0/4] OMAP_VOUT: Misc fixes and cleanup patches for 3.2 Archit Taneja ` (2 preceding siblings ...) 2011-09-26 11:59 ` [PATCH v3 3/4] OMAP_VOUT: Add support for DSI panels Archit Taneja @ 2011-09-26 11:59 ` Archit Taneja 2011-09-27 6:10 ` Tomi Valkeinen 2011-09-27 6:26 ` Hiremath, Vaibhav 3 siblings, 2 replies; 12+ messages in thread From: Archit Taneja @ 2011-09-26 11:59 UTC (permalink / raw) To: hvaibhav Cc: tomi.valkeinen, linux-omap, sumit.semwal, linux-media, Archit Taneja Remove the code in omap_vout_probe() which calls display->driver->update() for all the displays. This isn't correct because: - An update in probe doesn't make sense, because we don't have any valid content to show at this time. - Calling update for a panel which isn't enabled is not supported by DSS2. This leads to a crash at probe. Signed-off-by: Archit Taneja <archit@ti.com> --- drivers/media/video/omap/omap_vout.c | 8 -------- 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/drivers/media/video/omap/omap_vout.c b/drivers/media/video/omap/omap_vout.c index 7b8e87a..3d9c83e 100644 --- a/drivers/media/video/omap/omap_vout.c +++ b/drivers/media/video/omap/omap_vout.c @@ -2213,14 +2213,6 @@ static int __init omap_vout_probe(struct platform_device *pdev) if (ret) goto probe_err2; - for (i = 0; i < vid_dev->num_displays; i++) { - struct omap_dss_device *display = vid_dev->displays[i]; - - if (display->driver->update) - display->driver->update(display, 0, 0, - display->panel.timings.x_res, - display->panel.timings.y_res); - } return 0; probe_err2: -- 1.7.1 ^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe 2011-09-26 11:59 ` [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe Archit Taneja @ 2011-09-27 6:10 ` Tomi Valkeinen 2011-09-27 7:02 ` Archit Taneja 2011-09-27 6:26 ` Hiremath, Vaibhav 1 sibling, 1 reply; 12+ messages in thread From: Tomi Valkeinen @ 2011-09-27 6:10 UTC (permalink / raw) To: Archit Taneja; +Cc: hvaibhav, linux-omap, sumit.semwal, linux-media On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote: > Remove the code in omap_vout_probe() which calls display->driver->update() for > all the displays. This isn't correct because: > > - An update in probe doesn't make sense, because we don't have any valid content > to show at this time. > - Calling update for a panel which isn't enabled is not supported by DSS2. This > leads to a crash at probe. Calling update() on a disabled panel should not crash... Where is the crash coming from? Tomi ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe 2011-09-27 6:10 ` Tomi Valkeinen @ 2011-09-27 7:02 ` Archit Taneja 2011-09-27 7:07 ` Tomi Valkeinen 0 siblings, 1 reply; 12+ messages in thread From: Archit Taneja @ 2011-09-27 7:02 UTC (permalink / raw) To: Valkeinen, Tomi Cc: Hiremath, Vaibhav, linux-omap@vger.kernel.org, Semwal, Sumit, linux-media@vger.kernel.org On Tuesday 27 September 2011 11:40 AM, Valkeinen, Tomi wrote: > On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote: >> Remove the code in omap_vout_probe() which calls display->driver->update() for >> all the displays. This isn't correct because: >> >> - An update in probe doesn't make sense, because we don't have any valid content >> to show at this time. >> - Calling update for a panel which isn't enabled is not supported by DSS2. This >> leads to a crash at probe. > > Calling update() on a disabled panel should not crash... Where is the > crash coming from? you are right, the crash isn't coming from the updates. I see the crash when we have 4 dss devices in our board file. The last display pointer is corrupted in that case. I'm trying to figure out why. Archit > > Tomi > > ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe 2011-09-27 7:02 ` Archit Taneja @ 2011-09-27 7:07 ` Tomi Valkeinen 2011-09-27 7:15 ` Archit Taneja 0 siblings, 1 reply; 12+ messages in thread From: Tomi Valkeinen @ 2011-09-27 7:07 UTC (permalink / raw) To: Archit Taneja Cc: Hiremath, Vaibhav, linux-omap@vger.kernel.org, Semwal, Sumit, linux-media@vger.kernel.org On Tue, 2011-09-27 at 12:32 +0530, Archit Taneja wrote: > On Tuesday 27 September 2011 11:40 AM, Valkeinen, Tomi wrote: > > On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote: > >> Remove the code in omap_vout_probe() which calls display->driver->update() for > >> all the displays. This isn't correct because: > >> > >> - An update in probe doesn't make sense, because we don't have any valid content > >> to show at this time. > >> - Calling update for a panel which isn't enabled is not supported by DSS2. This > >> leads to a crash at probe. > > > > Calling update() on a disabled panel should not crash... Where is the > > crash coming from? > > you are right, the crash isn't coming from the updates. I see the crash > when we have 4 dss devices in our board file. The last display pointer > is corrupted in that case. I'm trying to figure out why. Could be totally unrelated, but does the V4L2 driver make sure that the used dss devices have a driver loaded? OMAPFB previously refused to start if all the devices do not have a driver, but nowadays it starts fine by skipping the devices without a driver. Tomi ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe 2011-09-27 7:07 ` Tomi Valkeinen @ 2011-09-27 7:15 ` Archit Taneja 0 siblings, 0 replies; 12+ messages in thread From: Archit Taneja @ 2011-09-27 7:15 UTC (permalink / raw) To: Valkeinen, Tomi Cc: Hiremath, Vaibhav, linux-omap@vger.kernel.org, Semwal, Sumit, linux-media@vger.kernel.org On Tuesday 27 September 2011 12:37 PM, Valkeinen, Tomi wrote: > On Tue, 2011-09-27 at 12:32 +0530, Archit Taneja wrote: >> On Tuesday 27 September 2011 11:40 AM, Valkeinen, Tomi wrote: >>> On Mon, 2011-09-26 at 17:29 +0530, Archit Taneja wrote: >>>> Remove the code in omap_vout_probe() which calls display->driver->update() for >>>> all the displays. This isn't correct because: >>>> >>>> - An update in probe doesn't make sense, because we don't have any valid content >>>> to show at this time. >>>> - Calling update for a panel which isn't enabled is not supported by DSS2. This >>>> leads to a crash at probe. >>> >>> Calling update() on a disabled panel should not crash... Where is the >>> crash coming from? >> >> you are right, the crash isn't coming from the updates. I see the crash >> when we have 4 dss devices in our board file. The last display pointer >> is corrupted in that case. I'm trying to figure out why. > > Could be totally unrelated, but does the V4L2 driver make sure that the > used dss devices have a driver loaded? > > OMAPFB previously refused to start if all the devices do not have a > driver, but nowadays it starts fine by skipping the devices without a > driver. The drivers were loaded in. The issue was something else totally. I assumed it was something related to update call. In drivers/media/video/omap/omap_voutdef.h: struct omap2video_device { ... ... struct omap_dss_device *displays[MAX_DISPLAYS]; ... ... }; MAX_DISPLAYS is 3, so the 4th display pointer was getting messed up wherever we used it. I guess we don't need this patch. We may want to set MAX_DISPLAYS to a higher number i guess, because we could theoretically register as many panels as we want, and set/unset them. Thanks, Archit > > Tomi > > > -- > 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe 2011-09-26 11:59 ` [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe Archit Taneja 2011-09-27 6:10 ` Tomi Valkeinen @ 2011-09-27 6:26 ` Hiremath, Vaibhav 1 sibling, 0 replies; 12+ messages in thread From: Hiremath, Vaibhav @ 2011-09-27 6:26 UTC (permalink / raw) To: Taneja, Archit Cc: Valkeinen, Tomi, linux-omap@vger.kernel.org, Semwal, Sumit, linux-media@vger.kernel.org > -----Original Message----- > From: Taneja, Archit > Sent: Monday, September 26, 2011 5:29 PM > To: Hiremath, Vaibhav > Cc: Valkeinen, Tomi; linux-omap@vger.kernel.org; Semwal, Sumit; linux- > media@vger.kernel.org; Taneja, Archit > Subject: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in > omap_vout_probe > > Remove the code in omap_vout_probe() which calls display->driver->update() > for > all the displays. This isn't correct because: > > - An update in probe doesn't make sense, because we don't have any valid > content > to show at this time. > - Calling update for a panel which isn't enabled is not supported by DSS2. > This > leads to a crash at probe. > It should not crash, do you have crash log here? Thanks, Vaibhav > Signed-off-by: Archit Taneja <archit@ti.com> > --- > drivers/media/video/omap/omap_vout.c | 8 -------- > 1 files changed, 0 insertions(+), 8 deletions(-) > > diff --git a/drivers/media/video/omap/omap_vout.c > b/drivers/media/video/omap/omap_vout.c > index 7b8e87a..3d9c83e 100644 > --- a/drivers/media/video/omap/omap_vout.c > +++ b/drivers/media/video/omap/omap_vout.c > @@ -2213,14 +2213,6 @@ static int __init omap_vout_probe(struct > platform_device *pdev) > if (ret) > goto probe_err2; > > - for (i = 0; i < vid_dev->num_displays; i++) { > - struct omap_dss_device *display = vid_dev->displays[i]; > - > - if (display->driver->update) > - display->driver->update(display, 0, 0, > - display->panel.timings.x_res, > - display->panel.timings.y_res); > - } > return 0; > > probe_err2: > -- > 1.7.1 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2011-09-27 7:23 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-09-26 11:59 [PATCH v3 0/4] OMAP_VOUT: Misc fixes and cleanup patches for 3.2 Archit Taneja 2011-09-26 11:59 ` [PATCH v3 1/4] OMAP_VOUT: Fix check in reqbuf for buf_size allocation Archit Taneja 2011-09-27 7:19 ` Hiremath, Vaibhav 2011-09-27 7:23 ` Archit Taneja 2011-09-26 11:59 ` [PATCH v3 2/4] OMAP_VOUT: CLEANUP: Remove redundant code from omap_vout_isr Archit Taneja 2011-09-26 11:59 ` [PATCH v3 3/4] OMAP_VOUT: Add support for DSI panels Archit Taneja 2011-09-26 11:59 ` [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe Archit Taneja 2011-09-27 6:10 ` Tomi Valkeinen 2011-09-27 7:02 ` Archit Taneja 2011-09-27 7:07 ` Tomi Valkeinen 2011-09-27 7:15 ` Archit Taneja 2011-09-27 6:26 ` Hiremath, Vaibhav
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox