Re: TW6800 based video capture boards

Re: TW6800 based video capture boards

[Domenico Andreoli]

On Mon, May 26, 2008 at 07:39:59AM -0300, Mauro Carvalho Chehab wrote:
> On Sun, 25 May 2008 04:00:28 +0200 Domenico Andreoli <cavokz@gmail.com> wrote:
> 
> >   I have some shining boards based on Techwell TW6802 and a "working"
> > V4L2 driver provided by the producer. Ah.. I have also the specs of
> > those TW6802 chips. Everything has been purchased by my employer.
> > 
> > Now I am eager to publish everything but I can't right now. My employer
> > would not understand and I would be in a difficult position. He already
> > knows that those drivers are based on GPL software and then _are_ GPL
> > at all the effects but he still needs to completely understand how it
> > works. Those guys are always happy to use Linux for free but at the
> > time of giving anything back...
> > 
> > To make the long story short, I want to rewrite them. So, how do
> > you judge my (legal) position? Yes, you are not a lawyer but I would
> > appreciate any related advice anyway ;)
> 
> I think this will depend if you have a signed NDA or not, and what are their
> terms. Better to consult a lawyer ;)

No NDA has been signed by me but I still do not know all the details
of the agreement.

In the meanwhile I am cleaning the "patch" trying to reduce noise and
hoping to not break anything. This also helps me to dig into their changes.

> > Since I am a kernel newbie I am expecting to receive lots of "leave
> > V4L2 to expert coders..." but I will try anyway. You are warned :)
> 
> Just do your work and submit us the code. We'll analyze it and point for
> issues, if needed ;) If you have any doubts about V4L2, I can help you.

The given driver is not a patch but a zip of the modified bt8xx directory
taken from 2.6.18. Their changes do not integrate with existing bttv
driver, which has been cannibalized as if one would use V4L only with
their cards. You want a different kernel version, you unzip the driver
in the new tree, easy.

These TW6800 chips must somewhat resemble Bt848/878, the given driver
is based on bttv. Anyway they differ in many points, some are trivial
changes while other are more substantial. My impression is that the
design of TW6800 shares some points with the one of Bt848 but it is
fundamentally a different beast.

If support to TW6800 has to be provided in the bttv driver, it seem the
most logical choice at the first glance, the bttv's framework needs to
be changed accordingly.

For instance, in bttv-gpio.c those few helper function work with
registers at a different location, everything else is left as the
original bttv driver. So supposing to provide and additional set of
functions specific to TW6800 they should be called instead of the
original generic bttv Bt848 ones ony for TW6800 cards at runtime. A
new bttv_ops entry, if anything like this exists.

I have also some thoughts for bttv-risc.c. What is it? It is used
to generate any RISC op-codes to be downloaded on the board? It seem
responsible for DMA operations.

There is the biggest chunk of changes in bttv-driver.c but I still have
to dig into it.

Finally, the bttv driver needs a restyle for V4L2, right? So it would
be a shame to use it to fork the TW6800 support, wouldn't it? Which
are the plans here?

I have a strong interest in this area, I am available to test any patch.

Regards,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

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

Re: TW6800 based video capture boards

[Mauro Carvalho Chehab]

> > Just do your work and submit us the code. We'll analyze it and point for
> > issues, if needed ;) If you have any doubts about V4L2, I can help you.
> 
> The given driver is not a patch but a zip of the modified bt8xx directory
> taken from 2.6.18. Their changes do not integrate with existing bttv
> driver, which has been cannibalized as if one would use V4L only with
> their cards. You want a different kernel version, you unzip the driver
> in the new tree, easy.
> 
> These TW6800 chips must somewhat resemble Bt848/878, the given driver
> is based on bttv. Anyway they differ in many points, some are trivial
> changes while other are more substantial. My impression is that the
> design of TW6800 shares some points with the one of Bt848 but it is
> fundamentally a different beast.
> 
> If support to TW6800 has to be provided in the bttv driver, it seem the
> most logical choice at the first glance, the bttv's framework needs to
> be changed accordingly.

Since this is a different chipset, I think that the better is to have a
different driver for it, instead of "abusing" on bttv driver. This driver is
already very big and messy, due to the large amount of different boards
supported, and several board-specific code written directly inside bttv-driver
and bttv-cards.

> For instance, in bttv-gpio.c those few helper function work with
> registers at a different location, everything else is left as the
> original bttv driver. So supposing to provide and additional set of
> functions specific to TW6800 they should be called instead of the
> original generic bttv Bt848 ones ony for TW6800 cards at runtime. A
> new bttv_ops entry, if anything like this exists.
> 
> I have also some thoughts for bttv-risc.c. What is it? It is used
> to generate any RISC op-codes to be downloaded on the board? It seem
> responsible for DMA operations.

Yes, that's the idea. Those chips have a set of risc instructions that needed
to be loaded. Those risc code will command data send, via DMA, to the
motherboard.

bttv, cx88 and cx23885 drivers share the same risc code,
provided by btcx-risc.c. bttv-risc.c has some code that is specific for bttv.
 
> There is the biggest chunk of changes in bttv-driver.c but I still have
> to dig into it.
> 
> Finally, the bttv driver needs a restyle for V4L2, right? So it would
> be a shame to use it to fork the TW6800 support, wouldn't it? Which
> are the plans here?

True. We've recently removed V4L1 code from it, and turned it to use
video_ioctl2, but there are still several V4L1 style coding inside.

If you are willing to write a new driver, I suggest you to use a more modern
driver as a model. I would suggest you to take cx88 as a model.

Cheers,
Mauro

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

Re: TW6800 based video capture boards

[Domenico Andreoli]

On Mon, May 26, 2008 at 12:15:13PM -0300, Mauro Carvalho Chehab wrote:
> 
> > I have also some thoughts for bttv-risc.c. What is it? It is used
> > to generate any RISC op-codes to be downloaded on the board? It seem
> > responsible for DMA operations.
> 
> Yes, that's the idea. Those chips have a set of risc instructions that needed
> to be loaded. Those risc code will command data send, via DMA, to the
> motherboard.

It looks that also TW6800 has this machinery with similar instructions.
I could start an all-private risc file and let see what happens as
time flows.

> bttv, cx88 and cx23885 drivers share the same risc code,
> provided by btcx-risc.c. bttv-risc.c has some code that is specific for bttv.

btcx-risc.c is not modified bby the upstream patch.

> If you are willing to write a new driver, I suggest you to use a more modern
> driver as a model. I would suggest you to take cx88 as a model.

great ;)

ciao,
Domenico

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50

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

Re: TW6800 based video capture boards (updates)

[Vito]

Domenico Andreoli <cavokz <at> gmail.com> writes:

> 
> Hi,
> 
> On Mon, May 26, 2008 at 07:39:59AM -0300, Mauro Carvalho Chehab wrote:
> > On Sun, 25 May 2008 04:00:28 +0200, Domenico Andreoli <cavokz <at>
gmail.com> wrote:
> > >
> > >   I have some shining boards based on Techwell TW6802 and a "working"
> > > V4L2 driver provided by the producer. Ah.. I have also the specs of
> > > those TW6802 chips. Everything has been purchased by my employer.
> > > 
> > > Now I am eager to publish everything but I can't right now. My employer
> > > would not understand and I would be in a difficult position. He already
> > > knows that those drivers are based on GPL software and then _are_ GPL
> > > at all the effects but he still needs to completely understand how it
> > > works. Those guys are always happy to use Linux for free but at the
> > > time of giving anything back...
> > > 
> > > To make the long story short, I want to rewrite them. So, how do
> > > you judge my (legal) position? Yes, you are not a lawyer but I would
> > > appreciate any related advice anyway ;)
> > 
> > I think this will depend if you have a signed NDA or not, and what are their
> > terms. Better to consult a lawyer ;)
> 
> I finally got the clearance few weeks ago :)
> 
> > > Since I am a kernel newbie I am expecting to receive lots of "leave
> > > V4L2 to expert coders..." but I will try anyway. You are warned :)
> > 
> > Just do your work and submit us the code. We'll analyse it and point for
> > issues, if needed ;) If you have any doubts about V4L2, I can help you.
> 
> The new driver, named tw68xx, is able to capture video only.  My wish
> is to make it stable and production ready as soon as possible.
> 
> So at the beginning no audio, no TS, no VBI and no overlay are
> supported. These functionalities would be added with time, boards
> and users.
> 
> I am already collecting people willing to help writing and test stuff :)
> 
> > Please, always c/c v4l ML when submitting your driver[1]. You may also c/c
> > other lists, like LKML. This will allow people to review it.
> 
> I plan to publish it for a first revision by the end of January.
> 
> Currently it is an external module and I would maintain that way until
> it is ready for the merge to the Linus' tree. This way I have not to
> follow a specific tree. Would it be ok for reviewers?
> 
> cheers,
> Domenico
> 
> -----[ Domenico Andreoli, aka cavok
>  --[ http://www.dandreoli.com/gpgkey.asc
>    ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" in
> the body of a message to majordomo <at> vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


Hi all.
I've bought a Provideo 16 in capture PCI-Experess card for my own DVR solution.
http://www.provideo.com.tw/DVRCARD_PV988.htm
This card have 8 TW6805 chip installed.
I've installed the card in a PC with Fedora Core 9 Linux OS
With this kernel.

[root@alinux]# uname -a
Linux apelle 2.6.27.15-78.2.23.fc9.i686 #1 SMP Wed Feb 11 23:53:07 EST 2009 i686
i686 i386 GNU/Linux
The matter is that the kernel don't recognize my card, (see lspci later)

I've compiled successfully the techwell tw6800.ko driver from
http://gitorious.org/tw68 
and inserted it:
[root@alinux]# dmesg
...
tw6800: tw6800 v4l2 driver version 0.0.0 loaded

But however the lspci don't recognize my card:

[root@alinux]# lspci -v
....
04:00.0 Multimedia video controller: JumpTec h, GMBH Unknown device 6804 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 5
	Memory at deefc000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [44] Power Management version 2

04:00.1 Multimedia controller: JumpTec h, GMBH Unknown device 6805 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 5
	Memory at deefc400 (32-bit, non-prefetchable) [size=128]
	Capabilities: [44] Power Management version 2

04:01.0 Multimedia video controller: JumpTec h, GMBH Unknown device 6804 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
	Memory at deefc800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [44] Power Management version 2

04:01.1 Multimedia controller: JumpTec h, GMBH Unknown device 6805 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
	Memory at deefcc00 (32-bit, non-prefetchable) [size=128]
	Capabilities: [44] Power Management version 2

04:02.0 Multimedia video controller: JumpTec h, GMBH Unknown device 6804 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
	Memory at deefd000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [44] Power Management version 2

04:02.1 Multimedia controller: JumpTec h, GMBH Unknown device 6805 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
	Memory at deefd400 (32-bit, non-prefetchable) [size=128]
	Capabilities: [44] Power Management version 2

04:03.0 Multimedia video controller: JumpTec h, GMBH Unknown device 6804 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 15
	Memory at deefd800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [44] Power Management version 2

04:03.1 Multimedia controller: JumpTec h, GMBH Unknown device 6805 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 15
	Memory at deefdc00 (32-bit, non-prefetchable) [size=128]
	Capabilities: [44] Power Management version 2

04:04.0 Multimedia video controller: JumpTec h, GMBH Unknown device 6804 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 5
	Memory at deefe000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [44] Power Management version 2

04:04.1 Multimedia controller: JumpTec h, GMBH Unknown device 6805 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 5
	Memory at deefe400 (32-bit, non-prefetchable) [size=128]
	Capabilities: [44] Power Management version 2

04:05.0 Multimedia video controller: JumpTec h, GMBH Unknown device 6804 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
	Memory at deefe800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [44] Power Management version 2

04:05.1 Multimedia controller: JumpTec h, GMBH Unknown device 6805 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
	Memory at deefec00 (32-bit, non-prefetchable) [size=128]
	Capabilities: [44] Power Management version 2

04:06.0 Multimedia video controller: JumpTec h, GMBH Unknown device 6804 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
	Memory at deeff000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [44] Power Management version 2

04:06.1 Multimedia controller: JumpTec h, GMBH Unknown device 6805 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 11
	Memory at deeff400 (32-bit, non-prefetchable) [size=128]
	Capabilities: [44] Power Management version 2

04:07.0 Multimedia video controller: JumpTec h, GMBH Unknown device 6804 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 15
	Memory at deeff800 (32-bit, non-prefetchable) [size=1K]
	Capabilities: [44] Power Management version 2

04:07.1 Multimedia controller: JumpTec h, GMBH Unknown device 6805 (rev 10)
	Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 15
	Memory at deeffc00 (32-bit, non-prefetchable) [size=128]
	Capabilities: [44] Power Management version 2

There is some possibility that this card can work in some manner?
Can you help me?.
Very very compliments for all your work.
Bye.
Vito.

Re: TW6800 based video capture boards (updates)

[Domenico Andreoli]

On Mon, May 25, 2009 at 1:55 PM, Vito <vcovito@libero.it> wrote:
>
> Hi all.

Hi Vito,

> I've bought a Provideo 16 in capture PCI-Experess card for my own DVR solution.
> http://www.provideo.com.tw/DVRCARD_PV988.htm
> This card have 8 TW6805 chip installed.
> I've installed the card in a PC with Fedora Core 9 Linux OS
> With this kernel.
>
> There is some possibility that this card can work in some manner?

Few days ago I created a repository on gitorious, http://gitorious.org/tw68.
I pushed the clean room driver written by William, mine is not available
for publication. My plan is to dig into it and see what improvements I can
bring. Anybody interested is free to jump onboard.

Currently I am not able to make any statement of usability of the free
one but Willy surely can :)

Best regards,
Domenico Andreoli

-----[ Domenico Andreoli, aka cavok
 --[ http://www.dandreoli.com/gpgkey.asc
   ---[ 3A0F 2F80 F79C 678A 8936  4FEE 0677 9033 A20E BC50