headers
Markus Rechberger | 1 Jun 2007 21:28
Picon

Fwd: tuner-core t->i2c.dev.driver question

Thierry did some research on that flawed i2c detection in tuner-core a
longer time ago.
That issue should be fixed in my experimental repository on
mcentral.de (it hasn't been tested with all devices yet)

following list shows up current problems with the v4l and dvb project
which are still is also flawed in the mainline kernel.

http://mcentral.de/wiki/index.php/Bugtracker

Markus

---------- Forwarded message ----------
From: Thierry Merle <thierry.merle <at> free.fr>
Date: Sat, 12 May 2007 15:21:54 +0200
Subject: Re: tuner-core t->i2c.dev.driver question
To: Markus Rechberger <mrechberger <at> gmail.com>

Hello Markus,
I saw this response in my draft directory of my e-mail client.
I send it to you if you did not received it yet.

Thierry

Markus Rechberger a écrit :
> Hi,
>
> can someone verify that
>
> #if LINUX_VERSION_CODE > KERNEL_VERSION(2,6,0)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Mauro Carvalho Chehab | 1 Jun 2007 22:42
Favicon

Re: Fwd: tuner-core t->i2c.dev.driver question

Markus,

> Thierry did some research on that flawed i2c detection in tuner-core a
> longer time ago.

I did some analysis on this issue.

What happens is that set_type is called twice during the i2c probe
phase, in the following order:

1) by attach_inform callback;
2) by tuner probe routine, under tuner-core.

The first one is required to allow setting tuner type and addresses. The
last one will properly fill tuner mask, identifying the tuner function,
as required for the boards with separate tuners for radio (like those
with tea5767).

It should also be noticed that SET_TYPE_ADDR were designed in a way that
you could later change the tuner type or address[1].

So, on a tuner driver design as currently implemented on mainstream
drivers, calling set_type() more than one time won't have any
troubles[2], although it would be better if it will run just once. I'm
not aware of any bugs caused by calling this twice with the currently
supported tuners.

On your tree, however, the registration function will not only
probe/fill the tuner structs, but will also register a newer module into
tuner. So, a new lock model will be needed, to avoid calling the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Markus Rechberger | 1 Jun 2007 23:03
Picon

Re: Fwd: tuner-core t->i2c.dev.driver question

On 6/1/07, Mauro Carvalho Chehab <mchehab <at> infradead.org> wrote:
> Markus,
>
> > Thierry did some research on that flawed i2c detection in tuner-core a
> > longer time ago.
>
> I did some analysis on this issue.
>
> What happens is that set_type is called twice during the i2c probe
> phase, in the following order:
>
> 1) by attach_inform callback;
> 2) by tuner probe routine, under tuner-core.
>
> The first one is required to allow setting tuner type and addresses. The
> last one will properly fill tuner mask, identifying the tuner function,
> as required for the boards with separate tuners for radio (like those
> with tea5767).
>
> It should also be noticed that SET_TYPE_ADDR were designed in a way that
> you could later change the tuner type or address[1].
>
> So, on a tuner driver design as currently implemented on mainstream
> drivers, calling set_type() more than one time won't have any
> troubles[2], although it would be better if it will run just once. I'm
> not aware of any bugs caused by calling this twice with the currently
> supported tuners.
>
> On your tree, however, the registration function will not only
> probe/fill the tuner structs, but will also register a newer module into
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Carvalho Chehab | 2 Jun 2007 01:00
Favicon

Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver


> >> + * Copyright (C) Nicolas VIVIEN
> > 
> > It would be interesting to have Nicolas SOB as well, if possible.
> 
> I don't think he ever knows about this version of the driver. I got his GPL
> driver, cleaned up -- coding style, v4l1 and v4l2 ioctl conversion to v4l2
> functions, some bug fixes and so on... If you still want him to sign this
> of, I'll try my best to catch him but can't guarantee any results.

It would be nice. I can accept it without his ack, but it would be
better to have it, if possible.
> 
> >> +
> >> +#ifndef CONFIG_STK11XX_DEBUG_STREAM
> >> +#define CONFIG_STK11XX_DEBUG_STREAM	0
> >> +#endif
> >> +
> >> +#if CONFIG_STK11XX_DEBUG_STREAM
> > 
> > I would instead use:
> > #ifdef CONFIG_STK11XX_DEBUG_STREAM
> 
> Hmm, no, I would rather get rid of CONFIG_ thing, it may make things
> unclear, beacuse there is (will be) no option in Kconfig for this, because
> this is the most verbose option for the driver mainly used for algorithms
> debugging.
Seems ok to me.

> > We don't do format conversions in kernel. Instead, you should return a
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Carvalho Chehab | 2 Jun 2007 01:01
Favicon

Re: [PATCH] ARM: OMAP: Camera if: Add new camera/sensor interface.

Em Qui, 2007-05-31 às 12:06 +0530, Trilok Soni escreveu:
> On 5/18/07, Sakari Ailus <sakari.ailus <at> nokia.com> wrote:
> > ext Mauro Carvalho Chehab wrote:
> > > Hi Sakari,
> >
> > Hi,
> >
> > > Sorry for not answering faster. I'm a little busy with lots of other
> > > stuff here.
> >
> > I'm sorry too. The same applies to me even greater extent. ;) First
> > quite busy, then vacation... :\
> >
> 
> ...
> 
> >
> > I guess I'll modify the current interface to match more closely to V4L
> > ioctls. This way, it'll be easily adapted to a more generalised
> > interface later.
> >
> 
> Any updates with above changes as you have agreed? I can atleast help
> you on changing sensor-ov9640/tcm85x code to latest I2C style
> {probe/remove} bindings. So if you have latest patches just drop it to
> me and I can adapt that to new i2c style bindings.

For me, this seems to be fine.
> 
--

--
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mauro Carvalho Chehab | 2 Jun 2007 01:10
Favicon

Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver


> > This seems to be an interesting approach.
> >
> >   
> Interesting but impossible to do for ioctl calls.
> When the application does a ioctl(fd_of_mnt_video0,VIDIOC_G_FMT,&arg) 
> for example, there is no way for the userspace helper to catch this ioctl.
> The application could only open/read from the userspace helper's file 
> /mnt/video0.
> ioctl would still have to be done on the kernel device driver.
> I thought also about a /proc interface for decompression algorithms (a 
> helper would listen on a /proc file and write on another /proc file) but 
> /proc is not designed for that kind of thing.
> A separate library seems to be the simplest solution.

There are some ways for this to work. For example, you may create a
helper device for the daemon driver to bind, even requiring it to have
root permission.

--

-- 
Cheers,
Mauro
Permalink | Reply | 10 comments |
headers
Mauro Carvalho Chehab | 2 Jun 2007 01:35
Favicon

Re: "by-name" rules for udev

Hi Kees,

> For names, we could even possibly even use the pci device/vendor combo

Using PCI IDs doesn't seem to be a good idea, since about half of the
supported devices don't have a vendor ID, using, instead, a common
value. 

It should also be noticed that some devices will have more than one
device, like /dev/video? /dev/radio? /dev/vbi?.

Maybe it is time to add some stuff at sysfs to allow better identifying
each device and their subdevices.

--

-- 
Cheers,
Mauro

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |
headers
Thierry Merle | 2 Jun 2007 11:00
Picon
Favicon

Re: [PATCH 1/1] V4L: stk11xx, add a new webcam driver


Mauro Carvalho Chehab a écrit :
>>> This seems to be an interesting approach.
>>>
>>>   
>>>       
>> Interesting but impossible to do for ioctl calls.
>> When the application does a ioctl(fd_of_mnt_video0,VIDIOC_G_FMT,&arg) 
>> for example, there is no way for the userspace helper to catch this ioctl.
>> The application could only open/read from the userspace helper's file 
>> /mnt/video0.
>> ioctl would still have to be done on the kernel device driver.
>> I thought also about a /proc interface for decompression algorithms (a 
>> helper would listen on a /proc file and write on another /proc file) but 
>> /proc is not designed for that kind of thing.
>> A separate library seems to be the simplest solution.
>>     
>
> There are some ways for this to work. For example, you may create a
> helper device for the daemon driver to bind, even requiring it to have
> root permission.
>
>   
Right, but I am afraid that complex userspace/kernelspace context 
changes breaks performance.
Nevertheless, I will start to specify the framework.
The helper daemon would link to the v4l2-apps/lib.
Permalink | Reply | 8 comments |
headers
David Mayne | 2 Jun 2007 11:59

Re: Help with cx88 driver and Hauppauge HVR-1300

For what it's worth, I've also change the motherboard on the machine  
(had a spare Socket A lying around) and tried a different card of the  
same model (bought two for this project) and still no joy.  It does  
all seem to work fine in Windoze though.  Please point me in the  
right direction as I *really* don't want to have to sit and use  
Windows for this!

Thanks

David

On 31 May 2007, at 19:10, David Mayne wrote:

> Hi,
>
> I'm posting this again as I'm not sure if it's actually gotten out  
> on to the ether.  If it has and you're ignoring it cos it's the  
> wrong place to post, please just give me a quick nudge in the right  
> direction :)
>
> Anyway, I'm trying to test my installation of a Hauppauge HVR-1300  
> for a VDR setup and I've run out of ideas on how to get round this  
> problem.  I've followed the testing steps on http://www.ethics- 
> gradient.net/myth/mythdvb.html and can get an FE_LOCK etc when  
> tuning channels.  However, when I run "dvbstream -o -ps -qam 16 -cr  
> 3_4 600 601 | mplayer -" to test capturing data, I get nothing in  
> appear in Mplayer and in /var/log/messages, I get the following  
> errors:
>
> May 25 20:52:42 pine kernel: [  325.404000] cx8802_start_dma()
(Continue reading)

Permalink | Reply | 2 comments |
headers
Markus Rechberger | 2 Jun 2007 22:21
Picon

v4l-dvb: bugs and regressions

Hi,

I put together a small list of bugs and regressions which occured
during the last year/months which are still unsolved.

http://mcentral.de/wiki/index.php/Bugtracker

feel free to comment these issues, most issues are still not handled.

Markus

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list
Permalink | Reply | 0 comments |

Gmane