| Message ID | 1317038365-30650-5-git-send-email-archit@ti.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers |
Received: from mail.tu-berlin.de ([130.149.7.33]) by www.linuxtv.org with esmtp (Exim 4.72) (envelope-from <linux-media-owner@vger.kernel.org>) id 1R89qY-0000Os-9t; Mon, 26 Sep 2011 14:00:12 +0200 X-tubIT-Incoming-IP: 209.132.180.67 Received: from vger.kernel.org ([209.132.180.67]) by mail.tu-berlin.de (exim-4.75/mailfrontend-4) with esmtp id 1R89qX-0002zT-BX; Mon, 26 Sep 2011 13:59:42 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753262Ab1IZL7h (ORCPT <rfc822;patchwork@linuxtv.org> + 5 others); Mon, 26 Sep 2011 07:59:37 -0400 Received: from comal.ext.ti.com ([198.47.26.152]:35268 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752671Ab1IZL7h (ORCPT <rfc822;linux-media@vger.kernel.org>); Mon, 26 Sep 2011 07:59:37 -0400 Received: from dlep34.itg.ti.com ([157.170.170.115]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id p8QBxaVE026076 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2011 06:59:36 -0500 Received: from dlep26.itg.ti.com (smtp-le.itg.ti.com [157.170.170.27]) by dlep34.itg.ti.com (8.13.7/8.13.8) with ESMTP id p8QBxar1014674; Mon, 26 Sep 2011 06:59:36 -0500 (CDT) Received: from DFLE70.ent.ti.com (localhost [127.0.0.1]) by dlep26.itg.ti.com (8.13.8/8.13.8) with ESMTP id p8QBxaB0028543; Mon, 26 Sep 2011 06:59:36 -0500 (CDT) Received: from dlelxv24.itg.ti.com (172.17.1.199) by dfle70.ent.ti.com (128.247.5.40) with Microsoft SMTP Server id 14.1.323.3; Mon, 26 Sep 2011 06:59:36 -0500 Received: from legion.dal.design.ti.com (legion.dal.design.ti.com [128.247.22.53]) by dlelxv24.itg.ti.com (8.13.8/8.13.8) with ESMTP id p8QBxZkO032387; Mon, 26 Sep 2011 06:59:35 -0500 Received: from localhost (a0393947pc.apr.dhcp.ti.com [172.24.137.144]) by legion.dal.design.ti.com (8.11.7p1+Sun/8.11.7) with ESMTP id p8QBxX019792; Mon, 26 Sep 2011 06:59:33 -0500 (CDT) From: Archit Taneja <archit@ti.com> To: <hvaibhav@ti.com> CC: <tomi.valkeinen@ti.com>, <linux-omap@vger.kernel.org>, <sumit.semwal@ti.com>, <linux-media@vger.kernel.org>, Archit Taneja <archit@ti.com> Subject: [PATCH v3 4/4] OMAP_VOUT: Don't trigger updates in omap_vout_probe Date: Mon, 26 Sep 2011 17:29:25 +0530 Message-ID: <1317038365-30650-5-git-send-email-archit@ti.com> X-Mailer: git-send-email 1.7.1 In-Reply-To: <1317038365-30650-1-git-send-email-archit@ti.com> References: <1317038365-30650-1-git-send-email-archit@ti.com> MIME-Version: 1.0 Content-Type: text/plain Sender: linux-media-owner@vger.kernel.org Precedence: bulk List-ID: <linux-media.vger.kernel.org> X-Mailing-List: linux-media@vger.kernel.org X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2011.9.26.115414 X-PMX-Spam: Gauge=IIIIIIII, Probability=8%, Report=' MULTIPLE_RCPTS 0.1, MSGID_ADDED_BY_MTA 0.05, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_1300_1399 0, BODY_SIZE_2000_LESS 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, __ANY_URI 0, __CP_MEDIA_BODY 0, __CP_URI_IN_BODY 0, __CT 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __HAS_X_MAILING_LIST 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __MULTIPLE_RCPTS_CC_X2 0, __SANE_MSGID 0, __TO_MALFORMED_2 0, __TO_NO_NAME 0, __URI_NO_WWW 0, __URI_NS ' X-LSpam-Score: 1.0 (+) X-LSpam-Report: No, score=1.0 required=5.0 tests=BAYES_00=-1.9, KB_DATE_CONTAINS_TAB=2.751, RCVD_IN_DNSWL_MED=-2.3, TAB_IN_FROM=2.494 autolearn=no |
Commit Message
Archit Taneja
Sept. 26, 2011, 11:59 a.m. UTC
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(-)
Comments
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> -----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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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: