Hi Tomi,
Am 30.09.2014 um 07:46 schrieb Tomi Valkeinen:
On 29/09/14 19:51, Dr. H. Nikolaus Schaller wrote:
'vram' is no longer used, only 'cma' is needed.
Do you have a particular need for the 'omapfb.vram' parameter?
Compatibility. So that we don't have to change the boot loader command line for using historic and most modern kernels by just swapping an SD card.
So U-Boot must provide the union of them.
Ok. 'vram' doesn't do any harm, it's just ignored on newer kernels.
'omapfb.vram' still works. And I wondered why would you need that? Nothing wrong with that parameter, if you know that in your use case you require the given amounts of memory for the framebuffers.
Well, I must admit that I don't know why it is needed. It was introduced and needed some time ago foe the OMAP3/BeagleBoard/GTA04 and I guess there have been reasons...
It is the old problem that kernel developers assume that the bootloader can as easily be up/down-graded as the kernel.
I didn't assume anything like that.
This wasn't meant personal. Just a general observation.
It was just that there was a new method in kernel to manage the memory, CMA, which I had to use instead of the hacky and custom 'vram'. I didn't find any way to keep the kernel bootargs compatibility.
No problem with that - since there is a simple solution.
There are other silly old bootargs that I have kept just for the above purpose, like omapdss.def_disp. Nowadays omapdss doesn't handle the concept of default display, but it just passes it forward to the proper components.
'omapfb.mode=dvi'? I don't think the board has DVI output. And even if it has, why set the mode here?
The same kernel/bootargs should work on a BeagleBoard.
No, they shouldn't. Bootargs are device specific.
Yes, they are - but having them device specific only makes trouble... The problem is if the boot loader is in flash memory updating the kernel (on a SD card) to do something special means reflashing.
Our concept is to try to keep the boot-loader stable and have no assumptions about the kernel. So that we can even swap SD cards between different devices.
But the same kernel binary should work on both devices, of course.
The best long-term solution is IMHO to get rid of all bootargs and rely on the device-specific DT which is more or less equivalent of a big bootarg string.
Well, it could be possible that the boot loader fetches device-specific boot-args from SD card but that would duplicate the mechanism that is already used for loading device specific device trees.
Anyways this seems to work.
But I still have a problem induced by the panel driver.
The first one was that the driver wasn't really adjusted to be 3.17 compatible. I have fixed some obvious issues (changing in how timing parameters are specified) but it still fails with:
[ 5.586913] dsi: r63311_enable() [ 5.590282] dsi: r63311_start() [ 5.593668] dsi: r63311_power_on() [ 5.597229] dsi: r63311_reset(0) [ 5.600686] dsi_vm_calc [ 5.603237] clkin=19200000 [ 5.606242] req_pck_min=143739800 [ 5.609896] req_pck_nom=143740800 [ 5.613528] req_pck_max=143741800 [ 5.617163] bitspp=24 [ 5.619709] ndl=4 [ 5.621893] byteclk_min=107804850 [ 5.625522] pll_min=1724877600 [ 5.628889] pll_max=1800000000 [ 5.632254] dsi_pll_calc [ 5.634889] fint_hw_min=150000 [ 5.638250] fint_hw_max=52000000 [ 5.641791] regn_start=1 [ 5.644607] regn_stop=128 [ 5.647515] pll_max=1800000000 [ 5.650877] regn=1 [ 5.653151] fint=19200000 [ 5.656066] regn=2 [ 5.658360] fint=9600000 [ 5.664809] omapdss DSI error: failed to set complexio power state to 1 [ 5.672232] r63311 58004000.encoder:lcd: failed to enable DSI [ 5.678230] r63311 58004000.encoder:lcd: enable failed [ 5.683585] omapfb omapfb: Failed to enable display 'lcd' [ 5.689220] omapfb omapfb: failed to initialize default display [ 5.695392] OMAPFB: free_resources
complexio problems often are related to pinmuxing or similar issues.
Do you have the attached patch?
Ah, no. We are mainly tracking linus/master.
The patch wasn't accepted by Tony, as he wants a DT based solution, and I have not been able to come up with a way to implement such a solution. And as there's been no DSI based boards in the mainline, it has been on low priority.
It works!!! Many thanks!
If the Pyra is finished we will have a DSI based board in the mainline.
So we will help to get it there :)
For the moment we have ca. 120 diffs that we are trying to get mainline so adding another useful one isn't a problem.
Then I tried the same with your R63311 driver [1] (after updating the compatible entry). It shows the same problem.
Full kernel log is attached.
Any ideas or a patch that is not yet in 3.17-rc6?
I think it's the attached patch that you need. I have pushed a branch I used a few days ago to test omap5-uevm with the DSI panel you sent:
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git work/omap5-plus
I think the DSI muxing patch is the only relevant one there, and the patch is also there in [1].
It works (at least tested with the LG R63311 based panel)!
BR and thanks, Nikolaus