Craig Matsuura wrote:
We actually referred to it a tear. It is a starvation of the FIFO's on
the OSD0, the VID0 does not have this problem as they have larger FIFO's
(This is straight from the silicon engineers at TI).
We provided a partial solution to TI and unfortunately MV was of no help
when we addressed it with them. I don't recall the exact fix, but it had
something to do with a PBBBR register and provided this to TI. No matter
who or how it was fixed if you put a heavy load on the kernel the video
on the OSD will start giving you a tearing like effect (or shift). I
think we did a dd if=/dev/zero of=/dev/null and it was really bad.
Yep. That's the one I was referring to.
We saw it when doing heavy ethernet and/or SD-card traffic.
Even if we had other layers off if had the problem at 1280x720. So we
ended up on the vid0 layer.
Thanks,
Craig
On Thursday 28 May 2009 2:34:38 pm Eric Nelson wrote:
> Craig Matsuura wrote:
> > Thanks for the quick response. Actually from my understanding on the
> > tearing issues (this is direct from TI Engineers), the FIFO on the OSD0
> > are too small when displaying at 1280x720 so there is no way to use the
> > OSD at 1280x720.
>
> I think you're referring to something other than tearing. At resolutions
> over around 1024x768, you'll get DMA starvation in the video output on
> the OSD. This produces a really weird behavior where the OSD layer shifts
> left for the rest of the frame.
>
> We've only seen it when enabling VID0 with OSD0 and OSD1 set up as an
> overlay with transparency (I forget what TI calls this mode).
>
> There's a partial fix for both the MV and git kernels that involves
> changing around the DMA priority for the video output. There's also
> a 'spraa' or 'sprue' doc that discusses things on the TI web-site.
>
> > How does directfb access the dma blitting?
>
> If memory serves, the DFB patches use /dev/mem to allocate the memory
> directly by the app (instead of using cmem or the dav-dma allocation
> routines), then hands the physical memory addresses to the dav-dma
driver.
>
> You'll need to configure DFB to steer clear of the RAM used by the codec
> engine and DSP.
>
> > Craig
> >
> > On Thursday 28 May 2009 1:48:18 pm Eric Nelson wrote:
> > > Hello Craig,
> > >
> > > Craig Matsuura wrote:
> > > > I am also curious about the progress. I am also interested in
> > > > speeding up blitting in directfb. I am currently on directfb 1.2, I
> > > > am using the fbdev not the mem mapping as I need it for an app that
> > > > runs on the vid0 in rgb24 bit mode.
> > >
> > > The latest driver can be found in our Git repository
> > > (file drivers/misc/dav-dma.c)
> > > http://git.boundarydevices.com/git-repos?p=linux-bd
> > >
> > > > I can not run on the osd0 as resolutions higher than 640x480 on the
> > > > OSD will cause video tearing. I run the vid0 at 1280x720 (720p).
> > >
> > > Using DMA for blts will help with tearing, but you'll likely also
need
> > > to sync with the vertical refresh interrupt.
> > >
> > > > I have contemplated using the /dev/mem but was unsure if it was
> > > > really worth the effort. I am also using the DSP with Codec
Engine 2
> > > > from
> >
> > TI so
> >
> > > > I can not use the c64 acceleration.
> > >
> > > The "blt" operations in dav-dma should inter-operate with CE2 just
> > > fine without the acceleration code in DFB.
> > >
> > > > On Wednesday 02 January 2008 8:36:20 pm Sriram Neelakandan wrote:
> > > > > Hi Eric,
> > > > >
> > > > > I stumbled on this posting recently..
> >
> >
http://mail.directfb.org/pipermail/directfb-users/2007-November/000123.ht
> >
> > > >ml
> > > >
> > > > > I am looking to use the driver ..
> > > > > Do u have any latest updates ?
> > > > > Also it will be of great help, if you could post a sample user
> > > > > space program, that demos the usage of your driver.
> > >
> > > Sorry for that, Sriram. I haven't had time to keep up with the
> > > Direct-FB mailing list and didn't notice your post.
> > >
> > > I also haven't touched base with the DFB team to know whether they've
> > > been keeping the DMA blt support up-to-date.
> > >
> > > When integrated with Direct-FB, the standard DFB demos will work
(only
> > > faster).
> > >
> > > Eric
> >
> > --
> >
> >
> >
------------------------------------------------------------------------
> > Craig Matsuura - Principal Engineer
> > Control4
> > 11734 South Election Road - Suite 200
> > Salt Lake City, UT 84020-6432
> > PH: 801-523-3161
> > FX: 801-523-3199
_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
