Thanks a Lot Vim
This solved my problem. I have now set the PBBPR value to 0x10. Thanks a lot to list for this prompt replies :) -----Original Message----- From: Vim Venture [mailto:[EMAIL PROTECTED] Sent: Thursday, October 16, 2008 4:57 AM To: [EMAIL PROTECTED] Cc: Brian Rhodes; [email protected] Subject: Re: DM6446 1024x768 graphics with video overlay suHas, Could what you are seeing be related to Advisory 2.1.2 in sprz241k, "Bus Priority Inversion Can Affect DDR2 Throughput"? I ran into this problem and saw OSD0 flickering occasionally. There was no noticeable effect to video playing on VID0 though. The flicker was fixed with a write of 0x10 to PBBPR as in the Advisory. Regards, -Vim On Oct 15, 2008, at 12:10 PM, [EMAIL PROTECTED] wrote: > Thanks Vtain, for your promt reply.. Please find my comments below > with > tag "suHas" >> >> >> suhas wrote: >>> >>> Hi Brain, >>> >>> It seems that, you are successful in using ODS0 in 1024x768x16bpp. >>> >>> I am working on DaVinci dm6446 EVM. I am posting this problem here >>> as >>> there was no reply to my post in other thread. It's a similar >>> problem, >>> so please help. >>> >>> I am facing a problem of display flickering when cpu gets busy with >>> some other processing (may be for Ethernet data transfer or while >>> displaying video). >>> >>> It seems that the problem is with CPU bandwidth. >>> >>> I am using OSDWIN0 in RGB565 mode. I have selected standard >>> resolution >>> of NTSC. I understand this means a 720p x 480p resolution. >>> >>> As per the bandwidth requirement formula, required bandwidth is: >>> >>> [(720 * 480) * 2 + 0 ] * 30 = ~20Mbps. Thus this satisfies the >>> condition for <25Mbps >>> >>> Still, display flickers whenever there is any heavy processing done >>> over CPU. Kindly help me out of this. >>> >>> >> I saw this problem when trying to use > 74.25Mhz external clock with >> dm6446. If you have the Video1 window enabled, try disabling that. It >> really depends what the 'flicker' is. Of the few effects I have run >> into, one was what appeared to be a few single lines which would >> wrap, >> and the other was large vertical portions of the picture which >> would get >> wrapped. The latter happening when we tested using a out-of-spec >> clock >> at a higher frequency. > > suHas: I have only OSDWIN0 enabled. All other windows are disabled. > With > flicker I do mean that, whenever there is some heavy processing over > ethernet the screen "shakes". Also if I try to view any video, it > seems > that few frames are dropeed and the entire screen flickers. Complete > picture becomes shaky. This effect exceeds when I view the video in > full > screen mode. > > I am using Analog display and am currently working on DaVinci > DM6446EVM. > >>> >>> I am using non-interlaced mode. Would this cause any problem? I >>> don't >>> think so, as I have also checked with interlaced mode. >>> >>> Results were the same. But using non-interlaced mode, made the >>> picture >>> more clear. >>> >>> Is there any other way by which I can implement this ping-pong logic >>> for OSDWIN0? >>> >>> >> I am not using any analog displays so I never became very familiar >> with >> what the ping-pong code actually did. I am fairly certain that it >> has no >> use for the OSD window. I believe it toggled the source of the video >> window between vid0_addr and the subpicture addr. I have no idea why >> that fixed anything, or whether it was simply to offset one of the >> 'fields' a line. >>> >>> Can you please help me out to get this issue resolved. >>> >>> BTW what is "panning in the framebuffer driver"? Could this be >>> used to >>> solve my issue? >>> >>> >> I believe panning was initially implemented solely for having a >> larger >> virtual resolution than your display. Lots of times, however, it >> seems >> to be used in framebuffer drivers for buffering. >>> >>> Awaiting your reply. >>> >>> Regards, >>> >>> Suhas Jain >>> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On >>> Behalf Of Carl Renaud >>> Sent: Wednesday, October 15, 2008 9:16 AM >>> To: Brian Rhodes >>> Cc: [email protected] >>> Subject: Re: DM6446 1024x768 graphics with video overlay >>> >>> Thanks for your response Brian! >>> >>> You say you are able to use OSD0 in 1024x768x16bpp. >>> >>> 1) Can you also use OSD1 at the same time as an attribute windows to >>> >>> let VID0 show through? E.g. have a D1 30fps video playing over a >>> >>> 1024x768 graphic background? >>> >>> 2) When you say "...If you need to do some form of animation on the >>> >>> OSD window, you'll have to do some work to understand the >>> limitations, >>> >>> especially if you are using OSD1 as an attribute window for per- >>> pixel >>> >>> alpha blending... ", what kind of limitation are we talking about? I >>> >>> know about the rendering speed limitation of the 297MHz ARM, but >>> other >>> >>> than that? >>> >>> 3) I guess I don't understand the equation in section 4.3.1 of >>> >>> sprue37c.pdf (Video Window Constraints). According to the equation, >>> >>> using OSD0 in 1024x768 at 30 fps seems to exceed the specified limit >>> >>> of 25 Mbytes/second. >>> >>> [(1024 * 768) * 2bpp + (720 * 480) * 0.5bpp] * 30 = [1572864 + >>> 172800] >>> >>> * 30 = ~52 Mbytes/sec >>> >>> What am I missing? >>> >>> Thanks again! >>> >>> On Tue, Oct 14, 2008 at 4:57 PM, Brian Rhodes <[EMAIL PROTECTED]> >>> wrote: >>> >>>> >>> >>>> >>> >>>> Carl Renaud wrote: >>> >>>>> >>> >>>>> Hi, >>> >>>>> I am seeking advice on the DM6446... >>> >>>>> Our product requirements >>> >>>>> ================== >>> >>>>> Display a 1024x768 graphic background with a video overlay. Using >>> the DM6446, there is no problem doing this is in D1 resolution, >>> using >>> VID0 for video, OSD0 for graphics and OSD1 for transparency. For >>> resolutions higher than D1, there seems to be a few limitations... >>> >>>>> Methods >>> >>>>> ====== >>> >>>>> 1) The first method would be to use VID0 for video, OSD0 for >>> graphics(RGB565) and OSD1 for transparency. >>> >>>>> I read in the VPBE document (section 4.3.1 of sprue37) that the >>> combined bandwith of the OSDs cannot be more than 25MB/sec. This is >>> exactly a D1 resolution OSD at 30 fps. So... this method would not >>> work... Correct? >>> >>>>> >>> >>>> >>> >>>> I am not having trouble drawing 1024x768x16bpp graphics to OSD0. To >>> prevent tearing, use the memory you would have for Video 1 window >>> and >>> implement panning in the framebuffer driver. Your 'product >>> requirement' has a full screen graphic background, and for that OSD0 >>> will suffice. If you need to do some form of animation on the OSD >>> window, you'll have to do some work to understand the limitations, >>> especially if you are using OSD1 as an attribute window for per- >>> pixel >>> alpha blending. >>> >>>>> >>> >>>>> 2) The second method would be to use VID0 for graphics(RGB888) and >>> VID1 for video (as a picture in picture). >>> >>>>> In the VPBE document (again section 4.3.1 of sprue37), it is >>>>> stated >>> that when doing HD, VID0 should be used and VID1 disabled. Also, >>> reading through the mailing list, it seems that there is a silicon >>> problem on the DM6446 that prevents using VID0 and VID1 at the same >>> time. So... this method would not work... Correct? >>> >>>> >>> >>>> You are correct. You cannot use Video 1 when the resolution of >>>> Video >>> 0 is > 720x576. The bug in the silicon causes a flicker when both >>> Video 1 and Video 0 are used at lower resolutions. >>> >>>> >>> >>>>> 3) The third method would be to use VID0 for graphics(RGB888), >>>>> OSD0 >>> for video(RGB565) and OSD1 for transparency. >>> >>>>> My understanding is that this should be possible if we limit the >>> video to be a D1 frame within the 1024x768 graphics of VID0. This >>> would respect the OSD bandwidth limitation. However, since OSD0 only >>> takes RGB565 (and bitmap), I would need to convert the YUV 4:2:2 >>> video >>> to RGB565 on the ARM(or DSP). Correct? >>> >>>>> >>> >>>> >>> >>>> This would not be possible. You would not be able to do this >>> colorspace conversion quick enough. Codec implementations which do >>> conversions between 4:2:2 and 4:2:0 are simply reassembling the >>> stream >>> of data, throwing some away in one direction, and duplicating some >>> in >>> the other. the conversion from yuv -> rgb is considerably more work. >>> >>>>> >>> >>>>> Is my understanding correct? Is there any other option on the >>> DM6446 to meet our requirements? >>> >>>>> Thank you! >>> >>>>> >>> ------------------------------------------------------------------------ >>> >>>>> >>> >>>>> _______________________________________________ >>> >>>>> Davinci-linux-open-source mailing list >>> >>>>> [email protected] >>> >>>>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >>> >>>>> >>> >>> _______________________________________________ >>> >>> Davinci-linux-open-source mailing list >>> >>> [email protected] >>> >>> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >>> >> > > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
_______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
