On Wed, 2010-05-05 at 19:32 +0200, ext Aguirre, Sergio wrote: > Tony, > > > -----Original Message----- > > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > > owner@xxxxxxxxxxxxxxx] On Behalf Of Tony Lindgren > > Sent: Friday, April 30, 2010 3:34 PM > > To: linux-arm-kernel@xxxxxxxxxxxxxxxxxxx > > Cc: linux-omap@xxxxxxxxxxxxxxx > > Subject: [PATCH 11/11] omap2/3/4: Disable CONFIG_FB_OMAP in > > omap3_defconfig > > > > Looks like CONFIG_FB_OMAP prevents somehow mounting root on MMC > > at least on zoom3 for multi-omap. Disable CONFIG_FB until the > > omap FB code is fixed. > > > > This allows booting omap3_defconfig on various omaps. Tested on > > 2420-n8x0, 3430-n900, 3630-zoom3 and 4430-blaze. Note that n8x0 > > still has issues with starting user space because of TLS and > > VFP. > > (Looping Tomi) > > Unfortunately, your patch is uncovering an issue with old DSS code to > compile it as module, which I think is caused by this: > > A single omapfb.ko is attempted to be created in drivers/video/omap/ folder, > but the included source files (DSS code + lcd drivers), results in multiple > module_init entries added in a single module, and therefore giving errors of > duplicate init_module entries between omapfb_main.c and the lcd_*.c files. > > So, either you disable old DSS driver completely, or you have it as > built-in. Ah, yes. I'm not sure if the older omapfb was ever really designed to be used as module... If this is the problem, then my suggestion is to either use it built-in, or use the new DSS2 which works well as modules. I guess the option to compile the older omapfb as a module should be removed? Or if some brave soul wants to start fixing omapfb, that's ok too =). Tomi -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
