On 03/09/14 10:33, Dr. H. Nikolaus Schaller wrote:
the uImage is becoming bigger than needed and needs to be replaced each time a driver is modified.
Well, I'm not against using modules as such, and it should work fine if you just load all the modules in correct order (basically omapdrm/omapfb the last).
However, I'd like to ask you how much bigger the uImage comes? You probably compile the kernel for a certain small set of devices. So we're talking about maybe less than 10 display drivers. I'm purely guessing, but I think we're talking about less than 100kB of data.
Also, usually kernel modules and the kernel image are replaced at the same time, when talking about end user. For development I agree that modules are much nicer.
So again, using modules is fine, and works fine, but for an "end product" I'd just use built-in.
It is possible to enable both omapdrm and omapfb as modules (but not as built-ins), but that's mostly meant for development. Normally you should know which framework you want to use, and just disable the other one.
After a lot of trial and error I found only this config to work on the GTA04: CONFIG_FB=y CONFIG_FB_OMAP2=y CONFIG_OMAP2_DSS=y CONFIG_${PANEL}=m
Setting CONFIG_FB=m automatically sets CONFIG_FB_OMAP2=m (and some others)
Yep. I'd recommend setting CONFIG_FB=y, as that builds the generic fb core into the kernel. No need to load that as a module, even if FB_OMAP2 is a module.
This makes it simply fail to load on OMAP3 (only the panel module loads, but no omapfb or /dev/fb*).
What do you mean "omapfb doesn't load"?
I don't see it in lsmod after boor.
Ok, so is anyone loading it? If is, what error does it give when loading the omapfb module?
Can you share boot logs and .config files?
The current one is here (works on OMAP3 but not on OMAP5):
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/configs/gta04...
Yep. I think it looks ok, except that you have display drivers as modules and omapfb as built-in. As I said, that won't work properly, especially with multi-display boards.
So either have everything as built-in, or omapfb as a module. And make sure in the userspace that the display device modules are loaded first, and omapfb module last.
Note that omapfb module does not depend on the display device modules in any way, so it can't happen automatically. The module load scripts in the userspace need to take care of the order.
I will prepare a log from OMAP3 and one from OMAP5.
Interestingly, a manual "modprobe omapfb" works!
So what does it load automatically if compiled into the kernel and not if a module?
Is there a MODULE_DEVICE_TABLE missing somewhere?
On OMAP5 this "modprobe omapfb" still fails:
[ 48.442782] omapfb omapfb: no of_node; not parsing pinctrl DT [ 48.442850] OMAPFB: omapfb_probe [ 48.446029] omapfb omapfb: failed to find default display [ 48.451668] OMAPFB: free_resources [ 48.451676] OMAPFB: free all fbmem [ 48.455270] omapfb omapfb: failed to setup omapfb [ 48.460221] platform omapfb: Driver omapfb requests probe deferral
The only config I was able to make working on OMAP5 was enabling OMAP_DRM.
Well, I can't say anything from the above log snippet. Please post the full log. All it says above is that it can't find the default display, i.e. the drivers needed for the default display have not been loaded.
Is there a difference of specifying the default display (bootargs?) between OMAP3 and OMAP5?
No.
With DT boot, a display alias in the board .dts file can be used to define display0, which is used as a default display. The user can also give it as a kernel bootarg.
Tomi