[ANNOUNCE] new driver for teletext decoder SAA5246A

[ANNOUNCE] new driver for teletext decoder SAA5246A

[Michael Geng]

Hello,

I would like to introduce a new device driver for the I2C based 
Videotext/Teletext decoder SAA5246A from Philips. The interface 
is identical to the existing driver for the SAA5249 chip. User 
programs can access these devices via /dev/vtx0 ... /dev/vtx31.

Templete was drivers/media/video/saa5249.c, some of the SAA5246A 
functionality was taken from the original driver from Martin Buck 
(http://home.pages.de/~videotext/). In order to make the driver 
sources easier to understand I added lots of symbolic constants 
related to the data sheet of the SAA5246A from Philips.

The driver is available as a patch to the linux kernel version 
2.6.3 from http://www.michaelgeng.de/linux/saa5246a-2.6.3.patch

I know that today's TV cards do no more have such a teletext 
processor chip on board, they use the CPU for decoding videotext 
pages. This is much faster if you want to extract all the pages 
from a TV station for reading like a journal. I also wanted to 
change to the vbi interface but after some trial I went back to 
decoding via SAA5246A because there were more errors in the pages
decoded with the vbi interface than with the vtx interface using 
a SAA5246A. I don't know why. And have you tried to capture a 
special subpage from a page that contains 10 suppages or more? 
When it is finally transmitted after 10 Minutes you will have to 
wait for another 10 Minutes if your CPU missed it. According to my 
experience a teletext processor will more probably capture the 
page.

Of courde I have tested the driver both as a module and compiled 
into the kernel. It is licensed under the GPL.

I would be happy to get some feedback!

Michael

Re: [ANNOUNCE] new driver for teletext decoder SAA5246A

[Michael Geng]

On Wed, Feb 25, 2004 at 04:13:30AM -0800, Andrew Morton wrote:
> linux@MichaelGeng.de (Michael Geng) wrote:
> >
> > http://www.michaelgeng.de/linux/saa5246a-2.6.3.patch

Location of the updated patch:

http://www.michaelgeng.de/linux/saa5246a-rev1-2.6.3.patch

> jdelay() is odd - it's a shame it has to fiddle with signals in that
> manner.  Are you sure it's really needed?

I copied this jdelay() stuff from the existing saa5249.c 
without much reflecting about it. 

In my opinion it is up to the user space program to request the 
driver status in reasonable time intervals in order to see if a
requested videotext page has been received. The kernel driver 
should answer without delay. It can't be the task of the kernel
driver to prevent a user space program from querying the status 
10000 times a second.

Conclusion: You are right, the jdelay() stuff is not necessary
at all. I removed it completely from the code. After that I 
tested the newly compiled driver using Martin Buck's vtxget 
program. The command 

time vtxget 100

consumed about 0.4secs sys time before and about 0.5secs after
removing jdelay(). I think this is ok, the driver still works 
fine.

> Also, I suggest you try removing all those `inline' statements.  Then see
> if /usr/bin/size claims that the code shrunk.  Often it does.

No, it doesn't shrink. I already tested that when I developed 
the driver with saa5249.c as a template. Now I made a completely
inline-free version, but /usr/bin/size shows exactly the same
size. By the way, this shows that gcc does a good job. Of course
this could also depend on the architecture, but on my Pentium 4
box gcc really puts the inline parts inline.

There are 2 reason why I used these inline functions:

1. A huge ioctl() function would be more difficult to understand
   than those individual inline functions. Don't you agree?

2. Some of those inline functions are not only specific to the
   SAA5246A. They could also be used for the existing driver to
   the SAA5249 or other drivers of that series. Maybe this could 
   be useful if someone wants to write another driver or even
   in order to merge the SAA5246A and SAA5249 drivers into 1 
   driver. Maybe this is possible, I'm not sure. I would
   like to try, but unfortunately I don't have a SAA5249. Does
   anybody want to sell his sample to me?

Conclusion: I would prefer to keep all those inline functions.
The inline functions are not changed in the updated patch.
			 
> Apart from that, looks fine.  Please send me a copy via email along with a
> suitable changelog for checking into Bitkeeper and copy Gerd Knorr
> <kraxel@bytesex.org>, thanks.

If you want to add the patch, how about the following changelog:

[V4L]: Added new driver for Teletext decoder SAA5246A from Philips

Thank you very much for your help,
Michael

Re: [ANNOUNCE] new driver for teletext decoder SAA5246A

[Andrew Morton]

linux@MichaelGeng.de (Michael Geng) wrote:
>
> No, it doesn't shrink. I already tested that when I developed 
> the driver with saa5249.c as a template. Now I made a completely
> inline-free version, but /usr/bin/size shows exactly the same
> size. By the way, this shows that gcc does a good job. Of course
> this could also depend on the architecture, but on my Pentium 4
> box gcc really puts the inline parts inline.

Yup.  I was suggesting remmoval of the `inline' keyword, rather than
actually moving the bodies of those functions into the caller.

I've previously seen significant code size reductions by _not_ inlining
large functions which had a single call site - just leave them as normal
out-of-line functions.  So it worth experimenting with - pretty simple to
do.  But if you're using a recent gcc it's probably inlining the function
even when it's not marked inline.   Whatever.

> If you want to add the patch, how about the following changelog:
> 
> [V4L]: Added new driver for Teletext decoder SAA5246A from Philips

Thanks.

Re: [ANNOUNCE] new driver for teletext decoder SAA5246A

[Michael Geng]

> Yup.  I was suggesting remmoval of the `inline' keyword, rather than
> actually moving the bodies of those functions into the caller.
> 
> I've previously seen significant code size reductions by _not_ inlining
> large functions which had a single call site - just leave them as normal
> out-of-line functions.  So it worth experimenting with - pretty simple to
> do.  But if you're using a recent gcc it's probably inlining the function
> even when it's not marked inline.   Whatever.

Sorry for the misunderstanding. I now tested code size with and without
the inline keyword. It's as you said: In some cases code size increases
in some cases it stays the same, in some cases size decreases. I removed
2 inline statements, this reduced the code size by 34 bytes. It's really
worth experimenting with the inline keyword.

The newly updated patch is located at
http://www.michaelgeng.de/linux/saa5246a-rev2-2.6.3.patch

> > If you want to add the patch, how about the following changelog:
> > 
> > [V4L]: Added new driver for Teletext decoder SAA5246A from Philips

Re: [ANNOUNCE] new driver for teletext decoder SAA5246A

[Michael Geng]

> Auf dem sogenannten "Multimedia eXtension Board", einer analogen
> TV-Karte auf saa7146 Basis, sitzt ein saa5281 Teletext-Prozessor.

Ich habe mir das Board gerade mal angesehen. Ausserdem habe ich das
Datenblatt fuer den SAA5281 mal ueberflogen. Der SAA5281 ist demnach
Software- und Hardwarekompatibel zum SAA5246.

> Vor langer Zeit (> 2 Jahren) habe ich mal den saa5249 Treiber gehackt,
> damit er auch mit dem saa5281 kooperiert. Hat auch gut geklappt,
> allerdings habe ich es vermieden, den Treiber mit in den 2.6er Kernel
> zu
> bringen, weil er einfach zu h?sslich war.

Kann ich mir den Treiber mal ansehen?

> Des weiteren hatte ich es dann irgenwann nicht mehr geschafft, die
> Teletext-Applikationen zu ?bersetzen und irgendwie war mir das ganze
> API
> dann zu bloated, so dass ich das Interesse verloren habe.

Ich auf meiner neuesten Linux-Installation von Martin Buck's Packet
eigentlich auch nur noch das blanke vtxget uebersetzen. Make vtxget
tut's immer noch. Momentan reicht mir das.

> Die Karten sind mittlerweile richtig, richtig billig auf EBay zu haben
> (oftmals f?r unter 10 EUR) und ich habe schon nen ganzen Stapel davon.
> 8-)
 
Was machst Du denn mit so vielen Karten?

Ich werde auch mal bei Ebay reinsehen, vielleicht kauf' ich mir auch
eine.

> Ich werde mir bei Gelegenheit deinen Treiber mal anschauen und
> gucken,
> was man da f?r den saa5281 Support reinbauen muss.

Wenn Du mir Deinen saa5281 Treiber schickst dann sehe ich mir evtl. das
gleiche mal in umgekehrter Richtung an.

Es tut gut zu hoeren, dass ich nicht der einzige bin, der die alten
SAA52xx noch verwenden will!
  
Tschuess,
Michael