From patchwork Tue Nov 27 19:15:40 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Steve Sakoman X-Patchwork-Id: 1812421 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 0F6B63FC54 for ; Tue, 27 Nov 2012 19:15:44 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752985Ab2K0TPm (ORCPT ); Tue, 27 Nov 2012 14:15:42 -0500 Received: from mail-ob0-f174.google.com ([209.85.214.174]:46714 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751764Ab2K0TPl (ORCPT ); Tue, 27 Nov 2012 14:15:41 -0500 Received: by mail-ob0-f174.google.com with SMTP id wc20so11248201obb.19 for ; Tue, 27 Nov 2012 11:15:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=gcl+CGGGxeWJ9mgQs/LXsG47Q8b7Oi7ynZeN/WrpdAE=; b=q8Ag2+yximfgbdhEWBDy/uvaMSDWA6pAL5n7SHPkzwW8f2L2ln2+1IXjdZCTDA56Pw yAZw5cHJW9I5EHWcM3IsYL8+gUcn3H9afYnzHwyZkrmLT7goGRB61950MiUFsd2ypFI3 y4FcNE+zCwgEfJtqliFnWDxdxGPn7I0X/czgmn5SMqTuF3LUj1Z+A/0Vk1HQQFhr+ZIA 8e5Q125FgiKbO+zpqDUC/h0gqE2vzDiF8egFtbCwmNQuHxMSUBmkJn4bdE39ow9Vm0qO efFLojP9NlapCDoEa49I4VZ1UJGkyaUIxoyLTu7bWTuuki3bkN5bZQrygtqqiMxwu/na JtDQ== MIME-Version: 1.0 Received: by 10.182.184.102 with SMTP id et6mr692970obc.102.1354043740212; Tue, 27 Nov 2012 11:15:40 -0800 (PST) Received: by 10.60.64.9 with HTTP; Tue, 27 Nov 2012 11:15:40 -0800 (PST) In-Reply-To: <50B4A4D7.2070203@ti.com> References: <50ADE6A5.3030001@ti.com> <50AF37EA.3080400@ti.com> <50B4A4D7.2070203@ti.com> Date: Tue, 27 Nov 2012 11:15:40 -0800 Message-ID: Subject: Re: omap DSS fails with tft410 driver panel? From: Steve Sakoman To: Tomi Valkeinen Cc: Enric Balletbo Serra , "linux-omap@vger.kernel.org" , Tony Lindgren , Javier Martinez Canillas Sender: linux-omap-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-omap@vger.kernel.org On Tue, Nov 27, 2012 at 3:32 AM, Tomi Valkeinen wrote: > Ok. So X is configuring video2 overlay for some reason. XVideo, perhaps? That was my guess too, and after some digging I am fairly certain this is the case. > 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: > > 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 " I tried something similar over the weekend (just removed the return so I still got the error printout) and found that the simple_check failed in 2 more places. Here is the patch I ended up with to get a successful simple_check: After digging a little more it turned out that the continual restarting of X wasn't due to the above error, but to a build system glitch. So the above issue doesn't block a basic X session. I checked XVideo both with and without the above patch and it is broken in both cases. I'm beginning to suspect that this might be a user space bug and will do a little investigation. Because of this I don't think any dss changes should be made at this point. During my testing I think I uncovered another issue :-( I set omapdss.def_disp=lcd43 on the kernel command line to see if the behavior changed with the LCD as the default device. What I encountered was a null pointer crash: [ 3.483062] fbcvt: 1024x768@60: CVT Name - .786M3-R [ 3.488250] Unable to handle kernel NULL pointer dereference at virtual address 00000028 [ 3.496765] pgd = c0004000 [ 3.499603] [00000028] *pgd=00000000 [ 3.503387] Internal error: Oops: 5 [#1] PREEMPT ARM [ 3.508605] Modules linked in: [ 3.511810] CPU: 0 Not tainted (3.6.0 #1) [ 3.516357] PC is at dss_mgr_check_timings+0x4/0x30 [ 3.521484] LR is at dpi_check_timings+0x18/0xb8 [ 3.526336] pc : [] lr : [] psr: 40000013 [ 3.526336] sp : dec2bd88 ip : 22222222 fp : def7e180 [ 3.538330] r10: def951c0 r9 : def61000 r8 : de41b858 [ 3.543823] r7 : dec2bdfc r6 : c06c0a50 r5 : dec2be00 r4 : deea1cd4 [ 3.550659] r3 : dec1ba40 r2 : dec2bdc8 r1 : dec2be00 r0 : 00000000 [ 3.557495] Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel [ 3.565155] Control: 10c5387d Table: 80004019 DAC: 00000015 [ 3.571166] Process swapper (pid: 1, stack limit = 0xdec2a2f0) [ 3.577270] Stack: (0xdec2bd88 to 0xdec2c000) [ 3.581848] bd80: dec1ba40 c0260dc0 ffffffff deea1cd4 def7e180 c046a7d0 [ 3.590423] bda0: 22222222 22222222 22222222 22222222 deea1cd4 c06c0a50 dec2be00 dec2bdfc [ 3.598968] bdc0: deea1cd4 c06c0a50 dec2be00 c026e738 c06c0a50 00000000 de41b800 c046749c [ 3.607513] bde0: 0000003d c0495788 00000018 00000000 00000010 def98640 dec00140 00000000 [ 3.616088] be00: 03000400 0000dac0 00300020 00040050 0003000f 00000001 00000000 00000000 [ 3.624664] be20: 00000001 00000000 00000000 c0459380 deea257c c06c0d00 dec2be50 00000000 [ 3.633209] be40: c025cc10 c029a98c 00000000 c029ae80 dec075d8 00000000 00000000 de41b800 [ 3.641784] be60: c06c1200 c06c3098 c06c3090 de41b80c 00000002 00000001 de41b800 c0689470 [ 3.650360] be80: def99148 def99148 dec2beb8 c01371c4 dec1ba40 00000000 def99148 decdf208 [ 3.658935] bea0: def95240 c0137e24 00000000 c0054e18 00000000 00000003 decdf208 00000000 [ 3.667510] bec0: c06e25dc c06c3098 c06e25dc c06e25dc c029c728 0000009e 00000000 c068920c [ 3.676055] bee0: 00000000 c029d830 c029d81c c029c514 c06e25dc c06c3098 c06c3098 c06c30cc [ 3.684631] bf00: c06e25dc c029c790 00000000 dec2bf18 c06e25dc c029aa9c dec077d8 decd9670 [ 3.693176] bf20: c06e25dc c06e25dc c06e8868 def95240 00000000 c029bb2c c05a9b18 c05a9b18 [ 3.701751] bf40: c06e25dc 00000001 c06a0c9c c0710300 0000009e c029ccb4 00000000 c06e25c8 [ 3.710296] bf60: 00000001 c06a0c9c c0710300 0000009e c068920c c029daa4 00000007 c06967d8 [ 3.718872] bf80: c06a0c9c c0689234 dec2a000 c0008654 c068920c 976c0d2e c06a0cc4 00000008 [ 3.727447] bfa0: 00000007 c06967d8 c06a0c9c c0710300 0000009e c0669160 c06967e0 c06698d8 [ 3.735992] bfc0: 00000007 00000007 c0669160 00000013 00000000 00000000 00000000 c06697a0 [ 3.744567] bfe0: c000eea8 00000013 00000000 00000000 00000000 c000eea8 fffffff7 dffefffe [ 3.753143] [] (dss_mgr_check_timings+0x4/0x30) from [] (dpi_check_timings+0x18/0xb8) [ 3.763183] [] (dpi_check_timings+0x18/0xb8) from [] (tfp410_check_timings+0x28/0x3c) [ 3.773223] [] (tfp410_check_timings+0x28/0x3c) from [] (omapfb_parse_def_modes+0x338/0x3f4) [ 3.783905] [] (omapfb_parse_def_modes+0x338/0x3f4) from [] (omapfb_probe+0x210/0x600) [ 3.794036] [] (omapfb_probe+0x210/0x600) from [] (platform_drv_probe+0x14/0x18) [ 3.803619] [] (platform_drv_probe+0x14/0x18) from [] (driver_probe_device+0x11c/0x330) [ 3.813812] [] (driver_probe_device+0x11c/0x330) from [] (__driver_attach+0x68/0x8c) [ 3.823760] [] (__driver_attach+0x68/0x8c) from [] (bus_for_each_dev+0x48/0x80) [ 3.833251] [] (bus_for_each_dev+0x48/0x80) from [] (bus_add_driver+0xf0/0x248) [ 3.842742] [] (bus_add_driver+0xf0/0x248) from [] (driver_register+0x9c/0x12c) [ 3.852203] [] (driver_register+0x9c/0x12c) from [] (platform_driver_probe+0x18/0x9c) [ 3.862243] [] (platform_driver_probe+0x18/0x9c) from [] (omapfb_init+0x28/0x54) [ 3.871826] [] (omapfb_init+0x28/0x54) from [] (do_one_initcall+0x90/0x160) [ 3.880950] [] (do_one_initcall+0x90/0x160) from [] (kernel_init+0x138/0x1f8) [ 3.890228] [] (kernel_init+0x138/0x1f8) from [] (kernel_thread_exit+0x0/0x8) [ 3.899566] Code: e3e00015 e8bd8010 c05d88aa e92d4008 (e5900028) [ 3.906097] ---[ end trace 38f657b10d460537 ]--- It seems that dss_mgr_check_timings is being called with a null dssdev->manager. Other than the fact that there should be a null pointer check in the code, it seems that this is a regression since it used to be possible to switch the default display in this fashion. Is this no longer allowed? Steve --- 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 --- a/drivers/video/omap2/dss/overlay.c +++ b/drivers/video/omap2/dss/overlay.c @@ -610,7 +610,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl, { if (info->paddr == 0) { DSSERR("check_overlay: paddr cannot be 0\n"); - return -EINVAL; +// return -EINVAL; } if ((ovl->caps & OMAP_DSS_OVL_CAP_SCALE) == 0) { @@ -630,7 +630,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl, if ((ovl->supported_modes & info->color_mode) == 0) { DSSERR("check_overlay: overlay %d doesn't support mode %d\n", ovl->id, info->color_mode); - return -EINVAL; +// return -EINVAL; } if (info->zorder >= omap_dss_get_num_overlays()) { @@ -641,7 +641,7 @@ int dss_ovl_simple_check(struct omap_overlay *ovl, if (dss_feat_rotation_type_supported(info->rotation_type) == 0) { DSSERR("check_overlay: rotation type %d not supported\n", info->rotation_type); - return -EINVAL; +// return -EINVAL; } return 0;