public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Marin Mitov <mitov@issp.bas.bg>
To: Greg KH <greg@kroah.com>
Cc: Scott Smedley <ss@aao.gov.au>, linux-kernel@vger.kernel.org
Subject: Re: [RFC] Yet another dt3155 driver for drivers/staging
Date: Wed, 13 Jan 2010 08:16:43 +0200	[thread overview]
Message-ID: <201001130816.43855.mitov@issp.bas.bg> (raw)
In-Reply-To: <20100113001724.GB29904@kroah.com>

On Wednesday 13 January 2010 02:17:24 am Greg KH wrote:
> On Wed, Jan 13, 2010 at 10:52:21AM +1100, Scott Smedley wrote:
> > Hi Marin,
> > 
> > > dt3155 frame grabber I am using in my experiments since 
> > > the time of 2.6.17 kernel.
> > 
> > Whoah!
> > 
> > > I will really appreciate your comments, suggestions, criticism.
> > 
> > I haven't tried your driver but the code looks much neater than
> > our driver. Still, I am wondering why you chose to implement a
> > device driver from scratch, rather than use an existing one?
> > 
> > http://sourceforge.net/projects/dt3155a/

In fact I used this one before switching to 2.6.17 kernel (see 

http://lfb.issp.bas.bg/~mitov/linux/dt3155pci/00README

for details) and it was working well for single image acquisition.
(except for the problems with having too much HIGHMEM).
For real time acquisition (25 frames per sec), display and write
on HDD I needed heavy buffering, otherwise frames are skipped.

Another minor reason was I had already written an OS2 driver 
for the same hardware and liked to try the same on linux :-).

Scott, 

if you have 2 or more boards, could you check if
my driver is working with more than one board? I have only one
and cannot do this check. I could send you a multi-threaded
program for the test if you need it.

Marin Mitov

> > 
> > I'll leave decisions about whether to merge or discard (either
> > driver) to Greg. My 2 cents is that there should only be 1 DT3155
> > driver for users to choose from.
> 
> I agree, we only need one of them.
> 
> Scott, any comparison between the two of them as to which one actually
> works better?
> 
> thanks,
> 
> greg k-h
> 

  reply	other threads:[~2010-01-13  6:17 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-12 20:42 [RFC] Yet another dt3155 driver for drivers/staging Marin Mitov
2010-01-12 23:52 ` Scott Smedley
2010-01-13  0:17   ` Greg KH
2010-01-13  6:16     ` Marin Mitov [this message]
2010-01-14  1:03       ` Scott Smedley
2010-01-14  2:36         ` Greg KH
2010-01-14  3:13           ` Scott Smedley
2010-01-14  3:40             ` Greg KH
2010-01-14 19:39               ` Marin Mitov
2010-01-15 17:33                 ` Greg KH
2010-01-14 19:23         ` Marin Mitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201001130816.43855.mitov@issp.bas.bg \
    --to=mitov@issp.bas.bg \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ss@aao.gov.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox