I'm trying to play around with copying memory into a framebuffer, and I'd like to be able to do it during the vblank. I poked around in the source for a while, but haven't found anything that seems to be a vblank interrupt (although there seems to be an option for a "fake" interrupt). Can anyone point me in the direction of code that is called once per screen refrehs, preferably during the blanking interval?
Thanks,
Brett
I'm trying to play around with copying memory into a framebuffer, and
I'd like to be able to do it during the vblank. I poked around in the
source for a while, but haven't found anything that seems to be a
vblank interrupt (although there seems to be an option for a "fake"
interrupt). Can anyone point me in the direction of code that is
called once per screen refrehs, preferably during the blanking interval?
Use FBIOPAN_DISPLAY. This ioctl already take place when vsync happens.
This is from a mail from Tomi:
Here are some snippets from private email:
Thanks for the response. FBIOPAN_DISPLAY seems to only be referenced in drivers/video/fbmem.c, and the main thing it seems to do is call fb_pan_display.
Are you saying that if I drop my copy code into fb_pan_display, it will end up getting called every vertical blank period (so 60 times per second if I'm set at 60Hz refresh)?
Brett
Use FBIOPAN_DISPLAY. This ioctl already take place when vsync happens.
Thanks for the response. FBIOPAN_DISPLAY seems to only be referenced
in drivers/video/fbmem.c, and the main thing it seems to do is call
fb_pan_display.
Are you saying that if I drop my copy code into fb_pan_display, it
will end up getting called every vertical blank period (so 60 times
per second if I'm set at 60Hz refresh)?
AFAIR: yes 
But you have to call this ioctl EVERY vsync! See the mail from Tomi.
Robert
I just realize that perhaps I do not understand you.
You have to use double buffering using FBIOPAN_DISPLAY: The switch
between front- and backbuffer happens automatically in the vertical
blank. So
Setup_frambuffer();
while(1)
{
fill_backbuffer();
ioctl(.., FBIOPAN_DISPLAY); // blocks until vsync
}
Just out of my mind. I did that a month ago so I forgot already almost 90% 
Robert
Yeah, this isn't quite what I want. I want to know in the kernel code itself what routines get called on vsync. I'm modifying the display driver to pull data from somewhere (that the OMAP display controller can't get to) and copy it into SDRAM (where the OMAP display controller can read it). There must be some kernel routine that occurs on vsync, but I haven't found it yet.
Brett
Yeah, this isn't quite what I want. I want to know in the kernel code
itself what routines get called on vsync. I'm modifying the display
omap_dispc_register_isr(vsync_handler, 0, DISPC_IRQ_VSYNC);
I think the parameter has changed during DSS development.
R.
Yeah, this isn't quite what I want. I want to know in the kernel code
itself what routines get called on vsync. I'm modifying the display
driver to pull data from somewhere (that the OMAP display controller
can't get to) and copy it into SDRAM (where the OMAP display
controller can read it). There must be some kernel routine that
occurs on vsync, but I haven't found it yet.
Hi Brett,
Is this still related to the problem of the DISP_C not being able to access
memory from other places than DDR memory?
I can't remember to have ever heard about this limitation. On the other hand
I have never tried anything else but I find it a bit strange...
Did you get the problem confirmed from anybody at TI?
I would assume it can run out of GPMC connected memory as well. One problem
with this approach might though be the memory bandwidth, which very will
quickly "kill" you at a high resolutions display.
As I posted earlier today a 1280x720p display will require a 111MB/s
continuous transfer and in this case it won't help you copying the image
from GPMC to DDR in an ISR either...
On GPMC max frequency is 100MHz which in synch burst mode leaves you with a
maximum theoretical memory bandwidth around just below 180MB/s, which might
make it impossible to achieve 111MB effectively.
In case you run async mode you will definitely not be able to achieve
111MB/s 
Have you tried to do the test with a lower resolution?
Best regards
Søren
Yes, it is related (it is my fallback plan if GPMC doesn't feed DSS).
I have some emails in to TI and I hope to get some answers from them soon. I have tried various resolutions without success. Right now I have it 1024x768@30Hz, 16 color, and I get the same error. At that resolution, I think I need about 48MB/s to get full-speed updates. I could probably live with less than that if I had to.
I'm having trouble sorting through the kernel code to find out where to register the ISR. I'm using the panel-generic driver and dvi out, and I have VENC support enabled in kernel options, but I don't have DSI or SDI or RFBI support. I'm not exactly sure what DSI and SDI are, although DSI seems to have a handler that looks like it gets called on frame draw end. Any further tips appreciated.
Brett
I have some emails in to TI and I hope to get
some answers from them soon. I have tried various
resolutions without success. Right now I have it
1024x768@30Hz, 16 color, and I get the same
error. At that resolution, I think I need about
48MB/s to get full-speed updates. I could
probably live with less than that if I had to.
Hi Brett,
Is you GPMC configured in SYNC burst mode at highest possible clock rate
(100MHz AFAIR)?
I really don't think you can achieve 48MB/s = 24MWords/s in ASYNC mode.
That would only leave ~4 clock cycles for each data transfer, which is below
the edge for:
Reserving bus - Setting address - Bus turnaround - Latching data - Releasing
bus
Already here we have 5 bus-states and no wait-states inserted, which would
just make thing even worse...
Have you tried to lower the resolution to 640x480@30fps or even lower
(320x240@20fps) just to make sure that the error goes away? Most probably
your monitor won't show anything, but hopefully the error disappear proving
no problem with DISP_C accessing data from GPMC
DSI is Display Serial Interface, which is standardized by MIPI (The Mobile
Industry Processor Interface Alliance). It's a high speed differential
serial interface in order to avoid parallel data busses in newer cell
phones...
SDI is as far as I know a TI propriety differential serial interface as
well, although I have never used it...
Best regards - Good luck
Søren
Hi Brett,
Is you GPMC configured in SYNC burst mode at highest possible clock rate
(100MHz AFAIR)?I really don't think you can achieve 48MB/s = 24MWords/s in ASYNC mode.
That would only leave ~4 clock cycles for each data transfer, which is below
the edge for:Reserving bus - Setting address - Bus turnaround - Latching data - Releasing
busAlready here we have 5 bus-states and no wait-states inserted, which would
just make thing even worse...Have you tried to lower the resolution to 640x480@30fps or even lower
(320x240@20fps) just to make sure that the error goes away? Most probably
your monitor won't show anything, but hopefully the error disappear proving
no problem with DISP_C accessing data from GPMC
I will check the mode and try very low-res/low-refresh settings and see what happens. Thank you for all the ideas.
DSI is Display Serial Interface, which is standardized by MIPI (The Mobile
Industry Processor Interface Alliance). It's a high speed differential
serial interface in order to avoid parallel data busses in newer cell
phones...SDI is as far as I know a TI propriety differential serial interface as
well, although I have never used it...
Very helpful to know, thank you. Google searches on "SDI" and "DSI" aren't terribly useful due to the large number of different things they can stand for.
Brett
You can find information on SDI and DSI in the OMAP3530 Technical Reference Manuals. These are low resoulution serial interfaces for LCD displays in Cellphones.
Gerald
Oh well, 320x240@15Hz, 16-bit color, pulling from GPMC space, does not seem to work any better. I get the same "DISPC IRQ: 0x200: OCP_ERR" that I was getting before with the higher res. I'm going to go back to the copy code for now.
Brett
Oh well, 320x240@15Hz, 16-bit color, pulling from GPMC space, does
not seem to work any better. I get the same "DISPC IRQ: 0x200:
OCP_ERR" that I was getting before with the higher res. I'm going to
go back to the copy code for now.
Again, how is your GPMC configured? - This is really a key point.
It might be that the OCP transaction times out before finishing in case the
GPMC is too slow. When an OCP initiator (DISP_C in this case) issues an OCP
transaction it might set a timeout as well. I don't think you can configure
this for the DISP_C module, but I'm not complete sure. This might be what is
causing you problems in case the transaction to GPMC takes too long even
though you as such have enough bandwidth for the updates...
For the Cortex and DSP cores you can set the maximum OCP transaction times,
but I'm not sure about the DMA channels - Especially not the LCD DMA, which
is a bit special...
Was the above clear or just a random set of words
Søren
That was pretty clear, thanks. I'm not sure how the GPMC is configured, I need to get an answer back from the hardware guy on that (unless the config is pure software). My last big exposure to CPU buses was back when everything was still parallel, non-multiplexed data and address lines, so I'm still catching up on modern hardware.
Brett
Apparently configured in SYNC mode, so I guess I'll wait to hear from TI if GPMC -> DSS should be possible at all or not.
My kernel-based memory copy is getting a couple of frames per second when I call it manually through a usermode hack, so I'm hopeful of doing better when I figure out how to call it directly in the kernel. I set up the interrupt but it crashed on memory access, so apparently the ISR doesn't like the ioremaps or something. Or else it was too slow, or who knows, I've never done kernel coding in Linux before, just SunOS 20 years ago, but it is fun to learn new stuff, just slow.
Brett
Apparently configured in SYNC mode, so I guess
I'll wait to hear from TI if GPMC -> DSS should be possible at all or
not.
Hi Brett,
I will give the DISP_C GPMC approach a try tomorrow and let you know about
my results... I won't believe it's not possible - DISP_C has AFAIK no way of
knowing if it's reading from GPMC or DDR...
GPMC configuration is pure SW - You basically just need to check the
registers GPMC_CONFIG1_i - GPMC_CONFIG7_i where i is selecting the Chip
Select in Action... More info can be found at page 1263 in the TRM...
Enjoy your weekend
Søren
Hi,
Thanks. My guess was that the fake interrupt was for things like RFBI which don't really have a vertical blank.
Anyway, I installed the ISR as you suggested, and I see it getting called, which is good. Unfortunately my ioremap call inside the ISR causes a kernel BUG call, even though the same ioremap works fine when called and I'm not in an ISR. I guess I better go learn about memory access and ISRs.
Brett