Re: v4l2 + kernel

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Gerd Knorr wrote:
> 
> On Tue, Apr 24, 2001 at 08:02:16PM -0700, Bill Dirks wrote:
> > Gerd Knorr wrote:
> > > Problems/Questions:
> > >
> > >  * virt_to_bus() is gone in 2.4.x.  It is not available any more for
> >
> > I still want to keep vmalloc_to_bus() for drivers that need to process
> > the data from the hardware. I will investigate how to reimplement it
> > without virt_to_bus().
> 
> You can't.  At least you can't build a plug-in replacement.  The pci_*
> functions have alloc and free calls, because they will programm a
> io memory management unit (for sparc, I think ia64 too).  Simply
> translating memory addresses to bus addresses doesn't work because
> there is no fixed mapping any more.

>From what I have seen, it would be possible, if we add v4l2_alloc and
v4l2_free type functions too - basically a complete set of memory
management helpers.

> > >  * What exactly was the reason to have one mmap() call for every
> > >    buffer instead of one big chunk like in v4l1?
> >
> > It just made sense to me that buffers are individually allocated and
> > freed. I never really wanted to to use mmap() for passing capture
> > buffers.
> 
> I'd love to drop mmap() altogether too, but I think we have problems
> to support devices with on-board memory and those which can't to
> scatter-gather then ...
> 
> > mmap() is for mapping file contents to virtual memory, not for
> > this.
> 
> Mapping device memory with mmap() is common operation on unix, see
> framebuffer devices for example.

For maximum flexibility, and minimum driver side effort, how about the
following scheme:

Allocate buffer memory for each capture buffer.  If this is inconvenient
for the driver, it can simply allocate one big chunk, and pass portions
to each buffer.

To maintain v4l1 compatibility, use the virtual mapping capabilities to
map multiple buffers back to a contiguous userspace buffer.  From what I
can see, this should be very easy, and require very little additional
code (much less than the current technique of maintaining two separate
buffer styles.

Because memory is now being handled on a per capture buffer basis,
userspace DMA is then simplified, as it can also be done per buffer,
without any extra logic.

-justin





[Index of Archives]     [Linux DVB]     [Video Disk Recorder]     [Asterisk]     [Photo]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Free Photo Albums]     [Fedora Users]     [Fedora Women]     [ALSA Users]     [ALSA Devel]     [Linux USB]

Powered by Linux