lkml.org 
[lkml]   [2010]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC] Yet another (third) dt3155 driver PCI/video4linux compliant
    On Sat, Mar 20, 2010 at 09:40:16PM +0200, Marin Mitov wrote:
    > On 20.3.2010, Greg KH wrote:
    > > On Sat, Mar 20, 2010 at 11:18:36AM +0200, Marin Mitov wrote:
    > > > Hi Scott, Greg, all,
    > > >
    > > > Here you will find a link to the source code for a dt3155 driver
    > > > rewritten to be PCI/video4linux compliant.
    > > >
    > > > http://lfb.issp.bas.bg/~mitov/linux/dt3155v4l/
    > > >
    > > > It works with xawtv (if the window is bigger than the acquired image).
    > > > See
    > > >
    > > > http://lfb.issp.bas.bg/~mitov/linux/dt3155v4l/00README
    > > >
    > > > for more details.
    > > >
    > > > Any critics/comments will be appreciated.
    > >
    > > Can you send it in patch form? I can't really do anything with it like
    > > this, sorry.
    > >
    > > greg k-h
    >
    > OK, here it is:
    >
    > ======================================================
    >
    > Kernel module (device driver) for dt3155 frame grabber
    > video4linux2 compliant (finaly). Works with xawtv.
    >
    > ======================================================
    >
    > This driver is written (almost) from scratch, usung the
    > allocator developed for dt3155pci see bellow). The driver
    > uses videobuf-dma-contig interface modified to use the above
    > mentioned allocator instead of dma_alloc_coheren().
    >
    > The first thing to do was to design a new allocator based
    > on allocating a configurable number of 4MB chunks of memory,
    > that latter are broken into frame buffers of 768x576 bytes
    > kept in different FIFOs (queues). As far as the driver autoloads
    > as a kernel module during kernel boot, the allocation of 4MB
    > chunks succeeds.
    >
    > The driver keeps three FIFOs: one for 4MB chunks, one for free
    > buffers (available for allocations) and one for buffers already
    > allocated. Allocation/deallocation is done automatically though
    > the video4linux videobuf subsystem (some pointers to functions
    > are replaced by driver supplied functions).
    >
    > Sure, there are problems:
    >
    > 1. The device works by read() method only (for now).
    >
    > 2. Works for CCIR, but should work for RS-170 (not tested)
    > This is made during kernel configuration.
    >
    > 3. Could work for multiple dt3155 frame grabbers in a PC,
    > (private data is allocated during PCI probe() method), but
    > is not tested due to lack of a second board.
    >
    > 4. Not tested on a BIG ENDIAN architecture.
    >
    > 5. Many others you could find .... :-)
    >
    > All critics, comments, suggestions are wellcome.

    I like it, want me to apply it? Right now it fails to build, but that
    should be simple to fix up, I'll be glad to do that.

    thanks,

    greg k-h


    \
     
     \ /
      Last update: 2010-04-28 01:21    [W:0.038 / U:0.348 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site