From patchwork Tue Nov 27 11:32:39 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tomi Valkeinen X-Patchwork-Id: 1810651 Return-Path: X-Original-To: patchwork-linux-omap@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id 71D953FCF6 for ; Tue, 27 Nov 2012 11:32:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755468Ab2K0Lcp (ORCPT ); Tue, 27 Nov 2012 06:32:45 -0500 Received: from comal.ext.ti.com ([198.47.26.152]:36859 "EHLO comal.ext.ti.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755271Ab2K0Lco (ORCPT ); Tue, 27 Nov 2012 06:32:44 -0500 Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id qARBWgU5019153; Tue, 27 Nov 2012 05:32:42 -0600 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id qARBWgeQ012000; Tue, 27 Nov 2012 05:32:42 -0600 Received: from dlelxv22.itg.ti.com (172.17.1.197) by dfle72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.1.323.3; Tue, 27 Nov 2012 05:32:41 -0600 Received: from [172.24.68.10] (h68-10.vpn.ti.com [172.24.68.10]) by dlelxv22.itg.ti.com (8.13.8/8.13.8) with ESMTP id qARBWe7Q006673; Tue, 27 Nov 2012 05:32:40 -0600 Message-ID: <50B4A4D7.2070203@ti.com> Date: Tue, 27 Nov 2012 13:32:39 +0200 From: Tomi Valkeinen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Steve Sakoman CC: Enric Balletbo Serra , "linux-omap@vger.kernel.org" , Tony Lindgren , Javier Martinez Canillas Subject: Re: omap DSS fails with tft410 driver panel? References: <50ADE6A5.3030001@ti.com> <50AF37EA.3080400@ti.com> In-Reply-To: X-Enigmail-Version: 1.4.6 Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On 2012-11-23 17:20, Steve Sakoman wrote: > On Fri, Nov 23, 2012 at 12:46 AM, Tomi Valkeinen wrote: > > >> Ok, so hmm... So the overlay is disabled, and the paddr is zero. Can you >> put a printk at dss/apply.c:dss_olv_set_info, and print ovl->id and >> info->paddr? And perhaps also to omapfb-main.c:omapfb_setup_overlay, at >> the point where it sets info.paddr, as I think that's the only place >> where omapfb sets paddr. > > OK, did that and here is what I get when starting up gdm, prior to > that all is normal > > root@omap3-multi:~# systemctl start gdm.service > Starting Gnome Display Manager... > Started Gnome Display Manager [ OK ] > root@omap3-multi:~# [ 83.475128] omapfb_setup_plane entry > [ 83.479492] setup_overlay 0, posx 0, posy 0, outw 1024, outh 768 > [ 83.485809] omapfb_setup_overlay: setting info.paddr = 9f400000 > [ 83.492431] dss_ovl_set_info entry > [ 83.496307] ovl->id = 0 > [ 83.499267] info->paddr = 9f400000 > [ 83.503601] omapfb_setup_plane: return success > [ 83.508697] omapfb_setup_plane entry > [ 83.513153] dss_ovl_set_info entry > [ 83.516723] ovl->id = 2 > [ 83.520111] info->paddr = 0 > [ 83.523406] omapdss OVERLAY error: check_overlay: paddr cannot be 0 > [ 83.530426] omapfb_setup_plane: !pi->enabled & ovl->set_overlay_info > [ 83.537414] dss_ovl_set_info entry > [ 83.540985] ovl->id = 2 > [ 83.544250] info->paddr = 0 > [ 83.547546] omapdss OVERLAY error: check_overlay: paddr cannot be 0 > > > >> I don't know what's going on there, why the paddr is suddenly zero. >> Looking at the log from Enric, SETUP_PLANE works fine just fine, and >> then, for no reason, next SETUP_PLANE fails, and the log doesn't show >> anything much happening between. >> >> However, I think omapdss may have been more permissive in the past, >> allowing paddr 0 if the overlay is disabled. I could add that back, but >> I'd rather first understand what's happening here. > > From the above it seems that the first SETUP_PLANE is for ovl->id = 0 > and then those that fail are for ovl->id =2. > > No idea what is going on in user space, but maybe this will mean > something to you :-) Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps? Anyway, I guess it's a valid thing to configure the overlay with paddr == 0 when the overlay is disabled. In fact, paddr == 0 check is in any case quite limited, as if the board's physical memory doesn't contain the given paddr, the DSS HW will fail just as it would for paddr 0. So the paddr == 0 check is more of a sanity check than a comprehensive test. Can you try the following patch: Tomi diff --git a/drivers/video/omap2/dss/overlay.c b/drivers/video/omap2/dss/overlay.c index 45f4994..e271e28 100644 --- a/drivers/video/omap2/dss/overlay.c +++ b/drivers/video/omap2/dss/overlay.c @@ -130,11 +130,6 @@ void dss_uninit_overlays(struct platform_device *pdev) int dss_ovl_simple_check(struct omap_overlay *ovl, const struct omap_overlay_info *info) { - if (info->paddr == 0) { - DSSERR("check_overlay: paddr cannot be 0\n"); - return -EINVAL; - } - if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) { if (info->out_width != 0 && info->width != info->out_width) { DSSERR("check_overlay: overlay %d doesn't support "