Reply
Thread Tools
Stskeeps's Avatar
Posts: 1,671 | Thanked: 11,478 times | Joined on Jun 2008 @ Warsaw, Poland
#1
This is a continuation of the very lengthy thread of The N800 has a 3D accelerator, right?

Instead, this focuses on actually getting the drivers and libraries to play nice. As it really should be possible.

I think we should be focusing on Graphics_SDK/OMAP24xx_MBX_SDK_N8xx/MBX_Linux_KM/embedded/3rdparty/omap24xx_lcd , not the MBX part of it (which looks cross-device).

Now, where do we stand. The first clue is that the OMAPLCD can't get an IRQ. Now, what is this IRQ/interrupt used for? Vsync (omaplcd_linux.c, InstallVsyncISR())

What's Vsync? Some of you may know this from discussions about tearing, etc. In this case, the interrupt it is waiting for, is the signal that it has begun to update the display and we can start filling in the framebuffer with the next frame.

Now, this is what the driver does, except that well, the framebuffer it is filling into, is the one that is 'staging area' for the real LCD framebuffer. In N8x0, this is the old OMAP framebuffer. We have to send a signal to update the LCD framebuffer. This is also why the driver doesn't work for N8x0 as intended but shows results if we really force a framebuffer transfer.

In the old setup, a Vsync interrupt would be the indication to the driver to take a frame from the queue of rendered frames, remove it from the queue and point the framebuffer pointer at it, as I understand it. This is the Flip() stuff mentioned in the kernel.

In our N8x0 setup, we would not have a Vsync interrupt. We might be able to get one through Blizzard though.

We'd be replacing the Flip() command with our own - take a rendered frame from the queue, push it to LCD controller. See blizzard.c in kernel for reference.

However, if we don't have a vsync interrupt, we will have to find some way to push as soon as we get a frame. As far as I can see, omaplcd_ddc_process_vsyncflip is the entry point for the new frames, which gets added into the queue.

So, for starters, I would see if we can hack omaplcd_ddc_process_vsyncflip to do our bidding.

It looks like VSyncFlip takes render items, Flip()s them and then runs a 'command complete' signal.

Now, shouldn't it be in reach to make this driver do our bidding?

EDIT: Wouldn't it work 'for starters' to hack the omaplcd_ddc_process_vsyncflip to flip immediately, not put in queue and have a user process regularly sending the 'update window' ioctl?
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.

Last edited by Stskeeps; 2010-05-11 at 20:53.
 

The Following 41 Users Say Thank You to Stskeeps For This Useful Post:
Posts: 2,152 | Thanked: 1,490 times | Joined on Jan 2006 @ Czech Republic
#2
Hello. When reading this I feel ashamed that I constantly cannot find any time to work on this and yet I think could do a lot. Too bad the whole Maemo thing didn't start few years earlier. I wish I could give same time to N8x0/N900 that I spent with 770. Now back to the 3d.

There is the http://wiki.maemo.org/MBX_drivers_status page, please update it with your findings if possible. With my last update I see it ends with "TODO - document GPL-ed kernel parts" which means Stskeeps had to figure it out again in the post above :-(

Yes omaplcd is the device dependent part of 3d drivers that needs to be changed.

As for the vsync in N8x0 situation. I think we don't want to hook into vsync interrrupt directly. Current omapfb driver already uses it quite sensibly. You either schedule omapfb update and it is started immediatelly (either for smaller screen parts or if you don't care) or you can set the tearsync flag when doing the update ioctl (fullscreen update in video playback) and the update is fired automatically next time vsync comes. So the omaplcd flip matches to scheduling omapfb update with tearsync flag. But for the start this can be ignored, just scheduling the update would be good start.

Next question is where the 3d frame buffers should be stored and how it relates to already preallocated three omapfb planes. This is related to the current allocation failure. As mentioned in older thread I think it should be doable to steal/render into already allocated planes instead of allocating yet another memory dynamically.

This relates to the
PVRSRV_ERROR GetBackBuffer(OMAPLCD_DEVINFO *psDevInfo, IMG_UINT32 ui32Num) procedure. There is code for static memory (flipbuffers array) and dynamic memory and default is dynamic one.

Current sizes of already allocated memory ( see also this)
omapfb: s1d13745 LCD controller rev 1 initialized (CNF pins 3)
omapfb: region0 phys 80600000 virt ffa01000 size=770048 type=0
omapfb: region1 phys 80700000 virt ffabd000 size=786432 type=0
omapfb: region2 phys 87c00000 virt ffb7d000 size=1572864 type=0
omapfb: Framebuffer initialized. Total vram 3129344 planes 3

I think the last plane is good enough for two 800x480x16bits flipbuffers. Basically I think we should abuse the current way how Xvideo and video output is done but instead of video we should point 3d chip to same memory overwriting the video. This would also allow scaling in the same way it currently works with video etc. Sounds crazy? Maybe it is.

I'l try to get back to documenting what I know about the 3d kernel part in the wiki.

Additionally for anyone working on this it could helpful to be familiar with omapfb driver and how it works with external display controllers. The 770 version is a bit easier to understand. N8x0 version is similar, it just switches sossi for rfbi for transfering the data, hw472.c is replaced with blizzard.c and the biggest difference is adding 3 planes due to OMAP2 chip having native support for 3 planes (named GFX, VID0,VID1?) . It was not clear to me at the time N800 came since there is no OMAP2 documentation but when OMAP3 came recently, it looks to me that the video subsystem of OMAP2 is exactly the same as OMAP3 (planes, tv-out, dispc, rfbi ..) so I finally understand a bit better why there are three planes allocated when in the end all three are merged anyway when transferring display data to the epson chip.

Also maybe it should be useful to study how omaplcd.ko part of SGX driver for OMAP3 works since it could be quite similar.
__________________
Newbies click here before posting. Thanks.

If you really need to PM me with troubleshooting question please consider posting it to the forum instead. It is OK to PM me a link to such post then. Thank you.

Last edited by fanoush; 2010-05-12 at 08:27. Reason: typos
 

The Following 25 Users Say Thank You to fanoush For This Useful Post:
Stskeeps's Avatar
Posts: 1,671 | Thanked: 11,478 times | Joined on Jun 2008 @ Warsaw, Poland
#3
Originally Posted by fanoush View Post
Next question is where the 3d frame buffers should be stored and how it relates to already preallocated three omapfb planes. This is related to the current allocation failure. As mentioned in older thread I think it should be doable to steal/render into already allocated planes instead of allocating yet another memory dynamically.

This relates to the
PVRSRV_ERROR GetBackBuffer(OMAPLCD_DEVINFO *psDevInfo, IMG_UINT32 ui32Num) procedure. There is code for static memory (flipbuffers array) and dynamic memory and default is dynamic one.

Current sizes of already allocated memory ( see also this)
omapfb: s1d13745 LCD controller rev 1 initialized (CNF pins 3)
omapfb: region0 phys 80600000 virt ffa01000 size=770048 type=0
omapfb: region1 phys 80700000 virt ffabd000 size=786432 type=0
omapfb: region2 phys 87c00000 virt ffb7d000 size=1572864 type=0
omapfb: Framebuffer initialized. Total vram 3129344 planes 3

I think the last plane is good enough for two 800x480x16bits flipbuffers.
There is two parameters to the omaplcd module:

module_param(fbsize, long, 0);
MODULE_PARM_DESC(fbsize, "Sets the size of the buffers in a flip chain (default=153600)");
module_param_array(flipbuffers, long, 0, 0);
MODULE_PARM_DESC(flipbuffers, "Sets the address of the buffers in a flip chain (default=0 -> allocated)");

And a piece of code further down, looks a little broken:

#if (LINUX_VERSION_CODE < KERNEL_VERSION(2,6,0))
for(i=0; i < OMAPLCD_MAX_BACKBUFFERS + 1; i++)
{
if(flipbuffers[i])
num_buffers++;
}
#endif

- num_buffers should probably be set to 2 in this case. We can probably hardwire the locations and num_buffers to the video framebuffer
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.
 

The Following 5 Users Say Thank You to Stskeeps For This Useful Post:
qole's Avatar
Moderator | Posts: 7,109 | Thanked: 8,820 times | Joined on Oct 2007 @ Vancouver, BC, Canada
#4
Oh! fanoush just showed up. If he sticks around, this could really start moving forward! If Stskeeps and fanoush start working together on this, we'll have to come up with a superhero team name for them.

Framebuffer flippers? 3D Heroes?
__________________
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!
 

The Following User Says Thank You to qole For This Useful Post:
Texrat's Avatar
Posts: 11,700 | Thanked: 10,045 times | Joined on Jun 2006 @ North Texas, USA
#5
Originally Posted by qole View Post
If Stskeeps and fanoush start working together on this, we'll have to come up with a superhero team name for them.

Framebuffer flippers? 3D Heroes?

...Avatars?

/me ducks and runs
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
 
Posts: 637 | Thanked: 445 times | Joined on Dec 2009 @ Kaliningrad, Russia
#6
Crysis please.

P.S. I don't understand any word you wrote, but it seems to be something nice
 
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#7
I hate how the driver works. So omaplcd passes mbxaccess a .so filename which passes it to its clients which dlopen it which use it to access the /dev/omaplcd device node which gets back to omaplcd again which eventually sets omap dss registers on its own or calls mbxaccess.

This is clearly designed so that the author of display class device drivers can choose whether to implement most of the logic in user space or kernel space -- If we could follow this we could create a libomaplcd.so replacement which calls into blizzard/xv/omaplcd/whatever user space library you can think of.

But of course, we can't.

Last edited by javispedro; 2010-05-12 at 19:15.
 

The Following User Says Thank You to javispedro For This Useful Post:
qole's Avatar
Moderator | Posts: 7,109 | Thanked: 8,820 times | Joined on Oct 2007 @ Vancouver, BC, Canada
#8
Ah, I almost forgot that other superhero of the 3D drivers, javispedro!

Framebuffer Flippers GO!
__________________
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!
 

The Following User Says Thank You to qole For This Useful Post:
Stskeeps's Avatar
Posts: 1,671 | Thanked: 11,478 times | Joined on Jun 2008 @ Warsaw, Poland
#9
My hacking project for tonight, since Finland is on holiday tomorrow - seeing if I can build the driver for our 2.6.33 kernel. Worth knowing how screwed we are on that front.
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.
 

The Following 13 Users Say Thank You to Stskeeps For This Useful Post:
Stskeeps's Avatar
Posts: 1,671 | Thanked: 11,478 times | Joined on Jun 2008 @ Warsaw, Poland
#10
OK, I've set up a gitorious project at http://gitorious.org/mbx-n8x0/mbx-n8...s/trees/master and a team for it (poke me to get added)

I've cleaned up the build system and am now using normal Linux kernel build system.

That means:

make CROSS_COMPILE=/path/to/cross-compiler KERNELDIR=/where/my/kernel-sources/are ARCH=arm

to compile it. Not the insane TI build system.

Oh, and it dual builds on 2.6.33 and 2.6.21. Could someone replicate the steps please for 2.6.21 and try to use the .ko's resulting?
__________________
As you go on to other communities, remember to build them around politeness, respect, trust and humility. Be wary of poisonous people and deal with them before they end up killing your community.. Seen it happen to too many IRC channels, forums, open source projects.
 

The Following 14 Users Say Thank You to Stskeeps For This Useful Post:
Reply

Tags
accelerated, nokia n8x0

Thread Tools

 
Forum Jump


All times are GMT. The time now is 10:16.