Updated requested feedback on video driver design

[Maupin, Chase]

Daniel,

Thanks for the feedback.  Our driver team is looking into the drm KMS interface based on your feedback.  I have some additional notes added below.

Sincerely,
Chase Maupin
Software Applications
Catalog DSP Products
e-mail: chase.maupin at ti.com
phone: (281) 274-3285

For support:
Forums - http://community.ti.com/forums/
Wiki - http://wiki.davincidsp.com/

> -----Original Message-----
> From: Daniel Stone [mailto:daniel at fooishbar.org]
> Sent: Friday, February 26, 2010 8:39 AM
> To: Alex Deucher
> Cc: Maupin, Chase; xorg-devel at lists.x.org
> Subject: Re: Updated requested feedback on video driver design
> 
> Hi Chase,
> 
> On Wed, Feb 24, 2010 at 12:19:57PM -0500, Alex Deucher wrote:
> > On Wed, Feb 24, 2010 at 9:21 AM, Maupin, Chase <chase.maupin at ti.com>
> wrote:
> > > In my last mail the link to the wiki page accidentally contained a
> period at the end which caused the link to fail.  Please see the updated
> link here
> > >
> > >
> http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Des
> ign
> > >
> > > Again, any feedback you have would be greatly appreciated.
> >
> > I would suggest using the drm KMS interface rather than fbdev for the
> > display controllers.  It's much more flexible, especially if the hw
> > supports multiple heads.
> 
> As Alex said, the fbdev API is incredibly deficient (even for cases less
> complex than VPSS), and DRM/KMS is definitely the way to go.  Extending
> the KMS API will allow you to do stuff like activate the HW composition
> functionality much more sensibly than either hacking it through fbdev,
> or mangling VPSS from userspace (!) leaving the kernel driver entirely
> unaware of what just happened.
> 
> As concerns the document, most of it (regarding how to communicate with
> the VPSS, etc) is low-level enough to only really concern the actual
> driver author.  Since most of the document is skeletal though (there's a
> lot of detail on how to use the syslink API, but then the entire
> documentation for control is 'send commands to the video driver'?), it's
> hard to say whether it's really useful or not.
> 
> One thing that strikes me is the 'frame' structure: to me, it looks like
> this refers to a framebuffer/CRTC/etc (i.e. a particular configuration
> of a section of a video device), whereas we tend to use it to refer to
> one coherent image (and only the image itself, i.e. pixels only) either
> from a capture device, or to be sent to the video device.  So if you're
> using 'frame' in the former usage, you probably want to rename it to
> avoid confusion; if you're using it to refer to pixels, most of the
> information you've listed other than timestamp/field ID/etc seems
> entirely superfluous.

We'll look into changing the name for clarity.

> 
> Lastly, is there any way to map the current storage, analogous to
> mmap()ing /dev/fbX on OMAP3 and below today, or is usage restricted to
> queue()? If so, how are buffers created for submission to queue()?

If the driver allocates the buffer then you should be able to mmap it as you would normally do with FBDev.  However, it is possible for the application to create and submit the buffers for use, as long as they are physically contiguous.  On TI systems this is normally done with the cmem module which handles shared physically contiguous buffers.

> 
> Most of this isn't particularly X-specific though, so it would be nice
> if there was a better discussion we could use -- perhaps linux-omap?
> 
> Cheers,
> Daniel