headers
morimoto.kuninori | 1 Dec 2008 01:38

Re: [PATCH] Add ov7725 ov7720 support to ov772x driver


Dear Guennadi

Thank you for checking patch.

> >  <at>  <at>  -837,15 +859,16  <at>  <at>  static int ov772x_video_probe(struct soc_camera_device *icd)
> >  	 */
> >  	pid = i2c_smbus_read_byte_data(priv->client, PID);
> >  	ver = i2c_smbus_read_byte_data(priv->client, VER);
> > -	if (pid != 0x77 ||
> > -	    ver != 0x21) {
> > +	if (pid != GET_PID(priv->id->driver_data) ||
> > +	    ver != GET_VER(priv->id->driver_data)) {
> >  		dev_err(&icd->dev,
> >  			"Product ID error %x:%x\n", pid, ver);
> >  		return -ENODEV;
> >  	}
> 
> this means, you can indeed probe the exact type of the camera - 7720 vs. 
> 7725, right? Then why do you require the platform code to also specify 
> exactly which camera is connected? Why don't you leave the platform code 
> at the old requirement, i.e., it should just register an i2c device of 
> type "ov772x" and then detect yourself what exactly sensor is there? This 
> is what I've done in mt9m001 and mt9v022. They both support several sensor 
> variants too. This way you can use one kernel for all compatible cameras. 
> If there is no real reason not to do the same in ov772x, I would suggest 
> you switch it over to autoprobing.

Indeed, it is not necessary to specify it accurately.
Sorry about it.
(Continue reading)

Permalink | Reply | 3 comments |
headers
CityK | 1 Dec 2008 02:37
Favicon

Re: HVR-1800 problems.

Mark, did you look at the earlier response ?? :

http://marc.info/?l=linux-video&m=122806908902796&w=2

--
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
CityK | 1 Dec 2008 02:40
Favicon

KWorld ATSC 110 and NTSC [was: 2.6.25+ and KWorld ATSC 110 inputs]

stuart wrote:
> V4L support for the KWorld ATSC120 is limited.  There a numerous threads 
> here which talk about the problems and some work arounds.  The 
> developers have talked about adding support but consider new features at 
> the cost of an overhaul of the current driver.
>
> Right now I believe you can not use both ATSC and NTSC tuners w/o power 
> cycling your computer and bringing it up with (only) the appropriate 
> driver.  Also, I don't believe the IR receiver works under V4L.  This 
> card replaced the Kworld 110 and Kworld 115 tuners.  If you can find 
> these older Kworld ATSC tuners, I would buy them instead as I believe 
> they are better supported under V4L (I also have a Kworld ATSC110 - but 
> only use it for ATSC tuning as well).
>
> Go here and read up on how people are setting this card up:
> > http://www.linuxtv.org/wiki/index.php/KWorld_ATSC_120
>
> I'm using the Kworld 120 as an ATSC tuner and nothing else in a Debian 
> mythtv slave back end system.

Stuart, while I don't know for sure, I believe that information about
the power cycling is now obsolete and the driver for the ATSC 120 is
working.

In any regard, such things are not related to the difficulties Bill is
experiencing with his 110 card.  I'll detail in the next message.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request <at> redhat.com?subject=unsubscribe
(Continue reading)

Permalink | Reply | 2 comments |
headers
CityK | 1 Dec 2008 03:09
Favicon

KWorld ATSC 110 and NTSC [was: 2.6.25+ and KWorld ATSC 110 inputs]

Hi Bill,

Bill Pringlemeir wrote:

> I have experimented with this a bit further.  Here are some of my
> observations,
>  
> I switch the antenna feed between top and bottom inputs with no effect
> on getting the NTSC signal.
>   

The NTSC issue is a known problem.

I tracked the error down to a commit Mauro had made (IIRC, back in
April) which ended up causing a regression on some boards  (e.g. KWorld
ATSC 110/115).  M.Krufky spun a quick patch (which works fine), but it
cannot be applied to the main Hg sources as it too would break other
things, and so some discussion would be needed to resolve the underlying
problem.  I was going to bug Mauro about the issue, but never got around
to it, and I don't know if Mike discussed this with Mauro at the recent
Plummers conference.  (I have cc'ed both in on the message).

Several posters on AVS forums were complaining of this and I posted a
link to Mike's patch and instructions (including a warning that it could
break support with other cards).  AFAIK, zero feedback was achieved from
that, as posters were either too scared by the warning or couldn't
follow the instructions, nor responded to further posts.  Whatever.

In any regard, Mike's patch, as I said, works fine, albeit is not a
perfect solution as it requires some manual intervention (or script) on
(Continue reading)

Permalink | Reply | 501 comments |
headers
Vanessa Ezekowitz | 1 Dec 2008 03:47
Picon
Gravatar

Re: KWorld ATSC 110 and NTSC [was: 2.6.25+ and KWorld ATSC 110 inputs]

On Sunday 30 November 2008 07:40:54 pm CityK wrote:
> stuart wrote:
> > V4L support for the KWorld ATSC120 is limited.  There a numerous threads 
> > here which talk about the problems and some work arounds.  The 
> > developers have talked about adding support but consider new features at 
> > the cost of an overhaul of the current driver.
> >
> > Right now I believe you can not use both ATSC and NTSC tuners w/o power 
> > cycling your computer and bringing it up with (only) the appropriate 
> > driver.  Also, I don't believe the IR receiver works under V4L.  This 
> > card replaced the Kworld 110 and Kworld 115 tuners.  If you can find 
> > these older Kworld ATSC tuners, I would buy them instead as I believe 
> > they are better supported under V4L (I also have a Kworld ATSC110 - but 
> > only use it for ATSC tuning as well).
> > Go here and read up on how people are setting this card up:
> > > http://www.linuxtv.org/wiki/index.php/KWorld_ATSC_120
> >
> > I'm using the Kworld 120 as an ATSC tuner and nothing else in a Debian 
> > mythtv slave back end system.

The OP was talking about the older 110 to begin with...so he already has one ;)

On my setup, with an ATSC 120 (not the 110), power cycling or rebooting is still necessary to switch between
analog/NTSC and digital/ATSC modes.  Trying to load both DVB and V4L drivers either renders the card
inoperable, or one or the other mode simply won't work.

In my case, for example, loading the analog driver (modprobe cx8800) followed by the DVB drivers (modprobe
cx88-dvb) results in working analog mode, but digital mode is defunct.  Rebooting and loading either of
the two alone results in that mode working fine indefinitely.
(Continue reading)

Permalink | Reply | 1 comment |
headers
CityK | 1 Dec 2008 04:18
Favicon

Re: KWorld ATSC 110 and NTSC [was: 2.6.25+ and KWorld ATSC 110 inputs]

Vanessa Ezekowitz wrote:
> On my setup, with an ATSC 120 (not the 110), power cycling or rebooting is still necessary to switch between
analog/NTSC and digital/ATSC modes.  Trying to load both DVB and V4L drivers either renders the card
inoperable, or one or the other mode simply won't work.
>
> In my case, for example, loading the analog driver (modprobe cx8800) followed by the DVB drivers
(modprobe cx88-dvb) results in working analog mode, but digital mode is defunct.  Rebooting and loading
either of the two alone results in that mode working fine indefinitely.
>
> Has there been a change to the driver that I'm not aware of?  I'm curious...

Ah, ok.  Thanks for the report Vanessa.   I must have been thinking of
something else -- sorry for providing that moment of false hope :P

--
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
David Brownell | 1 Dec 2008 06:34

Re: [PATCH v2] v4l2_device/v4l2_subdev: final (?) version

On Sunday 30 November 2008, Hans Verkuil wrote:
> > On a more philosophical note is GPIO really a single subdev or a
> > collection of independent serial & discrete buses to a collection of
> > subdevs?  In cx18 depending on the board, GPIO can reset chips,
> > change audio mux paths, change the state of LED's, and in the future
> > be used as a serial line (if I ever get that soft-UART to the IR
> > blaster implemented).
> 
> Definitely a collection of subdevs. Usually each chip driven by GPIO 
> would have its own subdev. So ivtv implements an audio muxer subdev, 
> but it might also have additional subdevs for other chips connected to 
> the GPIO lines. I haven't explored all the possibilities yet, but I 
> suspect that this can be a quite powerful solution.

Right.  GPIO is basically a glue tech ... the focus should be what's
being glued (the various subdevs, and their parents), not on the glue.
I think a standardized set of GPIO calls, and gpiolib, makes that a
lot easier nowadays; though maybe not always painless.

Keeping to the V4L2 topic:  I figure there will be some issues there
to sort out.  For example, it might be important to collect key
resources like GPIOs and regulators before setting up the various I2C
clients that rely on those for proper operation, or other parts of a
complex V4L2 "assembly" (to coin a term).  I understand that in some
cases those GPIOs are provided through I2C-based expanders... such
sequencing issues will become clearer as the $SUBJECT work matures.
(I'd expect the v4l2_device would manage such stuff.)

One widely accessible OMAP example:  the beagleboard.org hardware uses
a GPIO to enable its DVI output, and a regulator that must be enabled
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bill Pringlemeir | 1 Dec 2008 08:29
Picon
Favicon

Re: KWorld ATSC 110 and NTSC

On 30 Nov 2008, cityk <at> rogers.com wrote:

> Bill Pringlemeir wrote:

>> I have experimented with this a bit further.  Here are some of my
>> observations,

>> I switch the antenna feed between top and bottom inputs with no effect
>> on getting the NTSC signal.

> The NTSC issue is a known problem.

http://marc.info/?l=linux-video&m=121210186625441&w=2

[... blah blah blah ...]

I did investigate some of the difference between 2.6.24 and more
recent kernels.  The code is far better; user should expect some pain.
I was just hoping I was helping with a new issue; but I guess the
kernel lags behind mecurial.

> I tracked the error down to a commit Mauro had made (IIRC, back in
> April) which ended up causing a regression on some boards (e.g. KWorld
> ATSC 110/115).  M.Krufky spun a quick patch (which works fine), but it
> cannot be applied to the main Hg sources as it too would break other
> things, and so some discussion would be needed to resolve the underlying
> problem.  I was going to bug Mauro about the issue, but never got around
> to it, and I don't know if Mike discussed this with Mauro at the recent
> Plummers conference.  (I have cc'ed both in on the message).
(Continue reading)

Permalink | Reply | 501 comments |
headers
Steve Fink | 1 Dec 2008 07:55
Picon

USB device for uncompressed NTSC capture

This may be the wrong place for this question. I've been looking at a
number of places, but haven't managed to figure out what I need to
know.

I have a camera that only has analog NTSC output. I would like to get
the frames into my Linux laptop. The frames are 8-bit deep grayscale
and 320x240. I assume that they are getting expanded up into NTSC
format or something; I'm ok with that; I don't need it to be very
accurate.

On my desktop box, I have a Hauppage WinTV PCI card that hands me the
frames back via v4l. That works perfectly. I want to do the same on my
laptop, only using USB rather than PCI for obvious reasons. (1394
would be fine too. But I want something cheap.)

What devices are supported that would give me what I need? I scrounged
around on the linuxtv wiki and various other places, but it seems like
all of the USB sticks with analog inputs were doing fancy mpeg-2
compression, which kinda sucks for me:  I'm not saving the frames
anywhere, I'm processing them as they come in. So I'd rather not have
them compressed and then decompressed immediately. Also, although
quality isn't that big of a concern for me, latency is.

I don't need audio, TV tuning, a remote, or any of the other usual
crud that these things seem to have. I just want to get a stream of
frames at a rather low resolution, with the bits relatively
unmolested. I suspect that there may be many USB devices that would do
this for me, but for the life of me I can't figure out how to tell
which ones they are.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Guennadi Liakhovetski | 1 Dec 2008 08:06
Picon
Picon

Re: [PATCH] Add ov7725 ov7720 support to ov772x driver

Hi Morimoto,

On Mon, 1 Dec 2008, morimoto.kuninori <at> renesas.com wrote:

> > >  <at>  <at>  -837,15 +859,16  <at>  <at>  static int ov772x_video_probe(struct soc_camera_device *icd)
> > >  	 */
> > >  	pid = i2c_smbus_read_byte_data(priv->client, PID);
> > >  	ver = i2c_smbus_read_byte_data(priv->client, VER);
> > > -	if (pid != 0x77 ||
> > > -	    ver != 0x21) {
> > > +	if (pid != GET_PID(priv->id->driver_data) ||
> > > +	    ver != GET_VER(priv->id->driver_data)) {
> > >  		dev_err(&icd->dev,
> > >  			"Product ID error %x:%x\n", pid, ver);
> > >  		return -ENODEV;
> > >  	}
> > 
> > this means, you can indeed probe the exact type of the camera - 7720 vs. 
> > 7725, right? Then why do you require the platform code to also specify 
> > exactly which camera is connected? Why don't you leave the platform code 
> > at the old requirement, i.e., it should just register an i2c device of 
> > type "ov772x" and then detect yourself what exactly sensor is there? This 
> > is what I've done in mt9m001 and mt9v022. They both support several sensor 
> > variants too. This way you can use one kernel for all compatible cameras. 
> > If there is no real reason not to do the same in ov772x, I would suggest 
> > you switch it over to autoprobing.
> 
> Indeed, it is not necessary to specify it accurately.
> Sorry about it.
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane