What info does V-4-L expect to be in the "Identifier EEprom"?

What info does V-4-L expect to be in the "Identifier EEprom"?

[Fritz Katz]

I'm a consultant for a company that wishes to produce a video cards that will run Video-4-Linux applications. The company currently produces tuners and video capture cards for Microsoft Windows.

The company wishes to include an "Identifier EEprom" on the board so V4L will 
recognize the card and load appropriate drivers at boot-up.

Please point me in the direction of documentation for the info V4L expects to 
be found in the ID eeprom.

Thanks in advance!
-- Fritz Katz


      

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: What info does V-4-L expect to be in the "Identifier EEprom"?

[Alan Cox]

On Wed, Jul 30, 2008 at 08:54:36AM -0700, Fritz Katz wrote:
> I'm a consultant for a company that wishes to produce a video cards that will run Video-4-Linux applications. The company currently produces tuners and video capture cards for Microsoft Windows.
> 
> The company wishes to include an "Identifier EEprom" on the board so V4L will 
> recognize the card and load appropriate drivers at boot-up.
> 
> Please point me in the direction of documentation for the info V4L expects to 
> be found in the ID eeprom.

This depends on the chipset. The kernel matches drivers generally by using the
PCI class code, PCI vendor/device and PCI subvendor/device. For some video
capture devices multiple vendors shipped different devices with no real
distinguishing features except internal eeprom detail.

Peering into eeproms to tell them apart is generally a last resort and if there
are unique subvendor/devicd identifiers for your card that should be all you
need except to add entries to the relevant device driver indicating the relevant
GPIO pins/tuner etc for board specific stuff.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: What info does V-4-L expect to be in the "Identifier EEprom"?

[Hans Verkuil]

On Wednesday 30 July 2008 17:54:36 Fritz Katz wrote:
> I'm a consultant for a company that wishes to produce a video cards
> that will run Video-4-Linux applications. The company currently
> produces tuners and video capture cards for Microsoft Windows.
>
> The company wishes to include an "Identifier EEprom" on the board so
> V4L will recognize the card and load appropriate drivers at boot-up.
>
> Please point me in the direction of documentation for the info V4L
> expects to be found in the ID eeprom.

Currently the tveeprom module is specific for Hauppauge cards. The 
documentation of how (most) of that eeprom is setup is part of the 
tveeprom.c source (see the tveeprom_hauppauge_analog function).

It is likely you will choose your own format, but it is very useful if 
the eeprom has information like:

- model number/type of the card
- what tuner chip(s) is/are used (tuners tend to be swapped for 
different models quite often).
- whether there is a radio supported
- IR support (none, just a receiver, both receiver and transmitter)
- Any encoder/decoder chips (unless that can be derived from the model 
number).

In general: anything you need to determine which chips are on the board 
and on which i2c address. And how external connectors are hooked up to 
those chips (if that can vary).

Of course, if all this can be directly determined by the PCI 
(sub)vendor/device IDs, then there is no need for an eeprom. Sadly, my 
experience is that the PCI IDs tend to be insufficient or plain wrong, 
especially by cheap cards based on a reference design from another 
company. In several cases the PCI IDs where unchanged from the 
reference design, making it impossible to discover which card it really 
is.

Regards,

	Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: What info does V-4-L expect to be in the "Identifier EEprom"?

[Fritz Katz]

--- On Wed, 7/30/08, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> 
> It is likely you will choose your own format, but it is
> very useful if the eeprom has information like:
> 
> - model number/type of the card
> - what tuner chip(s) is/are used (tuners tend to be 
>     swapped for different models quite often).
> - whether there is a radio supported
> - IR support (none, just a receiver, both receiver 
>     and transmitter)
> - Any encoder/decoder chips (unless that can be derived
>   from the model number).
> 
> In general: anything you need to determine which chips are
> on the board and on which i2c address. And how external 
> connectors are hooked up to those chips (if that can vary).
> 

  So it would be sufficient to just include an ASCII string containing the above information?  

Then I could send it to this list, and the board could be recognized in the next release of V-4-L?

> Of course, if all this can be directly determined by the
> PCI (sub)vendor/device IDs, then there is no need for an
> eeprom. 

I'm assuming that the list of PCI (sub)vendor/device IDs is here:

http://www.pcidatabase.com/pci_c_header.php

and that the Video-4-Linux references pcihdr.h:
"PCI_DEVTABLE	PciDevTable [] = {..."
to determine the vendor/device ID.

Should those two hex numbers should be the first 32 bytes in the EEPROM?

Unfortunately, the company I'm consulting for is not in the list. I suppose we can submit an unused vendor ID to the site.

> Sadly, my experience is that the PCI IDs tend to be insufficient 
> or plain wrong, especially by cheap cards based on a reference 
> design from another company. 

Here's my sad story attempting to bring the board up on Linux:

____________

When I install one of the pci cards in the Linux box, and boot, an 
actual 'rant' appears in the dmesg:

	saa7130/34: v4l2 driver version 0.2.14 loaded
	phy0: hwaddr 00:40:f4:f8:83:e4, RTL8185vD + rtl8225z2
	ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 17 (level, low) -> IRQ 17
	saa7130[0]: found at 0000:00:09.0, rev: 1, irq: 17, latency: 32, mmio: 0xe2000000
	saa7134: <rant>
	saa7134:  Congratulations!  Your TV card vendor saved a few
	saa7134:  cents for a eeprom, thus your pci board has no
	saa7134:  subsystem ID and I can't identify it automatically
	saa7134: </rant>

and, when it sees the Philips decoder chip it says:

	saa7130[0]: Huh, no eeprom present (err=-5)?

I suppose the 5 line <rant> is useful if it shames companies 
into including the ID eeprom. But the <rant> then goes on to 
spew into dmesg and /var/log/messages a list 144 different 
cards. A more helpful suggestion might be to print a URL 
to a trouble-shooting webpage to help people determine 
which card they have. I have found this page to be helpful:

http://www.de.gentoo-wiki.com/HARDWARE_saa7134

Apparently it's necessary to cycle through rmmod/modprobe/watchTV 
to see which combo works. Here's the simple script:
 -----------------------
 #/bin/sh
 MAXCARD=144
 MAXTUNER=69
 for i in $(seq 0 $MAXCARD);
 do
   for j in $(seq 0 $MAXTUNER);
   do
     rmmod tuner saa7134
     modprobe saa7134 card=$i tuner=$j
     echo "Is TVtime working with card=" $i " and tuner=" $j " ? "
     sleep 1 # make sure /dev/video is registered when tvtime starts
     tvtime
   done
 done
 -----------------------

There are over 144 card and 69 tuner combos = 9936.  
GAAACK!, takes a long time.

Also, from hard experience, I've found it's necessary to do a:

# tail -f /var/log/messages

in another shell to make sure the card is still responding 
to commands. Some tuner numbers apparently lock up the card, 
reboot required, and you won't know that anything is 
wrong -- while you spend hours testing combos that should 
have worked.

I finally found a card/tuner combo. Using tvtime, the video 
output doesn't appear on the 'Television' output. Instead 
it appears on 'Composite2' output. You can only tune 
channels by using 'Input Configuration', switching to a 
blue-screen 'Television' and then switching back to 
'Composite2' to view it.

Sometimes the board tunes fine. Sometimes after re-boot 
it may be necessary to do fine-tuning to receive stations. 
I suppose since the board is not recognized by V-4-L, the 
tuner section may not be initialized properly?

Regards,
-- Fritz Katz.







      

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: What info does V-4-L expect to be in the "Identifier EEprom"?

[Hans Verkuil]

On Wednesday 30 July 2008 20:37:19 Fritz Katz wrote:
> --- On Wed, 7/30/08, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > It is likely you will choose your own format, but it is
> > very useful if the eeprom has information like:
> >
> > - model number/type of the card
> > - what tuner chip(s) is/are used (tuners tend to be
> >     swapped for different models quite often).
> > - whether there is a radio supported
> > - IR support (none, just a receiver, both receiver
> >     and transmitter)
> > - Any encoder/decoder chips (unless that can be derived
> >   from the model number).
> >
> > In general: anything you need to determine which chips are
> > on the board and on which i2c address. And how external
> > connectors are hooked up to those chips (if that can vary).
>
>   So it would be sufficient to just include an ASCII string
> containing the above information?

That's one way of doing it. Usually it tends to be a bit more 
systematic.

> Then I could send it to this list, and the board could be recognized
> in the next release of V-4-L?

Someone needs to add code to the saa7134 driver to parse the eeprom.

> > Of course, if all this can be directly determined by the
> > PCI (sub)vendor/device IDs, then there is no need for an
> > eeprom.
>
> I'm assuming that the list of PCI (sub)vendor/device IDs is here:
>
> http://www.pcidatabase.com/pci_c_header.php
>
> and that the Video-4-Linux references pcihdr.h:
> "PCI_DEVTABLE	PciDevTable [] = {..."
> to determine the vendor/device ID.
>
> Should those two hex numbers should be the first 32 bytes in the
> EEPROM?

No, PCI IDs are stored by the PCI hardware (I'm no expert on this). The 
boards already have PCI IDs since they are mandated by the PCI 
standard. You can find them with 'lspci -vn'.

> Unfortunately, the company I'm consulting for is not in the list. I
> suppose we can submit an unused vendor ID to the site.

No! The cards already have vendor/device/subvendor/subdevice IDs. Ask 
the engineers, they should have all the details on this.

You need to add a card definition to the saa7134-cards.c source. It's 
not magic, someone has to do some coding. And if the PCI IDs are 
sufficient to uniquely determine with card it is, then there is no need 
for an eeprom. On the other hand, if there are several types of board 
with the same PCI IDs but different components, then something like 
that might be needed.

> > Sadly, my experience is that the PCI IDs tend to be insufficient
> > or plain wrong, especially by cheap cards based on a reference
> > design from another company.
>
> Here's my sad story attempting to bring the board up on Linux:
>
> ____________
>
> When I install one of the pci cards in the Linux box, and boot, an
> actual 'rant' appears in the dmesg:
>
> 	saa7130/34: v4l2 driver version 0.2.14 loaded
> 	phy0: hwaddr 00:40:f4:f8:83:e4, RTL8185vD + rtl8225z2
> 	ACPI: PCI Interrupt 0000:00:09.0[A] -> GSI 17 (level, low) -> IRQ 17
> 	saa7130[0]: found at 0000:00:09.0, rev: 1, irq: 17, latency: 32,
> mmio: 0xe2000000 saa7134: <rant>
> 	saa7134:  Congratulations!  Your TV card vendor saved a few
> 	saa7134:  cents for a eeprom, thus your pci board has no
> 	saa7134:  subsystem ID and I can't identify it automatically
> 	saa7134: </rant>

PCI IDs are not known in the card list, so it falls back to this.

>
> and, when it sees the Philips decoder chip it says:
>
> 	saa7130[0]: Huh, no eeprom present (err=-5)?
>
> I suppose the 5 line <rant> is useful if it shames companies
> into including the ID eeprom. But the <rant> then goes on to
> spew into dmesg and /var/log/messages a list 144 different
> cards. A more helpful suggestion might be to print a URL
> to a trouble-shooting webpage to help people determine
> which card they have. I have found this page to be helpful:
>
> http://www.de.gentoo-wiki.com/HARDWARE_saa7134
>
> Apparently it's necessary to cycle through rmmod/modprobe/watchTV
> to see which combo works. Here's the simple script:
>  -----------------------
>  #/bin/sh
>  MAXCARD=144
>  MAXTUNER=69
>  for i in $(seq 0 $MAXCARD);
>  do
>    for j in $(seq 0 $MAXTUNER);
>    do
>      rmmod tuner saa7134
>      modprobe saa7134 card=$i tuner=$j
>      echo "Is TVtime working with card=" $i " and tuner=" $j " ? "
>      sleep 1 # make sure /dev/video is registered when tvtime starts
>      tvtime
>    done
>  done
>  -----------------------
>
> There are over 144 card and 69 tuner combos = 9936.
> GAAACK!, takes a long time.
>
> Also, from hard experience, I've found it's necessary to do a:
>
> # tail -f /var/log/messages
>
> in another shell to make sure the card is still responding
> to commands. Some tuner numbers apparently lock up the card,
> reboot required, and you won't know that anything is
> wrong -- while you spend hours testing combos that should
> have worked.
>
> I finally found a card/tuner combo. Using tvtime, the video
> output doesn't appear on the 'Television' output. Instead
> it appears on 'Composite2' output. You can only tune
> channels by using 'Input Configuration', switching to a
> blue-screen 'Television' and then switching back to
> 'Composite2' to view it.
>
> Sometimes the board tunes fine. Sometimes after re-boot
> it may be necessary to do fine-tuning to receive stations.
> I suppose since the board is not recognized by V-4-L, the
> tuner section may not be initialized properly?

Yup. As I said, someone has to write card definitions for these boards. 
It's not magic, you know. Someone has to tell the saa7134 driver how to 
detect the cards and what to do.

Regards,

	Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: What info does V-4-L expect to be in the "Identifier EEprom"?

[Fritz Katz]

Thank you Hans, 

  I need to correct my own mis-information.
  Vendor ID assignments are given out by an industry group PCISIG.
  Membership costs $3000 and has other benefits:

    http://www.pcisig.com/membership/join_pci_sig/

_________________________________________
--- On Wed, 7/30/08, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> >
> > Should those two hex numbers should be the first 32
> > bytes in the EEPROM?
> 
> No, PCI IDs are stored by the PCI hardware (I'm no
> expert on this). The boards already have PCI IDs since 
> they are mandated by the PCI standard. You can find them 
> with 'lspci -vn'.
> 
> > Unfortunately, the company I'm consulting for is
> > not in the list. I suppose we can submit an unused 
> > vendor ID to the site.
> 
> No! The cards already have
> vendor/device/subvendor/subdevice IDs. Ask 
> the engineers, they should have all the details on this.
> 



      

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: What info does V-4-L expect to be in the "Identifier EEprom"?

[hermann pitton]

Hi everyone,

Am Mittwoch, den 30.07.2008, 13:44 -0700 schrieb Fritz Katz:
> Thank you Hans, 
> 
>   I need to correct my own mis-information.
>   Vendor ID assignments are given out by an industry group PCISIG.
>   Membership costs $3000 and has other benefits:
> 
>     http://www.pcisig.com/membership/join_pci_sig/
> 

Fritz, for what I can see you for sure don't have an eeprom yet on that
card(s).

Since PCI subvendor and subdevice information is stored there,
we for now could only add those cards providing them a card=Number entry
the users must look up.

To blow out all the known cards if an eeprom is not detected, you are
right, is becoming a bit overloaded and confusing, but that started with
some card=5 or 6 IIRC. Documentation/CARDLIST.saa7134 mirrors it.

If there is no eeprom, no subvendor/subdevice information is available
and there is no way around of it for auto detection.

The default Philips, the vendor, as subvendor on it and device 0x0 is
also not legal for detection use. There are some weired faulty solutions
in between, I would like to kick them even out too, since nobody can
guarantee, that they are unique. (the bomb ticks)

Trying all possible card variants is a risky business, so far, no
hardware died on it, as far I can truly tell, but there is some
remaining risk to have components on some card, which can't stand a
shortage.

So, it is not recommended to proceed that way for all cards around, like
you have seen, gpio stuff has impacts, but trying tuners should be safe.

Old can/tin tuners melt down to some very few tuner APIs, else we would
have several hundreds more in the end. How they are broken down
currently, you can see quite well in the Hauppauge tveeprom.

The rule is, if any new old ;) tuner on the markets really requires a
new entry, it is granted, but we don't duplicate stuff without limit we
have already.

We have countless cards without eeprom faking just card=3.

Else we need the dmesg with gpio init reported at least and a complete
description of all chips to start some guessing.

The v4l wiki at linuxtv.org and the bttv.gallery.de might give you some
hints and directions.

Recent saa713x stuff, which can mean triple or quad capabilities, like
multiple analog, DVB-T and DVB-S on it, also LowNoiseAmplifiers, which
must be configured correctly and invisible chips behind i2c bridges,
also all sort of gpio switching coming potentially from everywhere, are
not a simple task anymore.

But a simple saa7130, if not with some remote using an unknown protocol,
should be a fairly simple job. So far Hans is right.

Cheers,
Hermann



______________________________________
> --- On Wed, 7/30/08, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> > >
> > > Should those two hex numbers should be the first 32
> > > bytes in the EEPROM?
> > 
> > No, PCI IDs are stored by the PCI hardware (I'm no
> > expert on this). The boards already have PCI IDs since 
> > they are mandated by the PCI standard. You can find them 
> > with 'lspci -vn'.
> > 
> > > Unfortunately, the company I'm consulting for is
> > > not in the list. I suppose we can submit an unused 
> > > vendor ID to the site.
> > 
> > No! The cards already have
> > vendor/device/subvendor/subdevice IDs. Ask 
> > the engineers, they should have all the details on this.
> > 
> 


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Re: What info does V-4-L expect to be in the "Identifier EEprom"?

[Steven Toth]

Fritz Katz wrote:
> I'm a consultant for a company that wishes to produce a video cards that will run Video-4-Linux applications. The company currently produces tuners and video capture cards for Microsoft Windows.
> 
> The company wishes to include an "Identifier EEprom" on the board so V4L will 
> recognize the card and load appropriate drivers at boot-up.
> 
> Please point me in the direction of documentation for the info V4L expects to 
> be found in the ID eeprom.
> 

Congratulations, another company starting to see the light. :)

 From the thread is sounds like you have a fairly regular 713x board.

- Steve

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list