Craig Matsuura wrote:
So you said MV claims there is a fix. Do you know what the fix is? If we
can run at 1280x720 with out the starvation we would be interested in
trying it. However we never had anything that complete rid us of the
problem.
Don't get me wrong. I certainly don't speak for (or against) MV.
I just think I first heard about the fix on the linux-davinci mailing list
in the context of someone using MontaVista.
We've been using the git kernel forever.
We're running 1280x800 with a full OSD layer (as 16-bit RGB565) without
the DMA under-run being a problem. That's not to say that we can't make
the problem happen if we try by stressing the USB, SD card and ethernet
channels concurrently, but it's not a problem because the combinations
don't happen in our customers' production apps.
Thanks,
Craig
On Thursday 28 May 2009 2:59:09 pm Eric Nelson wrote:
> 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
--
------------------------------------------------------------------------
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
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
_______________________________________________
directfb-users mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
