Hi Tomi,
Am 03.09.2014 um 07:19 schrieb Tomi Valkeinen:
On 02/09/14 19:39, Dr. H. Nikolaus Schaller wrote:
Hi Tomi,
Am 02.09.2014 um 14:00 schrieb Tomi Valkeinen:
On 02/09/14 12:51, Dr. H. Nikolaus Schaller wrote:
Config:
http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=arch/arm/configs/gta04...
You seem to have a mix built-in and modules for the display drivers. I'd recommend just using one, either build all as modules, or all as built-in. Makes life easier.
But blows up the kernel if all panel drivers are compiled into a universal kernel.
Works fine for me.
What issue are you seeing?
the uImage is becoming bigger than needed and needs to be replaced each time a driver is modified.
In your case, I think the main problem is that you have omapfb as built-in, but display devices as modules.
Yes. The intention is that only the one panel driver is loaded that is needed on a specific device. All controlled by the device tree.
omapfb doesn't support "hotplugging" new displays. So when you at some point load the display modules related to HDMI, omapfb has already decided that there are no displays.
Ok, I see.
Strangely it did work on the GTA04 (different panels) with the original settings. I.e.. omapfb=y and panel=m (which is deferred because it has to wait for an SPI interface).
Hmm, ok. Well, I realized that what I said above isn't quite: omapfb does return -EPROBE_DEFER if there are no displays, or if the user has defined a default display and that's not found.
Ok.
So having omapfb as built-in and display drivers as modules does indeed work, kind of. I was able to get HDMI display working on omap5 uevm with omapdss and omapfb built-in, and then loading connector-hdmi.ko and encoder-tpd12s015.ko.
However, if you have two displays, the above is not good. The result will be that the first display which is loaded will cause omapfb to succeed, and the second display will be ignored as omapfb is already running.
I see. On the GTA04 we only have one display (I have not yet worked on re-enabling the VENC and OPA362 on DT and new DSS).
So that may be the difference to the OMAP5432EVM with HDMI + Panel.
Interestingly with all being modules it does NOT work on GTA04 (OMAP3). I can config the panel as module but not the omapfb.
Are you saying that kernel menuconfig prevents you from turning omapfb to a module?
no, I mean that I can configure it but it does not work.
So either build everything into kernel, or build them as modules, and load omapfb last.
After enabling omap_drm=m to be a module as well, I get a /dev/fb0 on the OMAP5, but it does no longer work on the OMAP3.
So do you want to use omapdrm or omapfb?
I would like to use omapfb (others might be interested in omapdrm).
Configuring for omapdrm was just a test.
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)
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.
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...
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?
BR, Nikolaus