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.
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. 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.
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. But the same kernel binary should work on both devices, of course.
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?
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.
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].
Tomi