Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 25 4月, 2008 5 次提交
    • M
      V4L/DVB (7368): bttv: added support for Kozumi KTV-01C card · e80faad3
      由 Mauro Lacy 提交于 
      Signed-off-by: NMauro Lacy <mauro@lacy.com.ar>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      e80faad3
    • E
      V4L/DVB (7366): Support for a 16-channel bt878 card · 97275ac5
      由 Ernesto Hernández-Novich 提交于 
      I have what looks like a Geovision GV-600 (or 650) card. It has a large
chip in the middle labeled

CONEXANT
FUSION 878A
25878-13
E345881.1
0312 TAIWAN

It has an audio connector coming out from a chip labeled

ATMEL
0242
AT89C2051-24PI

It is identified as follows on my Debian GNU/Linux Etch (kernel 2.6.18)

...
01:0a.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 11)
01:0a.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 11)
...
01:0a.0 0400: 109e:036e (rev 11)
        Subsystem: 008a:763c
        Flags: bus master, medium devsel, latency 64, IRQ 58
        Memory at dfffe000 (32-bit, prefetchable) [size=4K]
        Capabilities: [44] Vital Product Data
        Capabilities: [4c] Power Management version 2

01:0a.1 0480: 109e:0878 (rev 11)
        Subsystem: 008a:763c
        Flags: bus master, medium devsel, latency 64, IRQ 58
        Memory at dffff000 (32-bit, prefetchable) [size=4K]
        Capabilities: [44] Vital Product Data
        Capabilities: [4c] Power Management version 2

It was being detected as a GENERIC UNKNOWN CARD both by the 2.6.18
kernel and the latest v4l-dvb drivers, but it did not work at all. The
card has sixteen (16) BNC video inputs, four of them on the board itself
and twelve on three daughter-cards. It has a single bt878 chip, no tuner
and what looks like and audio input. After doing some research I managed
to get only eight channels working by forcing card=125 and those DID NOT
match channels 0-7 on the card, and no audio.

Based on what was working for card=125, I added the card definition
block, added a specific muxsel routine and got the card working fully
with xawtv, where the sixteen channels show up as Composite0 to
Composite15, matching the channel labels in the card and daughter-cards.
I have made no efforts yet to get audio working, but would appreciate
any pointers.
Signed-off-by: NErnesto Hernández-Novich <emhn@usb.ve>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      97275ac5
    • W
      V4L/DVB (7294): : tuner and radio addresses are missing for the PixelView PlayTV card · 27dea3eb
      由 Wojciech Migda 提交于 
      The PixelView PlayTV card definition structure was missing initialization of
the tuner_addr and radio_addr fields. As a result it was impossible to have the
tuner initialized using parameters specified while loading the bttv.ko module.

This regression became visible after the v4l rearrangements introduced
somewhere around 2.6.15 kernel version.

The root cause for the tuner initialization failure is located in the
attach_inform function in the bttv-i2c.c file.

There at the very beginning the addr variable holding the tuner device address
is initialized with the value taken from the bttv_tvcards array.

For the PixelView PlayTV card the tuner address field (and the radio address as
well) was uninitialized, and thus equal 0. Later in that function execution of
the TUNER_SET_TYPE_ADDR tuner command is guarded with check for the tuner
address either equal ADDR_UNSET, or client->addr.

Since both are non-zero (the latter in case of the card owned by me at the
runtime is equal 0x61) the TUNER_SET_TYPE_ADDR command is not executed, and
consequently in the tuner_attach function in the tuner-core.c file call to
i2c_attach_client does not result in assigning the tuner type variable with the
requested value.

Providing initialization of the tuner_addr and radio_addr with ADDR_UNSET
values as it is already done for other tv cards defined in bttv-cards.c ensures
that the tuner initialization is done correctly, just as it used to be in the
2.6.14 kernel.
Signed-off-by: NWojciech Migda <wojtek.golf@interia.pl>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      27dea3eb
    • G
      V4L/DVB (7237): Convert videobuf-dma-sg to generic DMA API · 0705135e
      由 Guennadi Liakhovetski 提交于 
      videobuf-dma-sg does not need to depend on PCI. Switch it to using generic
DMA API, convert all affected drivers, relax Kconfig restriction, improve
compile-time type checking, fix some Coding Style violations while at it.
Signed-off-by: NGuennadi Liakhovetski <g.liakhovetski@pengutronix.de>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      0705135e
    • D
      V4L/DVB (7094): static memory · ff699e6b
      由 Douglas Schilling Landgraf 提交于 
      - Static memory is always initialized with 0.
- Replaced in some cases C99 comments for /* */
Signed-off-by: NDouglas Schilling Landgraf <dougsland@gmail.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      ff699e6b
  3. 07 4月, 2008 1 次提交
  5. 02 4月, 2008 4 次提交
  7. 20 3月, 2008 1 次提交
  9. 18 2月, 2008 2 次提交
  11. 03 2月, 2008 1 次提交
  13. 26 1月, 2008 21 次提交
  15. 07 1月, 2008 1 次提交
  17. 12 12月, 2007 2 次提交
  19. 05 11月, 2007 2 次提交
    • T
      V4L/DVB (6392): bttv: Update initial image size when set via V4L1 VIDIOCMCAPTURE · a8ab68bf
      由 Trent Piepho 提交于 
      The V4L1 spec says that the image size should be with with VIDIOCSWIN before
requesting buffers with VIDIOCGMBUF and capturing into them with
VIDIOCMCAPTURE.

But it seems that many apps don't do this.  They set the size using the fields
in the VIDIOCMCAPTURE ioctl.  The driver doesn't know what size to capture
until it actually starts to capture.  In particular, it doesn't know what size
to capture until it has already mmap the captured buffers.  Which is quite
stupid.  Why V4L1 has size and format fields for VIDIOCMCAPTURE I have no idea.

Many drivers don't support this, including those using v4l1-compat.

The bttv does, which is probably the only reason such broken software is so
prevalent.

But, the driver doesn't adjust its idea of what size is being captured when it
is set this way.  If you try to query the driver's current setting with
v4l2-ctl, it won't be correct.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      a8ab68bf
    • T
      V4L/DVB (6391): bttv: SPICT ioctl doesn't work with vlc · 35378434
      由 Trent Piepho 提交于 
      The bttv driver instists that the depth specified in the call to VIDIOCSPICT
match the pixel format specified in the same call.

vlc doesn't set the depth field, which makes the SPICT ioctl always fail.

The V4L1 standard is not clear on how most operation are supposed to work, and
this is no exception.  The depth field would appear to be entirely redundant,
as the pixel format specifies a specific depth.  It could be that this field
was only meant for output from the *G*PICT ioctl and should be ignored in
*S*PICT.  This is in fact what the v4l1-compat wrapper does.
Signed-off-by: NTrent Piepho <xyzzy@speakeasy.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@infradead.org>
      35378434