Active Topics
-
The N900 is now 15 years old! (7)
to Nokia N900 by Danct12 - 22 hrs, 36 mins ago -
Sailfish OS for the Motorola Moto G7 Power (XT1955-5) - (ocean) (4)
to SailfishOS by Maemish - 1 day, 18 hrs ago -
F(x)tec Pro1x (QWERTY) for sale (0)
to Buy & Sell by aln00000 - 4 days, 2 hrs ago - more...
| The Following 2 Users Say Thank You to Stskeeps For This Useful Post: | ||
 |
|
2010-05-17
, 21:13
|
|
Posts: 1,671 |
Thanked: 11,478 times |
Joined on Jun 2008
@ Warsaw, Poland
|
#12
|
So, Flip():
Together with this from the graphics subsystem manual mentioned above:
Base address of the graphics buffer in system memory (DSS.DISPC_GFX_BAi registers): The default
value of these two registers at reset time is 0x0. The horizontal resolution is one pixel because the
base address is aligned on a pixel size boundary. In case of 4 BPP, the resolution is two pixels; for 2
BPP, resolution is four pixels; for 1 BPP, resolution is eight pixels; and for RGB24 packed format, the
resolution is four pixels. The vertical resolution is one line. The register DSS.DISPC_GFX_BA0 defines
the base address of the even field; and DSS.DISPC_GFX_BA1 defines the base of the odd field in the
case of an external synchronization and based on the value of the input signal DISPC_FID and the
polarity. To improve system throughput, the base address should be aligned on the burst size
boundary.
Means Flip() is basically pointing that particular plane to the address and then noting the chip about it (GOLCD). Now, my thought is then to do along these lines, pseudocode galore:
When doing a flip (ie, point to a new framebuffer to be shown), - yes, this call is exported by blizzard.c.
int blizzard_update_window_async(struct fb_info *fbi,
struct omapfb_update_window *win,
void (*complete_callback)(void *arg),
void *complete_callback_data)
with a callback being the Vsync ISR, with the IRQ parts removed. That then checks if there's things to be flipped and runs complete() calls and all that stuff and calls a Flip() if need be, making it possible to get Vsync ISR called again.
If I'm right and omaplcd_ddc_process_vsyncflip is actually the entry point for the incoming frames, the first Flip() it does when there's no frames waiting in queue besides the incoming (read: no need to wait for vsync, just write to the buffer), will make sure the VsyncFlip() method gets called each time it's done transferring/flipping a frame.
Now, how difficult is it for us to add blizzard_update_window_async support in Flip() and strip out the IRQ stuff of the ISR, and provide a callback wrapper for VSyncFlip for blizzard_update_window_async?
Code:
IMG_VOID Flip (OMAPLCD_DEVINFO * psDevInfo, unsigned long ui32DevAddr)
{
IMG_UINT32 control;
WriteReg ((IMG_VOID *) ((IMG_UINT8 *) psDevInfo->sFBInfo.pvRegs +
OMAPLCD_GFX_BA0), ui32DevAddr);
WriteReg ((IMG_VOID *) ((IMG_UINT8 *) psDevInfo->sFBInfo.pvRegs +
OMAPLCD_GFX_BA1), ui32DevAddr);
control =
ReadReg ((IMG_VOID *) ((IMG_UINT8 *) psDevInfo->sFBInfo.pvRegs +
OMAPLCD_CONTROL));
control |= OMAP_CONTROL_GOLCD;
WriteReg ((IMG_VOID *) ((IMG_UINT8 *) psDevInfo->sFBInfo.pvRegs +
OMAPLCD_CONTROL), control);
} static IMG_BOOL
Base address of the graphics buffer in system memory (DSS.DISPC_GFX_BAi registers): The default
value of these two registers at reset time is 0x0. The horizontal resolution is one pixel because the
base address is aligned on a pixel size boundary. In case of 4 BPP, the resolution is two pixels; for 2
BPP, resolution is four pixels; for 1 BPP, resolution is eight pixels; and for RGB24 packed format, the
resolution is four pixels. The vertical resolution is one line. The register DSS.DISPC_GFX_BA0 defines
the base address of the even field; and DSS.DISPC_GFX_BA1 defines the base of the odd field in the
case of an external synchronization and based on the value of the input signal DISPC_FID and the
polarity. To improve system throughput, the base address should be aligned on the burst size
boundary.
Means Flip() is basically pointing that particular plane to the address and then noting the chip about it (GOLCD). Now, my thought is then to do along these lines, pseudocode galore:
When doing a flip (ie, point to a new framebuffer to be shown), - yes, this call is exported by blizzard.c.
int blizzard_update_window_async(struct fb_info *fbi,
struct omapfb_update_window *win,
void (*complete_callback)(void *arg),
void *complete_callback_data)
with a callback being the Vsync ISR, with the IRQ parts removed. That then checks if there's things to be flipped and runs complete() calls and all that stuff and calls a Flip() if need be, making it possible to get Vsync ISR called again.
If I'm right and omaplcd_ddc_process_vsyncflip is actually the entry point for the incoming frames, the first Flip() it does when there's no frames waiting in queue besides the incoming (read: no need to wait for vsync, just write to the buffer), will make sure the VsyncFlip() method gets called each time it's done transferring/flipping a frame.
Now, how difficult is it for us to add blizzard_update_window_async support in Flip() and strip out the IRQ stuff of the ISR, and provide a callback wrapper for VSyncFlip for blizzard_update_window_async?
__________________
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.
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.
 |
|
2010-05-17
, 23:02
|
|
Posts: 2,355 |
Thanked: 5,249 times |
Joined on Jan 2009
@ Barcelona
|
#13
|
So, my implementation of AllocContiguousMemory:
It will crash you say?
Madness! The damn driver works as usual. I even get the usual triangles on the screen (after a forced blizzard push). So what's happening here?
Initial reasoning: omaplcd IS NOT allocating the real framebuffer, but just wasting some memory. And quite a bit of precious dma memory, for a start.
For skeptics, the kernel BUGS when trying to kill mbxdaemon because it then tries to free 0x01...
Code:
PVRSRV_ERROR AllocContiguousMemory(IMG_UINT32 ui32Size, IMG_HANDLE unref__ * hMem, IMG_SYS_PHYADDR *pPhysAddr, IMG_CPU_VIRTADDR *pLinAddr)
{printk("%s(size=%lu)\n", __func__, ui32Size);
dma_addr_t dma;
#if (LINUX_VERSION_CODE >= KERNEL_VERSION(2,6,0))
*pLinAddr = dma_alloc_coherent(NULL, ui32Size, &dma, GFP_KERNEL);
#else
*pLinAddr = consistent_alloc(GFP_KERNEL | GFP_DMA, ui32Size, &dma);
#endif
if(*pLinAddr == IMG_NULL)
{
printk ("AllocContiguousMemory: unable to allocate contiguous memory of %lu\n", ui32Size);
}
else
{printk("%s BEING EVIL HERE!\n", __func__);
//pPhysAddr->uiAddr = dma;
*pLinAddr = 0x01; pPhysAddr->uiAddr = 0x01;
return PVRSRV_OK;
}
return PVRSRV_ERROR_OUT_OF_MEMORY;
}
Code:
[ 83.820312] GetSystemSurfaceInfo(c88fd000) [ 83.820312] No flipbuffers [ 83.820312] GetBackBuffer(c88fd000, num=0) [ 83.820312] AllocContiguousMemory(size=768000) [ 83.828125] AllocContiguousMemory BEING EVIL HERE! [ 83.828125] GetBackBuffer(c88fd000, num=1) [ 83.828125] AllocContiguousMemory(size=768000) [ 83.828125] AllocContiguousMemory BEING EVIL HERE! [ 83.828125] InitMain() going to call installvsync [ 83.828125] InitMain() installvsync ok [ 83.828125] InitMain() going to return [ 83.828125] OMAPLCDBridgeDispatch called, see next line [ 83.828125] OMAPLCDBridgeDispatch(cmd=OMAPLCDIO_INSTALL_VSYNC_ISR)
Initial reasoning: omaplcd IS NOT allocating the real framebuffer, but just wasting some memory. And quite a bit of precious dma memory, for a start.
For skeptics, the kernel BUGS when trying to kill mbxdaemon because it then tries to free 0x01...
Code:
[ 639.859375] OMAPLCDBridgeDispatch called, see next line [ 639.859375] OMAPLCDBridgeDispatch(cmd=OMAPLCDIO_DEINIT_MAIN) [ 639.859375] DeinitMain() [ 639.859375] ReleaseBackBuffer(c88fd000, num=0) [ 639.867187] dma_free_coherent: trying to free invalid coherent area: 00000001 [ 639.867187] [<c002c178>] (dump_stack+0x0/0x14) from [<c002e2f8>] (dma_free_coherent+0x1d0/0x204) ....
|
|
2010-05-18
, 06:56
|
|
Posts: 1,671 |
Thanked: 11,478 times |
Joined on Jun 2008
@ Warsaw, Poland
|
#14
|
Originally Posted by javispedro
Madness! The damn driver works as usual. I even get the usual triangles on the screen (after a forced blizzard push). So what's happening here?
Initial reasoning: omaplcd IS NOT allocating the real framebuffer, but just wasting some memory. And quite a bit of precious dma memory, for a start.
__________________
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.
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.
 |
|
2010-05-18
, 12:35
|
|
Posts: 13 |
Thanked: 8 times |
Joined on Aug 2009
@ Brazil - Piracicaba/SP
|
#15
|
hello hardware folks,
i can really be saying something stupied,
- but canīt the MBX stream/flush the data without reserving a DMA buffer?
- are the memmory values " [ 83.820312] AllocContiguousMemory(size=768000)" enough or excceds the actual free memmory?
- could someone write an e-mail to the lcd manufactor for help, just "asking" how is the I/O of the lcd?
Anyway, if i say ******** plaese follow up,
thank you for all efforts you are doing and go ahead! you can make it!
Last edited by marshel; 2010-05-18 at 12:38.
i can really be saying something stupied,
- but canīt the MBX stream/flush the data without reserving a DMA buffer?
- are the memmory values " [ 83.820312] AllocContiguousMemory(size=768000)" enough or excceds the actual free memmory?
- could someone write an e-mail to the lcd manufactor for help, just "asking" how is the I/O of the lcd?
Anyway, if i say ******** plaese follow up,
thank you for all efforts you are doing and go ahead! you can make it!
__________________
--marshel--
brazilian n800 owner
curious by nature
--marshel--
brazilian n800 owner
curious by nature
Last edited by marshel; 2010-05-18 at 12:38.
|
|
2010-05-18
, 13:11
|
|
Posts: 1,671 |
Thanked: 11,478 times |
Joined on Jun 2008
@ Warsaw, Poland
|
#16
|
:takes a deep breath:
Okay, so, libomaplcd.ko is actually what we see in the kernel driver. With Flip() and so on, down to actually writing into BA0.
A simple look into the debug symbols confirms this suspicion:
static void Flip(OMAPLCD_DEVINFO *, long unsigned int);
static void FlushQueue(OMAPLCD_DEVINFO *, void (*)(IMG_VOID *, long unsigned int), IMG_VOID *);
PVRSRV_ERROR MapFBRegRange(OMAPLCD_CLIENT_DEVINFO *, OMAPLCD_DEVINFO *);
PVRSRV_ERROR MapSwapChain(OMAPLCD_CLIENT_DEVINFO *, OMAPLCD_CLIENT_SWAP_CHAIN *);
IMG_BOOL OMAPLCDBridge(IMG_HANDLE, IMG_UINT32, IMG_VOID *, IMG_UINT32, IMG_VOID *, IMG_UINT32);
IMG_UINT32 ReadReg(IMG_VOID *);
Okay, so, libomaplcd.ko is actually what we see in the kernel driver. With Flip() and so on, down to actually writing into BA0.
A simple look into the debug symbols confirms this suspicion:
static void Flip(OMAPLCD_DEVINFO *, long unsigned int);
static void FlushQueue(OMAPLCD_DEVINFO *, void (*)(IMG_VOID *, long unsigned int), IMG_VOID *);
PVRSRV_ERROR MapFBRegRange(OMAPLCD_CLIENT_DEVINFO *, OMAPLCD_DEVINFO *);
PVRSRV_ERROR MapSwapChain(OMAPLCD_CLIENT_DEVINFO *, OMAPLCD_CLIENT_SWAP_CHAIN *);
IMG_BOOL OMAPLCDBridge(IMG_HANDLE, IMG_UINT32, IMG_VOID *, IMG_UINT32, IMG_VOID *, IMG_UINT32);
IMG_UINT32 ReadReg(IMG_VOID *);
__________________
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.
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.
|
|
2010-05-18
, 15:26
|
|
Posts: 1,671 |
Thanked: 11,478 times |
Joined on Jun 2008
@ Warsaw, Poland
|
#17
|
I've contacted my TI contact to see if he can add a hook to the libomaplcd.so file. Let's see if they still react..
__________________
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.
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.
|
|
2010-05-19
, 18:18
|
|
Posts: 1,671 |
Thanked: 11,478 times |
Joined on Jun 2008
@ Warsaw, Poland
|
#18
|
I have heard from my TI contact and he said 'I will look in to it and will do want I can.' (assuming he means 'what' and not 'want'). That looks good 
__________________
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.
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.
|
|
2010-05-24
, 19:55
|
|
Posts: 1,671 |
Thanked: 11,478 times |
Joined on Jun 2008
@ Warsaw, Poland
|
#19
|
I've sent the following to my TI contact:
Thanks for offering this.
What we need is:
After every call to the function static void Flip(OMAPLCD_DEVINFO *,
long unsigned int), there should be a ioctl made into kernel, using
OMAPLCDBridge, to the following ioctl:
#define OMAPLCDIO_PERFORMED_FLIP _IOWR('F', 0x41, struct
OMAPLCD_INIT_MAIN_IN_DATA_TAG)
A similar call can probably be seen if you look for
OMAPLCDIO_DEINIT_MAIN in your current code.
We can implement the kernel side ourselves, we just need the user code
to call this each time it has run Flip()
The reason for this to be done after each Flip() call, is so we can
start a data transfer of the framebuffer to the external LCD
controller in kernel, of the framebuffer it just flipped to.
Thank you!
Thanks for offering this.
What we need is:
After every call to the function static void Flip(OMAPLCD_DEVINFO *,
long unsigned int), there should be a ioctl made into kernel, using
OMAPLCDBridge, to the following ioctl:
#define OMAPLCDIO_PERFORMED_FLIP _IOWR('F', 0x41, struct
OMAPLCD_INIT_MAIN_IN_DATA_TAG)
A similar call can probably be seen if you look for
OMAPLCDIO_DEINIT_MAIN in your current code.
We can implement the kernel side ourselves, we just need the user code
to call this each time it has run Flip()
The reason for this to be done after each Flip() call, is so we can
start a data transfer of the framebuffer to the external LCD
controller in kernel, of the framebuffer it just flipped to.
Thank you!
__________________
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.
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.
|
|
2010-06-02
, 23:25
|
|
Posts: 13 |
Thanked: 8 times |
Joined on Aug 2009
@ Brazil - Piracicaba/SP
|
#20
|
any news if it worked? hmmm i'm not the kernel geek type of guy....
__________________
--marshel--
brazilian n800 owner
curious by nature
--marshel--
brazilian n800 owner
curious by nature
 |
| Tags |
| accelerated, nokia n8x0 |
«
Previous Thread
|
Next Thread
»
|
All times are GMT. The time now is 23:15.
http://bunnitude.com/misc/files/omap/pdf/sprufa4.pdf
We use RFBI to send to the LCD controller, I believe.
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.