[GIT PATCHES FOR 2.6.35] Small miscellaneous fixes

2010-03-15 Thread Hans Verkuil
Retry. I accidentally based by tree from linux-2.6.git instead of v4l-dvb.git.
Sorry about that, hopefully this works better.

Hans

The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b:
  Jean Delvare (1):
V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants

are available in the git repository at:

  ssh://linuxtv.org/git/hverkuil/v4l-dvb.git misc-fixes

Hans Verkuil (3):
  videobuf-core: fix spelling mistake in debug message.
  v4l doc: fix font of field name
  v4l2: sort chip IDs in v4l2-chip-ident.h

Michael Hunold (1):
  saa7146: fix up bytesperline if it is an impossible value

 Documentation/DocBook/v4l/vidioc-reqbufs.xml |2 +-
 drivers/media/common/saa7146_video.c |8 +-
 drivers/media/video/videobuf-core.c  |2 +-
 include/media/v4l2-chip-ident.h  |  120 +
 4 files changed, 69 insertions(+), 63 deletions(-)
-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Magic in videobuf

2010-03-15 Thread Pawel Osciak
Hello,

is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
besides driver debugging? I intend to remove them, as we weren't able
to find any particular use for them when we were discussing this at
the memory handling meeting in Norway...


Best regards
--
Pawel Osciak
Linux Platform Group
Samsung Poland RD Center

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[BUGFIX][PATCH] change some parameters for tlg2300

2010-03-15 Thread Huang Shijie
The orgin parameters may cause a bug : The audio may lost in certain
situation (such as open the VLC at the first time).

The origin parameters set a small stop_threshold for snd_pcm_runtime{}.
So a xrun occurs in some situation.

Signed-off-by: Huang Shijie shij...@gmail.com
---
 drivers/media/video/tlg2300/pd-alsa.c |   10 --
 1 files changed, 0 insertions(+), 10 deletions(-)

diff --git a/drivers/media/video/tlg2300/pd-alsa.c 
b/drivers/media/video/tlg2300/pd-alsa.c
index 6f42621..e9ad715 100644
--- a/drivers/media/video/tlg2300/pd-alsa.c
+++ b/drivers/media/video/tlg2300/pd-alsa.c
@@ -21,9 +21,6 @@
 static void complete_handler_audio(struct urb *urb);
 #define AUDIO_EP   (0x83)
 #define AUDIO_BUF_SIZE (512)
-#define PERIOD_SIZE(1024 * 8)
-#define PERIOD_MIN (4)
-#define PERIOD_MAX PERIOD_MIN
 
 static struct snd_pcm_hardware snd_pd_hw_capture = {
.info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
@@ -38,18 +35,11 @@ static struct snd_pcm_hardware snd_pd_hw_capture = {
.rate_max = 48000,
.channels_min = 2,
.channels_max = 2,
-   .buffer_bytes_max = PERIOD_SIZE * PERIOD_MIN,
-   .period_bytes_min = PERIOD_SIZE,
-   .period_bytes_max = PERIOD_SIZE,
-   .periods_min = PERIOD_MIN,
-   .periods_max = PERIOD_MAX,
-   /*
.buffer_bytes_max = 62720 * 8,
.period_bytes_min = 64,
.period_bytes_max = 12544,
.periods_min = 2,
.periods_max = 98
-   */
 };
 
 static int snd_pd_capture_open(struct snd_pcm_substream *substream)
-- 
1.6.6

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [PATCH] V4L: v4l2-subdev driver for AK8813 and AK8814 TV-encoders from AKM

2010-03-15 Thread Guennadi Liakhovetski
On Sun, 14 Mar 2010, Hans Verkuil wrote:

 Review notes below...
 
 On Thursday 11 March 2010 11:25:42 Guennadi Liakhovetski wrote:
  AK8814 only differs from AK8813 by included Macrovision Copy Protection
  function. This patch adds a driver for AK8813 and AK8814 I2C PAL/NTSC TV
  encoders.
  
  Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---

[snip]

  diff --git a/drivers/media/video/ak881x.c b/drivers/media/video/ak881x.c
  new file mode 100644
  index 000..b91f0f6
  --- /dev/null
  +++ b/drivers/media/video/ak881x.c
  @@ -0,0 +1,360 @@
  +/*
  + * Driver for AK8813 / AK8814 TV-ecoders from Asahi Kasei Microsystems 
  Co., Ltd. (AKM)
  + *
  + * Copyright (C) 2010, Guennadi Liakhovetski g.liakhovet...@gmx.de
  + *
  + * This program is free software; you can redistribute it and/or modify
  + * it under the terms of the GNU General Public License version 2 as
  + * published by the Free Software Foundation.
  + */
  +
  +#include linux/i2c.h
  +#include linux/init.h
  +#include linux/platform_device.h
  +#include linux/videodev2.h
  +
  +#include media/ak881x.h
  +#include media/v4l2-chip-ident.h
  +#include media/v4l2-common.h
  +#include media/v4l2-device.h
  +
  +#define AK881X_INTERFACE_MODE  0
  +#define AK881X_VIDEO_PROCESS1  1
  +#define AK881X_VIDEO_PROCESS2  2
  +#define AK881X_VIDEO_PROCESS3  3
  +#define AK881X_DAC_MODE5
  +#define AK881X_STATUS  0x24
  +#define AK881X_DEVICE_ID   0x25
  +#define AK881X_DEVICE_REVISION 0x26
  +
  +struct ak881x {
  +   struct v4l2_subdev subdev;
  +   struct ak881x_pdata *pdata;
  +   int id; /* DEVICE_ID code V4L2_IDENT_AK881X code from v4l2-chip-ident.h 
  */
  +   char revision;  /* DEVICE_REVISION content */
  +};
  +
  +static int reg_read(struct i2c_client *client, const u8 reg)
  +{
  +   return i2c_smbus_read_byte_data(client, reg);
  +}
  +
  +static int reg_write(struct i2c_client *client, const u8 reg,
  +const u8 data)
  +{
  +   return i2c_smbus_write_byte_data(client, reg, data);
  +}
 
 I suggest making these inline.

Disagree. It has been advised on the LKML to _not_ use inline in .c files 
- the compiler decides itself, and it does trivially inline these.

 I also recommend using struct v4l2_subdev instead of struct i2c_client as
 argument. In my experience it makes the code cleaner if the mapping from
 subdev to i2c_client is done at the lowest possible level.

May I disagree with this one too?;) Just for a mere reason, that in this 
specific case, register-access routines should not need anything except the 
i2c-client - by desiign.

  +
  +static int reg_set(struct i2c_client *client, const u8 reg,
  +  const u8 data, u8 mask)
  +{
  +   int ret = reg_read(client, reg);
  +   if (ret  0)
  +   return ret;
  +   return reg_write(client, reg, (ret  ~mask) | (data  mask));
  +}
  +
  +static struct ak881x *to_ak881x(const struct i2c_client *client)
  +{
  +   return container_of(i2c_get_clientdata(client), struct ak881x, subdev);
  +}
 
 Ditto for this one.
 
  +
  +static int ak881x_g_chip_ident(struct v4l2_subdev *sd,
  +   struct v4l2_dbg_chip_ident *id)
  +{
  +   struct i2c_client *client = sd-priv;
 
 Don't use sd-priv directly. Use v4l2_get_subdevdata(sd) instead.

Ok.

  +   struct ak881x *ak881x = to_ak881x(client);
  +
  +   if (id-match.type != V4L2_CHIP_MATCH_I2C_ADDR)
  +   return -EINVAL;
  +
  +   if (id-match.addr != client-addr)
  +   return -ENODEV;
  +
  +   id-ident   = ak881x-id;
  +   id-revision= ak881x-revision;
  +
  +   return 0;
  +}
  +
  +#ifdef CONFIG_VIDEO_ADV_DEBUG
  +static int ak881x_g_register(struct v4l2_subdev *sd,
  + struct v4l2_dbg_register *reg)
  +{
  +   struct i2c_client *client = sd-priv;
  +
  +   if (reg-match.type != V4L2_CHIP_MATCH_I2C_ADDR || reg-reg  0x26)
  +   return -EINVAL;
  +
  +   if (reg-match.addr != client-addr)
  +   return -ENODEV;
  +
  +   reg-val = reg_read(client, reg-reg);
  +
  +   if (reg-val  0x)
  +   return -EIO;
  +
  +   return 0;
  +}
  +
  +static int ak881x_s_register(struct v4l2_subdev *sd,
  + struct v4l2_dbg_register *reg)
  +{
  +   struct i2c_client *client = sd-priv;
  +
  +   if (reg-match.type != V4L2_CHIP_MATCH_I2C_ADDR || reg-reg  0x26)
  +   return -EINVAL;
  +
  +   if (reg-match.addr != client-addr)
  +   return -ENODEV;
  +
  +   if (reg_write(client, reg-reg, reg-val)  0)
  +   return -EIO;
  +
  +   return 0;
  +}
  +#endif
  +
  +static int ak881x_try_g_fmt(struct v4l2_subdev *sd,
  +   struct v4l2_mbus_framefmt *mf)
 
 Can you rename this function to ak881x_try_g_mbus_fmt? Same for the other
 fmt functions.

Well, we (including you) wanted to eventually convert all subdev drivers 
to mediabus, and then to rename *_mbus_fmt to just *_fmt. That's why I 
kept these names without mbus 

Re: [BUGFIX][PATCH] change some parameters for tlg2300

2010-03-15 Thread Huang Shijie
Hi Mauro:
Please ignore this patch.
This patch has side effect : the radio does not run well with this patch.

Best Regards
Huang Shijie.

 The orgin parameters may cause a bug : The audio may lost in certain
 situation (such as open the VLC at the first time).

 The origin parameters set a small stop_threshold for snd_pcm_runtime{}.
 So a xrun occurs in some situation.

 Signed-off-by: Huang Shijie shij...@gmail.com
 ---
  drivers/media/video/tlg2300/pd-alsa.c |   10 --
  1 files changed, 0 insertions(+), 10 deletions(-)

 diff --git a/drivers/media/video/tlg2300/pd-alsa.c 
 b/drivers/media/video/tlg2300/pd-alsa.c
 index 6f42621..e9ad715 100644
 --- a/drivers/media/video/tlg2300/pd-alsa.c
 +++ b/drivers/media/video/tlg2300/pd-alsa.c
 @@ -21,9 +21,6 @@
  static void complete_handler_audio(struct urb *urb);
  #define AUDIO_EP (0x83)
  #define AUDIO_BUF_SIZE   (512)
 -#define PERIOD_SIZE  (1024 * 8)
 -#define PERIOD_MIN   (4)
 -#define PERIOD_MAX   PERIOD_MIN
  
  static struct snd_pcm_hardware snd_pd_hw_capture = {
   .info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
 @@ -38,18 +35,11 @@ static struct snd_pcm_hardware snd_pd_hw_capture = {
   .rate_max = 48000,
   .channels_min = 2,
   .channels_max = 2,
 - .buffer_bytes_max = PERIOD_SIZE * PERIOD_MIN,
 - .period_bytes_min = PERIOD_SIZE,
 - .period_bytes_max = PERIOD_SIZE,
 - .periods_min = PERIOD_MIN,
 - .periods_max = PERIOD_MAX,
 - /*
   .buffer_bytes_max = 62720 * 8,
   .period_bytes_min = 64,
   .period_bytes_max = 12544,
   .periods_min = 2,
   .periods_max = 98
 - */
  };
  
  static int snd_pd_capture_open(struct snd_pcm_substream *substream)
   

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Capturing raw JPEG stream from webcam

2010-03-15 Thread Laurent Pinchart
Hi Basil,

On Saturday 13 March 2010 02:55:47 Basil Mohamed Gohar wrote:
 I originally posted this to the video4linux mailing list, but I've since
 discovered that this is the appropriate place (or so I understand) for
 video4linux questions.  My question is how can I capture the raw JPEG
 image stream (e.g., MJPEG) from my webcam, which reports through v4l2
 that it is capable of.  I am using the gst-launch cli to gstreamer,
 
 which confirms that my webcam has this capability:
  image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
  30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
 
 And, indeed, I can capture using this capability, but the framerate is
 not at the specified rate, but at a much lower value (half or less).
 So, even if I specify 30fps, I get something less.  I can capture the
 full 30fps when I use one of the yuv modes, though, so it's clearly
 capable of delivering that framerate.
 
 My webcam is a Logitech QuickCam Pro 5000.  The lsusb output is:
  046d:08ce Logitech, Inc. QuickCam Pro 5000
 
 An example command line I try is as follows:
  gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
  height=480, framerate=30/1' ! jpegdec ! xvimagesink

Have you tried disabling auto-exposure ? The camera is allowed to reduce the 
frame rate in low-light conditions if auto-exposure is turned on.

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Magic in videobuf

2010-03-15 Thread Mauro Carvalho Chehab
Hi Pawel,

Pawel Osciak wrote:
 Hello,
 
 is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
 besides driver debugging? I intend to remove them, as we weren't able
 to find any particular use for them when we were discussing this at
 the memory handling meeting in Norway...

It is a sort of paranoid check to avoid the risk of mass memory corruption 
if something goes deadly wrong with the video buffers.

The original videobuf, written back in 2001/2002 had this code, and I've
kept it on the redesign I did in 2007, since I know that DMA is very badly
implemented on some chipsets. There are several reports of the video driver
to corrupt the system memory and damaging the disk data when a PCI transfer
to disk happens at the same time that a PCI2PCI data transfer happens (This
basically affects overlay mode, where the hardware is programmed to transfer
data from the video board to the video adapter board).

The DMA bug is present on several VIA and SYS old chipsets. It happened again
in some newer chips (2007?), and the fix were to add a quirk blocking overlay
mode on the reported broken hardware. It seems that newer BIOSes for those
newer hardware fixed this issue.

That's said, I never got any report from anyone explicitly saying that they
hit the MAGIC_CHECK() logic.

I prefer to keep this logic, but maybe we can add a CONFIG option to disable it.
Something like:

#ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK
#define MAGIC_CHECK() ...
#else
#define MAGIC_CHECK()
#endif

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


unsupported device: Lightel Technologies Inc - CI-1000-USB2 Connector Inspector

2010-03-15 Thread Seweryn Niemiec

Hi

In syslog I've found a request to send e-mail with log, so I do it.

http://pastebin.com/g5WtquKY

--
Greetings,
Seweryn
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: cx18: missing audio for analog recordings

2010-03-15 Thread Andy Walls
On Sun, 2010-03-14 at 22:48 -0400, Mark Lord wrote:
 On 03/02/10 07:40, Andy Walls wrote:
  Again, maybe dynamically allocating these work order objects from the
  kernel as needed, would be better from a small dynamically allocated
  pool for each card.  I was concerned that the interrupt handler was
  taking to long at the time I implemented the things the way they are
  now.
 ..
 
 I haven't seen that particular issue again, with or without increasing
 the work orders, so hopefully it won't recur.

OK.


 But after updating to the tip of the v4l2-dvb git tree last week,
 I've been hitting the no audio on analog recordings bug much more often.

Is that tuner audio or baseband (line-in) audio?



 Digging through google, it appears this problem has been around as long
 as the cx18 driver has existed, with no clear resolution.  Lots of people
 have reported it to you before, and nobody has found a silver bullet fix.

Correct.   I thought it was completely gone, but apparently, there just
isn't a lot of reporting of this intermittent problem.


 The problem is still there.
 
 I have now spent a good many hours trying to isolate *when* it happens,
 and have narrowed it down to module initialization.
 
 Basically, if the audio is working after modprobe cx18, it then continues
 to work from recording to recording until the next reboot.

 If the audio is not working after modprobe, then simply doing rmmod/modprobe
 in a loop (until working audio is achieved) is enough to cure it.

Good to know.


 So for my Mythtv box here, I now have a script to check for missing audio
 and do the rmmod/modprobe.  This is a good, effective workaround.
 
 http://rtr.ca/hvr1600/fix_hvr1600_audio.sh
 
 That's a link to my script.
 
 As for the actual underlying cause/bug, it's still not clear what is 
 happening.
 But the problem is a LOT more prevalent (for me, and for two other people I 
 know)
 with versions of the cx18 driver since spring 2009.
 
 My suspicion is that the firmware download for the APU is somehow being 
 corrupted,
 and now that the driver downloads the firmware *twice* during init, it 
 doubles the
 odds of said corruption.  Just a theory, but it's the best fit so far.

Please isolate an APU load and initialization problem, by seeing if
audio fails for both tuner audio and baseband audio.


Here are all the potential problem areas I can think of:

1. A/V digitizer/decoder audio detection firmware load and init.  (I've
added firmware readback verification to try and head this off.)

2. A/V digitizer decoder audio microcontroller hard reset and soft
reset sequencing.  (I think the cx18 driver has this wrong ATM.)

3. APU load and init.  (The double load is to fix a DTV TS stream bug on
every other APU  CPU firmware load sequence.  The APU_AI_RESET is to
fix the audio bitrate problem on first capture after a double firmware
load.)

4. AI1 Mux setting failing when switching between the internal A/V
decoder's I2S output and the external I2S inputs.  (I thought I had this
fixed, but I don't have detailed register specs for that register - so
maybe not.)

5. A/V decoder audio clock PLL stops operating due to being programmed
out of range.  (This was a problem for 32 ksps audio a while ago, but
I'm pretty confident I have it fixed.)

6. A/V decoder analog frontend setup for SIF wrong?.  (I fixed this due
to a problen Helen Buus reported with cable TV.)



I think #2 is the real problem.  I just started to disassmble the
digitizer firmware 2 nights ago to see if I could get some insight as to
how to properly reset it.

I've got a first WAG at fixing the resets of the audio microcontroller's
resets at:

http://linuxtv.org/hg/~awalls/cx18-audio

If it doesn't work, change the CXADEC_AUDIO_SOFT_RESET register define
from 0x810 to 0x9cc, although that may not work either.


 I think we have some nasty i2c issues somewhere in the kernel.

The only I2C connected devices for analog audio are the analog tuner IF
demodulator chip for SIF audio and the CS5345 chip for baseband audio.
Unlike the PVR-150, which has an I2C connected CX25843 A/V decoder, the
CX23418's A/V decoder is integrated and accessed via PCI bus registers.
 
With that said, the CX23418 will sometimes have to let register access
over the PCI bus fail.  For that, I have routines in cx18-io.[ch] to
perform retries.  You may wish to add a log statement there to watch for
retry loops that completely fail. 


Thanks for the troubleshooting and reporting.

Regards,
Andy


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [patch 1/5] drivers/media/video/cx23885 needs kfifo conversion

2010-03-15 Thread Mauro Carvalho Chehab
Hi Andrew,

You can drop this patch. The conversion to the new kfifo API happened on this
patch:

commit 7801edb0b8b66e83c13623b483bc2e846c007c9d
Author: Stefani Seibold stef...@seibold.net
AuthorDate: Mon Dec 21 14:37:33 2009 -0800
Commit: Linus Torvalds torva...@linux-foundation.org
CommitDate: Tue Dec 22 14:17:57 2009 -0800

media video cx23888 driver: ported to new kfifo API

The patch is already upstream.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT FIXES FOR 2.6.34] Fixes for vpfe capture driver

2010-03-15 Thread Mauro Carvalho Chehab
Hi Murali,

Muralidharan Karicheri wrote:
 Mauro,
 
 The following changes since commit 9178a7c062ff0c43e95d826419f9e9454c52ef15:
   Mauro Carvalho Chehab (1):
 V4L/DVB: Fix bad whitespacing

Applied, thanks.

Please, next time base your fixes against fixes.git. 
This make things easier for me.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: dual TT C-1501 on a single PCI riser

2010-03-15 Thread Martin van Es
Hi Daniel,

Thx for your answer. It put me on the right track because I have
finally solved the puzzle!
Here's how:

I did some testing with the IDSEL jumpers and saw the following pattern:

IDSEL   GSI/IRQ reported by kernel.
24  17
25  20
26  no route - 1
27  no route - 1
28  17
29  20
30  no route - 1
31  no device present

But none of these settings resulted in a response to interrupts.
Also I had measured that INTA of slot2 was wired to INTD of the riser
connector, which I thought strange, because I'd expect a forward rotation
for slot2 (AB)?

When I look at the pci layout, pci device 05 is connected to bridge 1e.0:

-[:00]-+-00.0
   +-02.0
   +-02.1
   +-1b.0
   +-1c.0-[01]00.0
   +-1c.1-[02]--
   +-1c.2-[03]--
   +-1c.3-[04]--
   +-1d.0
   +-1d.1
   +-1d.2
   +-1d.3
   +-1d.7
   +-1e.0-[05]--+-00.0  Philips Semiconductors SAA7146
   |\-0c.0  Philips Semiconductors SAA7146
   +-1f.0
   +-1f.1
   +-1f.2
   \-1f.3

Then I wondered if device 05 would still be present if I removed the riser and
it was. So I started to suspect that the motherboard had no way to know what
PCI int's were used behind the bridge if both cards were detected to serve
INTA (i.e. 05.0x = INTA in lspci -v) and would thus (quite stupidly?)
route any int for
this slot to INTA?

So, when I hard-wired the 2nd slot INTA to riser INTA together and used IDSEL 29
I had a succesful initialisation of the DVB card (the other IDSELs didn't work,
even on different PCI INTs), but way too many interrupts on int 20. Then I tried
both cards and that worked as well, but again far too many interrupts
on int 20.
Last change was to cut the original slot2 connection to INTD and gone were my
extra interrupts!

So now I have two correctly recognised cards, both using int 20 and PCI INTA.
Now I wonder if this will harm the performance if both cards are recording
streams, let alone if they work, because that's the next test I still have to
do.

Regards,
Martin van Es

On Sun, Mar 14, 2010 at 22:52, Daniel Glöckner daniel...@gmx.net wrote:
 Hi,

 On Sun, Mar 14, 2010 at 05:14:33PM +0100, Martin van Es wrote:
 ? Pin A11: additional 33 MHz PCI clock
 ? Pin B10: additional PCI request signal (i.e., PREQ#2)
 ? Pin B14: additional PCI Grant signal (i.e., GNT#2)
 -

 I'm 100% sure the Tranquil riser does not support this suggestion
 since the A11/B10 and B14 leads are not used on the riser.

 Your riser card doesn't need these signals thanks to the IT8209R.
 The drawback is that the cards will be granted less bus time when
 competing with on board PCI peripherals.

 On the other hand, my guess would be that an ordinary
 riser with arbiter and the correct wiring should do the trick. My
 question is more or less the same as Udo's in the thread I posted: how
 do I check if int 17 of the second card is correctly connected to int
 A of the second slot and if not, where to start changing things?

 PCI slots have four interrupts, INTA, INTB, INTC, and INTC. Riser cards
 usually permute these for the second and following slots to avoid
 interrupt sharing. The BIOS has a built-in table that tells Linux for
 every slot which pin of the interrupt controller is connected to these
 four interrupt lines. So we need to make the second slot appear to the
 BIOS to be one where INTA is same interrupt as (probably) INTB of the
 first slot.

 Slots are addressed using the IDSEL line. Every slot has its own line.
 To reduce the number of signals (and to allow riser cards) the PCI
 standards suggests reusing the upper AD lines as IDSEL lines for the
 slots. So by changing the AD line connected to the IDSEL line of the
 second slot with the jumper on the riser card, the slot will get another
 number and thus another interrupt mapping.

 According to the ICH7 datasheet you should currently have selected
 AD24, as your card is 08.0 on the bus (strange... at that position
 should have been the intel ethernet controller..). Just subtract
 16 from the AD number to get the slot number. Now try all of them
 until you find one where interrupts work. Avoid those already in
 use on the same bus as listed by lspci -tv.

 Good luck!

  Daniel

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Magic in videobuf

2010-03-15 Thread Hans Verkuil

 Hi Pawel,

 Pawel Osciak wrote:
 Hello,

 is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
 besides driver debugging? I intend to remove them, as we weren't able
 to find any particular use for them when we were discussing this at
 the memory handling meeting in Norway...

 It is a sort of paranoid check to avoid the risk of mass memory corruption
 if something goes deadly wrong with the video buffers.

 The original videobuf, written back in 2001/2002 had this code, and I've
 kept it on the redesign I did in 2007, since I know that DMA is very badly
 implemented on some chipsets. There are several reports of the video
 driver
 to corrupt the system memory and damaging the disk data when a PCI
 transfer
 to disk happens at the same time that a PCI2PCI data transfer happens
 (This
 basically affects overlay mode, where the hardware is programmed to
 transfer
 data from the video board to the video adapter board).

 The DMA bug is present on several VIA and SYS old chipsets. It happened
 again
 in some newer chips (2007?), and the fix were to add a quirk blocking
 overlay
 mode on the reported broken hardware. It seems that newer BIOSes for those
 newer hardware fixed this issue.

 That's said, I never got any report from anyone explicitly saying that
 they
 hit the MAGIC_CHECK() logic.

 I prefer to keep this logic, but maybe we can add a CONFIG option to
 disable it.
 Something like:

 #ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK
   #define MAGIC_CHECK() ...
 #else
   #define MAGIC_CHECK()
 #endif

What on earth does this magic check have to do with possible DMA
overruns/memory corruption? This assumes that somehow exactly these magic
fields are overwritten and that you didn't crash because of memory
corruption elsewhere much earlier. It pollutes the code for no good
reason. All it does is oops anyway, so it really doesn't 'avoid' a crash
(as if you could in such scenarios). And most likely the damage has been
done already in that case.

Please let us get rid of this. It makes no sense whatsoever.

Regards,

   Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] V4L2 file handles and event interface

2010-03-15 Thread Mauro Carvalho Chehab
Hi Sakari,

Sakari Ailus wrote:
 Hi Mauro,
 
 The latest event patchset is available in my Gitorious tree now. The
 file handles documentation patch changed due to unrelated changes in
 Documentation/video4linux/v4l2-framework.txt. There are no other changes
 compared to the patches sent to the list earlier.
 
 Please pull.
 
 The following changes since commit 9178a7c062ff0c43e95d826419f9e9454c52ef15:
   Mauro Carvalho Chehab (1):
 V4L/DVB: Fix bad whitespacing
 
 are available in the git repository at:
 
   git://gitorious.org/omap3camera/mainline.git v4l-dvb-event
 
 Sakari Ailus (6):
   V4L: File handles

The idea of having a common file handle at the V4L2 core is interesting, but
I see some troubles on it. As you said on this changeset's comment:

V4L/DVB: V4L: File handles

This patch adds a list of v4l2_fh structures to every video_device.
It allows using file handle related information in V4L2. The event interface
is one example of such use.

Video device drivers should use the v4l2_fh pointer as their
file-private_data.

You're saying that the drivers should use struct v4l2_fh, but there
aren't any patches on your series enforcing this change.

Also, you're defining it as just:

+struct v4l2_fh {
+ struct list_headlist;
+ struct video_device *vdev;
+};

while other drivers need something much more complex. For example, saa7134
defines the file handler struct used on file-private_data as:

struct saa7134_fh {
struct saa7134_dev *dev;
unsigned int   radio;
enum v4l2_buf_type type;
unsigned int   resources;
enum v4l2_priority prio;

/* video overlay */
struct v4l2_window win;
struct v4l2_clip   clips[8];
unsigned int   nclips;

/* video capture */
struct saa7134_format  *fmt;
unsigned int   width,height;
struct videobuf_queue  cap;
struct saa7134_pgtable pt_cap;

/* vbi capture */
struct videobuf_queue  vbi;
struct saa7134_pgtable pt_vbi;
};

Even the simplest driver we have (vivi) require more than just
the video device:

struct vivi_fh {
struct vivi_dev*dev;

/* video capture */
struct vivi_fmt*fmt;
unsigned int   width, height;
struct videobuf_queue  vb_vidq;

enum v4l2_buf_type type;
unsigned char  bars[8][3];
intinput;   /* Input Number on bars */
};


So, it is not clear for me how to convert any of the existing
drivers to fit on your proposal.

Also, the better is if you could provide us a patchset with the needed
conversion. It is interesting if you could add some notes there about why
this change is needed.

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] V4L2 file handles and event interface

2010-03-15 Thread Hans Verkuil
Hi Mauro,

 Hi Sakari,

 Sakari Ailus wrote:
 Hi Mauro,

 The latest event patchset is available in my Gitorious tree now. The
 file handles documentation patch changed due to unrelated changes in
 Documentation/video4linux/v4l2-framework.txt. There are no other changes
 compared to the patches sent to the list earlier.

 Please pull.

 The following changes since commit
 9178a7c062ff0c43e95d826419f9e9454c52ef15:
   Mauro Carvalho Chehab (1):
 V4L/DVB: Fix bad whitespacing

 are available in the git repository at:

   git://gitorious.org/omap3camera/mainline.git v4l-dvb-event

 Sakari Ailus (6):
   V4L: File handles

 The idea of having a common file handle at the V4L2 core is interesting,
 but
 I see some troubles on it. As you said on this changeset's comment:

 V4L/DVB: V4L: File handles

 This patch adds a list of v4l2_fh structures to every video_device.
 It allows using file handle related information in V4L2. The event
 interface
 is one example of such use.

 Video device drivers should use the v4l2_fh pointer as their
 file-private_data.

 You're saying that the drivers should use struct v4l2_fh, but there
 aren't any patches on your series enforcing this change.

I guess that was an unfortunate phrase in the comment. It should have
been: 'If drivers need the events interface, then they should use
v4l2_fh.'

So this is not required for all drivers. Although it is my intention to
move into that direction, but that will take much more time.


 Also, you're defining it as just:

 +struct v4l2_fh {
 + struct list_headlist;
 + struct video_device *vdev;
 +};

 while other drivers need something much more complex. For example, saa7134
 defines the file handler struct used on file-private_data as:

 struct saa7134_fh {
 struct saa7134_dev *dev;
 unsigned int   radio;
 enum v4l2_buf_type type;
 unsigned int   resources;
 enum v4l2_priority prio;

 /* video overlay */
 struct v4l2_window win;
 struct v4l2_clip   clips[8];
 unsigned int   nclips;

 /* video capture */
 struct saa7134_format  *fmt;
 unsigned int   width,height;
 struct videobuf_queue  cap;
 struct saa7134_pgtable pt_cap;

 /* vbi capture */
 struct videobuf_queue  vbi;
 struct saa7134_pgtable pt_vbi;
 };

 Even the simplest driver we have (vivi) require more than just
 the video device:

 struct vivi_fh {
 struct vivi_dev*dev;

 /* video capture */
 struct vivi_fmt*fmt;
 unsigned int   width, height;
 struct videobuf_queue  vb_vidq;

 enum v4l2_buf_type type;
 unsigned char  bars[8][3];
 intinput;   /* Input Number on bars */
 };


 So, it is not clear for me how to convert any of the existing
 drivers to fit on your proposal.

Drivers will still have their own fh structure, but it embed the v4l2_fh
struct. Just as is done with e.g. struct v4l2_subdev or struct v4l2_device
(or pretty much everywhere in the kernel these days).


 Also, the better is if you could provide us a patchset with the needed
 conversion. It is interesting if you could add some notes there about why
 this change is needed.

I plan on converting ivtv to this (ivtv already has events using the
poorly defined dvb/video.h events interface). But it looks like that will
take two weeks before I get the time. Although if this would block you
from merging this patch series, then I can try to get it done earlier.

Regards,

   Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] V4L2 file handles and event interface

2010-03-15 Thread Sakari Ailus
Mauro Carvalho Chehab wrote:
 Hi Sakari,

Hi Mauro,

...
 The idea of having a common file handle at the V4L2 core is interesting, but
 I see some troubles on it. As you said on this changeset's comment:
 
 V4L/DVB: V4L: File handles
 
 This patch adds a list of v4l2_fh structures to every video_device.
 It allows using file handle related information in V4L2. The event 
 interface
 is one example of such use.
 
 Video device drivers should use the v4l2_fh pointer as their
 file-private_data.
 
 You're saying that the drivers should use struct v4l2_fh, but there
 aren't any patches on your series enforcing this change.

Oh, there should be an if there. It is described better in
Documentation/video4linux/v4l2-framework.txt .

 Also, you're defining it as just:
 
 +struct v4l2_fh {
 + struct list_headlist;
 + struct video_device *vdev;
 +};
 
 while other drivers need something much more complex. For example, saa7134
 defines the file handler struct used on file-private_data as:
 
 struct saa7134_fh {
 struct saa7134_dev *dev;
 unsigned int   radio;
 enum v4l2_buf_type type;
 unsigned int   resources;
 enum v4l2_priority prio;
 
 /* video overlay */
 struct v4l2_window win;
 struct v4l2_clip   clips[8];
 unsigned int   nclips;
 
 /* video capture */
 struct saa7134_format  *fmt;
 unsigned int   width,height;
 struct videobuf_queue  cap;
 struct saa7134_pgtable pt_cap;
 
 /* vbi capture */
 struct videobuf_queue  vbi;
 struct saa7134_pgtable pt_vbi;
 };
 
 Even the simplest driver we have (vivi) require more than just
 the video device:
 
 struct vivi_fh {
 struct vivi_dev*dev;
 
 /* video capture */
 struct vivi_fmt*fmt;
 unsigned int   width, height;
 struct videobuf_queue  vb_vidq;
 
 enum v4l2_buf_type type;
 unsigned char  bars[8][3];
 intinput;   /* Input Number on bars */
 };
 
 
 So, it is not clear for me how to convert any of the existing
 drivers to fit on your proposal.

The struct v4l2_fh is meant to be a part of the driver's own file handle
structure. It does not attempt to offer drivers anything directly but
generic functionality that depends on file handle specific data such as
V4L2 events. E.g.

struct my_video_fh {
blah;
struct v4l2_fh fh;
blah;
};

 Also, the better is if you could provide us a patchset with the needed
 conversion. It is interesting if you could add some notes there about why
 this change is needed.

There is no need to change any existing drivers, this change does not
affect them. V4L2 file handles are only for those drivers that want to
use them. Other drivers can safely ignore this. But if a driver wants to
use V4L2 events it also has to use V4L2 file handles since event
information is stored in V4L2 file handles.

Cheers,

-- 
Sakari Ailus
sakari.ai...@maxwell.research.nokia.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: dual TT C-1501 on a single PCI riser

2010-03-15 Thread Daniel Glöckner
On 03/15/2010 01:50 PM, Martin van Es wrote:
 When I look at the pci layout, pci device 05 is connected to bridge 1e.0:

 -[:00]-+-00.0
+-1e.0-[05]--+-00.0  Philips Semiconductors SAA7146
|\-0c.0  Philips Semiconductors SAA7146

No, this means bridge 1e.0 connects to bus number 05.

 So I started to suspect that the motherboard had no way to know what
 PCI int's were used behind the bridge if both cards were detected to serve
 INTA (i.e. 05.0x = INTA in lspci -v) and would thus (quite stupidly?)
 route any int for this slot to INTA?

I don't get that sentence..
Every slot has INTA/B/C/D and each PCI function announces which one of these it
uses. In most cases INTA is used. The board manufacturer for bus 05 only knows
how INTx maps to APIC inputs for slot 00. He knows there are people who use
riser cards, so he adds mappings for non-existent slots by permuting those
interrupts available to slot 00.

 Last change was to cut the original slot2 connection to INTD and gone were my
 extra interrupts!

It might be INTD isn't connected to the APIC. It is rarely used on cards.

 So now I have two correctly recognised cards, both using int 20 and PCI INTA.
 Now I wonder if this will harm the performance if both cards are recording
 streams, let alone if they work, because that's the next test I still have to
 do.

It should work. On interrupt the driver will be called once for each card to
check if the card in question caused the interrupt. As long as we are not
talking about thousands of interrupts per second, this shouldn't harm 
performance.

  Daniel


-- 
Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com
Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany
Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160
Geschäftsführer: Dr. Uwe Kracke, Ust-IdNr.: DE 205 198 055

emlix - your embedded linux partner
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Capturing raw JPEG stream from webcam

2010-03-15 Thread Basil Mohamed Gohar
On 03/15/2010 05:40 AM, Laurent Pinchart wrote:
 Hi Basil,
   
Hi Laurent!
 On Saturday 13 March 2010 02:55:47 Basil Mohamed Gohar wrote:
   
 I originally posted this to the video4linux mailing list, but I've since
 discovered that this is the appropriate place (or so I understand) for
 video4linux questions.  My question is how can I capture the raw JPEG
 image stream (e.g., MJPEG) from my webcam, which reports through v4l2
 that it is capable of.  I am using the gst-launch cli to gstreamer,

 which confirms that my webcam has this capability:
 
 image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
 30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
   
 And, indeed, I can capture using this capability, but the framerate is
 not at the specified rate, but at a much lower value (half or less).
 So, even if I specify 30fps, I get something less.  I can capture the
 full 30fps when I use one of the yuv modes, though, so it's clearly
 capable of delivering that framerate.

 My webcam is a Logitech QuickCam Pro 5000.  The lsusb output is:
 
 046d:08ce Logitech, Inc. QuickCam Pro 5000
   
 An example command line I try is as follows:
 
 gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
 height=480, framerate=30/1' ! jpegdec ! xvimagesink
   
 Have you tried disabling auto-exposure ? The camera is allowed to reduce the 
 frame rate in low-light conditions if auto-exposure is turned on.

   
Thanks for replying.  I haven't actually tried this yet (I am currently
at work), but I do not think this is the issue, because when I choose
the YUV-style modes, I can capture at the full framerates.  It's only
when I select the image/jpeg mode that I get the lower framerates,
despite explicitly requesting the higher ones.

I suppose it's not impossible that the camera is opting for different
behavior depending on the mode of the request, but I think that is not
likely the case.  I do appreciate the suggestion, though, and I'll try
it when I get home.

Meanwhile, does anyone else have any other ideas?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] V4L2 file handles and event interface

2010-03-15 Thread Mauro Carvalho Chehab
Sakari Ailus wrote:
 Mauro Carvalho Chehab wrote:
 Hi Sakari,
 
 Hi Mauro,
 
 ...
 The idea of having a common file handle at the V4L2 core is interesting, but
 I see some troubles on it. As you said on this changeset's comment:

 V4L/DVB: V4L: File handles
 
 This patch adds a list of v4l2_fh structures to every video_device.
 It allows using file handle related information in V4L2. The event 
 interface
 is one example of such use.
 
 Video device drivers should use the v4l2_fh pointer as their
 file-private_data.

 You're saying that the drivers should use struct v4l2_fh, but there
 aren't any patches on your series enforcing this change.
 
 Oh, there should be an if there. It is described better in
 Documentation/video4linux/v4l2-framework.txt .

Even there, it is not clear that this is an optional interface. Also, as I am
understanding, you'll likely add other things there, so the better would be
to add some notes at the header files that implement those functions, stating
when and how they should be used.
 
 Also, you're defining it as just:

 +struct v4l2_fh {
 + struct list_headlist;
 + struct video_device *vdev;
 +};

 while other drivers need something much more complex. For example, saa7134
 defines the file handler struct used on file-private_data as:

 struct saa7134_fh {
 struct saa7134_dev *dev;
 unsigned int   radio;
 enum v4l2_buf_type type;
 unsigned int   resources;
 enum v4l2_priority prio;

 /* video overlay */
 struct v4l2_window win;
 struct v4l2_clip   clips[8];
 unsigned int   nclips;

 /* video capture */
 struct saa7134_format  *fmt;
 unsigned int   width,height;
 struct videobuf_queue  cap;
 struct saa7134_pgtable pt_cap;

 /* vbi capture */
 struct videobuf_queue  vbi;
 struct saa7134_pgtable pt_vbi;
 };

 Even the simplest driver we have (vivi) require more than just
 the video device:

 struct vivi_fh {
 struct vivi_dev*dev;

 /* video capture */
 struct vivi_fmt*fmt;
 unsigned int   width, height;
 struct videobuf_queue  vb_vidq;

 enum v4l2_buf_type type;
 unsigned char  bars[8][3];
 intinput;   /* Input Number on bars */
 };


 So, it is not clear for me how to convert any of the existing
 drivers to fit on your proposal.
 
 The struct v4l2_fh is meant to be a part of the driver's own file handle
 structure. It does not attempt to offer drivers anything directly but
 generic functionality that depends on file handle specific data such as
 V4L2 events. E.g.
 
 struct my_video_fh {
   blah;
   struct v4l2_fh fh;
   blah;
 };
 
 Also, the better is if you could provide us a patchset with the needed
 conversion. It is interesting if you could add some notes there about why
 this change is needed.
 
 There is no need to change any existing drivers, this change does not
 affect them. V4L2 file handles are only for those drivers that want to
 use them. Other drivers can safely ignore this. But if a driver wants to
 use V4L2 events it also has to use V4L2 file handles since event
 information is stored in V4L2 file handles.

It is always a good idea to add at least one use case when a new API is
added on kernel. So, I prefer if you could send those changes together
with some use case. Hans is planning to use on ivtv (as his email on
this thread). Also Guennadi said me once, at irc, that he has also something
ready or almost ready just waiting for this merge. So, it would be really
nice if you can send either one of the implementations together with the
patch series. This helps to better understand about the usecases. 
 
 Cheers,
 


-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Magic in videobuf

2010-03-15 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 Hi Pawel,

 Pawel Osciak wrote:
 Hello,

 is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
 besides driver debugging? I intend to remove them, as we weren't able
 to find any particular use for them when we were discussing this at
 the memory handling meeting in Norway...
 It is a sort of paranoid check to avoid the risk of mass memory corruption
 if something goes deadly wrong with the video buffers.

 The original videobuf, written back in 2001/2002 had this code, and I've
 kept it on the redesign I did in 2007, since I know that DMA is very badly
 implemented on some chipsets. There are several reports of the video
 driver
 to corrupt the system memory and damaging the disk data when a PCI
 transfer
 to disk happens at the same time that a PCI2PCI data transfer happens
 (This
 basically affects overlay mode, where the hardware is programmed to
 transfer
 data from the video board to the video adapter board).

 The DMA bug is present on several VIA and SYS old chipsets. It happened
 again
 in some newer chips (2007?), and the fix were to add a quirk blocking
 overlay
 mode on the reported broken hardware. It seems that newer BIOSes for those
 newer hardware fixed this issue.

 That's said, I never got any report from anyone explicitly saying that
 they
 hit the MAGIC_CHECK() logic.

 I prefer to keep this logic, but maybe we can add a CONFIG option to
 disable it.
 Something like:

 #ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK
  #define MAGIC_CHECK() ...
 #else
  #define MAGIC_CHECK()
 #endif
 
 What on earth does this magic check have to do with possible DMA
 overruns/memory corruption? This assumes that somehow exactly these magic
 fields are overwritten and that you didn't crash because of memory
 corruption elsewhere much earlier. 

Yes, that's the assumption. As, in general, there are more than one videobuffer,
and assuming that one buffer physical address is close to the other, if the data
got miss-aligned at the DMA, it is likely that the magic number of the next 
buffer
will be overwritten if something got bad. The real situation will depend on how 
fragmented is the memory.

 It pollutes the code

There are only 18 occurences of MAGIC* at a given videobuf driver:
$ grep MAGIC ~v4l/master_hg/v4l/videobuf-dma-sg.c |wc -l
18

So, I don't think it is too much pollution.

 for no good
 reason. All it does is oops anyway, so it really doesn't 'avoid' a crash
 (as if you could in such scenarios). And most likely the damage has been
 done already in that case.

It won't avoid the damage, but the error message could potentially help
to track the issue. It will also likely limit the damage.

 Please let us get rid of this. It makes no sense whatsoever.

I don't have a strong opinion about this subject, but if this code might help
to avoid propagating the damage and to track the issue, I don't see why we
need to remove it, especially since it is easy to disable the entire logic
by just adding a few #if's to remove this code on environments where no
problem is expected.

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] V4L2 file handles and event interface

2010-03-15 Thread Mauro Carvalho Chehab
Mauro Carvalho Chehab wrote:
 Video device drivers should use the v4l2_fh pointer as their
 file-private_data.

...

 The struct v4l2_fh is meant to be a part of the driver's own file handle
 structure. It does not attempt to offer drivers anything directly but
 generic functionality that depends on file handle specific data such as
 V4L2 events. E.g.

 struct my_video_fh {
  blah;
  struct v4l2_fh fh;
  blah;
 };

An additional comment about this: 

On your comment, you said that Video device drivers should use the v4l2_fh 
pointer as their file-private_data..
This can be understood as:
file-private_data = v4l2_fh;

But a driver following your example, should do, instead:
file-private_data = my_video_fh;

Please, be sure that you document it clearly when you submit it again.

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Magic in videobuf

2010-03-15 Thread Hans Verkuil

 Hans Verkuil wrote:
 Hi Pawel,

 Pawel Osciak wrote:
 Hello,

 is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
 besides driver debugging? I intend to remove them, as we weren't able
 to find any particular use for them when we were discussing this at
 the memory handling meeting in Norway...
 It is a sort of paranoid check to avoid the risk of mass memory
 corruption
 if something goes deadly wrong with the video buffers.

 The original videobuf, written back in 2001/2002 had this code, and
 I've
 kept it on the redesign I did in 2007, since I know that DMA is very
 badly
 implemented on some chipsets. There are several reports of the video
 driver
 to corrupt the system memory and damaging the disk data when a PCI
 transfer
 to disk happens at the same time that a PCI2PCI data transfer happens
 (This
 basically affects overlay mode, where the hardware is programmed to
 transfer
 data from the video board to the video adapter board).

 The DMA bug is present on several VIA and SYS old chipsets. It happened
 again
 in some newer chips (2007?), and the fix were to add a quirk blocking
 overlay
 mode on the reported broken hardware. It seems that newer BIOSes for
 those
 newer hardware fixed this issue.

 That's said, I never got any report from anyone explicitly saying that
 they
 hit the MAGIC_CHECK() logic.

 I prefer to keep this logic, but maybe we can add a CONFIG option to
 disable it.
 Something like:

 #ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK
 #define MAGIC_CHECK() ...
 #else
 #define MAGIC_CHECK()
 #endif

 What on earth does this magic check have to do with possible DMA
 overruns/memory corruption? This assumes that somehow exactly these
 magic
 fields are overwritten and that you didn't crash because of memory
 corruption elsewhere much earlier.

 Yes, that's the assumption. As, in general, there are more than one
 videobuffer,
 and assuming that one buffer physical address is close to the other, if
 the data
 got miss-aligned at the DMA, it is likely that the magic number of the
 next buffer
 will be overwritten if something got bad. The real situation will depend
 on how
 fragmented is the memory.

For the record: we are talking about the magic fields as found in
include/media/videobuf*.h. None of the magic field there are actually in
the video buffers. They are in administrative structures or in ops structs
which are unlikely to be close in memory to the actual buffers.

Magic values that are actually put in the buffers themselves might serve
some purpose.


 It pollutes the code

 There are only 18 occurences of MAGIC* at a given videobuf driver:
   $ grep MAGIC ~v4l/master_hg/v4l/videobuf-dma-sg.c |wc -l
   18

 So, I don't think it is too much pollution.

It is, because it is absolute not clear what its purpose is, and in this
case  even when I know the purpose it still makes no sense. Code like that
confuses people and does more harm than good.


 for no good
 reason. All it does is oops anyway, so it really doesn't 'avoid' a crash
 (as if you could in such scenarios). And most likely the damage has been
 done already in that case.

 It won't avoid the damage, but the error message could potentially help
 to track the issue. It will also likely limit the damage.

 Please let us get rid of this. It makes no sense whatsoever.

 I don't have a strong opinion about this subject, but if this code might
 help
 to avoid propagating the damage and to track the issue, I don't see why we
 need to remove it, especially since it is easy to disable the entire logic
 by just adding a few #if's to remove this code on environments where no
 problem is expected.

It is highly unlikely that this code ever prevented these issues.
Especially given the places where the check is done. I think this is just
debug code that has been dragged along for all these years without anyone
bothering to remove it.

Regards,

 Hans

-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [GIT PULL] V4L2 file handles and event interface

2010-03-15 Thread Hans Verkuil

 Mauro Carvalho Chehab wrote:
 Video device drivers should use the v4l2_fh pointer as their
 file-private_data.

 ...

 The struct v4l2_fh is meant to be a part of the driver's own file
 handle
 structure. It does not attempt to offer drivers anything directly but
 generic functionality that depends on file handle specific data such as
 V4L2 events. E.g.

 struct my_video_fh {
 blah;
 struct v4l2_fh fh;
 blah;
 };

 An additional comment about this:

 On your comment, you said that Video device drivers should use the
 v4l2_fh
 pointer as their file-private_data..
 This can be understood as:
   file-private_data = v4l2_fh;

 But a driver following your example, should do, instead:
   file-private_data = my_video_fh;

No, it should do:

file-private_data = my_video_fh.fh;

Then later you can use to_container to get back to my_video_fh.

But it is true that a short example might clarify things.

Regards,

   Hans


 Please, be sure that you document it clearly when you submit it again.

 --

 Cheers,
 Mauro
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Magic in videobuf

2010-03-15 Thread Mauro Carvalho Chehab
Hans Verkuil wrote:
 Hans Verkuil wrote:
 Hi Pawel,

 Pawel Osciak wrote:
 Hello,

 is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
 besides driver debugging? I intend to remove them, as we weren't able
 to find any particular use for them when we were discussing this at
 the memory handling meeting in Norway...
 It is a sort of paranoid check to avoid the risk of mass memory
 corruption
 if something goes deadly wrong with the video buffers.

 The original videobuf, written back in 2001/2002 had this code, and
 I've
 kept it on the redesign I did in 2007, since I know that DMA is very
 badly
 implemented on some chipsets. There are several reports of the video
 driver
 to corrupt the system memory and damaging the disk data when a PCI
 transfer
 to disk happens at the same time that a PCI2PCI data transfer happens
 (This
 basically affects overlay mode, where the hardware is programmed to
 transfer
 data from the video board to the video adapter board).

 The DMA bug is present on several VIA and SYS old chipsets. It happened
 again
 in some newer chips (2007?), and the fix were to add a quirk blocking
 overlay
 mode on the reported broken hardware. It seems that newer BIOSes for
 those
 newer hardware fixed this issue.

 That's said, I never got any report from anyone explicitly saying that
 they
 hit the MAGIC_CHECK() logic.

 I prefer to keep this logic, but maybe we can add a CONFIG option to
 disable it.
 Something like:

 #ifdef CONFIG_VIDEO_DMA_PARANOID_CHECK
#define MAGIC_CHECK() ...
 #else
#define MAGIC_CHECK()
 #endif
 What on earth does this magic check have to do with possible DMA
 overruns/memory corruption? This assumes that somehow exactly these
 magic
 fields are overwritten and that you didn't crash because of memory
 corruption elsewhere much earlier.
 Yes, that's the assumption. As, in general, there are more than one
 videobuffer,
 and assuming that one buffer physical address is close to the other, if
 the data
 got miss-aligned at the DMA, it is likely that the magic number of the
 next buffer
 will be overwritten if something got bad. The real situation will depend
 on how
 fragmented is the memory.
 
 For the record: we are talking about the magic fields as found in
 include/media/videobuf*.h. None of the magic field there are actually in
 the video buffers. They are in administrative structures or in ops structs
 which are unlikely to be close in memory to the actual buffers.

Well, Pawel's email didn't mentioned that he is referring just to one type
of magic check.


 Magic values that are actually put in the buffers themselves might serve
 some purpose.
 
 It pollutes the code
 There are only 18 occurences of MAGIC* at a given videobuf driver:
  $ grep MAGIC ~v4l/master_hg/v4l/videobuf-dma-sg.c |wc -l
  18

 So, I don't think it is too much pollution.
 
 It is, because it is absolute not clear what its purpose is, and in this
 case  even when I know the purpose it still makes no sense. Code like that
 confuses people and does more harm than good.
 
 for no good
 reason. All it does is oops anyway, so it really doesn't 'avoid' a crash
 (as if you could in such scenarios). And most likely the damage has been
 done already in that case.
 It won't avoid the damage, but the error message could potentially help
 to track the issue. It will also likely limit the damage.

 Please let us get rid of this. It makes no sense whatsoever.
 I don't have a strong opinion about this subject, but if this code might
 help
 to avoid propagating the damage and to track the issue, I don't see why we
 need to remove it, especially since it is easy to disable the entire logic
 by just adding a few #if's to remove this code on environments where no
 problem is expected.
 
 It is highly unlikely that this code ever prevented these issues.
 Especially given the places where the check is done. I think this is just
 debug code that has been dragged along for all these years without anyone
 bothering to remove it.

I remember that when I did the conversion, the memory magic helped a lot to find
several issues. So, yes, they are very useful when debug troubles at videbuf.

I remember I had to re-format one disk, during that time, due to a videobuf 
issue.
So, those checks help people that are touching at the videobuf code, reducing 
the 
chances of damaging their disk partitions when trying to implement overlay mode 
and
userptr on the videobuf implementations that misses those features, or when
working on a different mmap() logic at the driver.

They also helped me with some troubles related to compat32 stuff and troubles 
at 
mmap() logic on the driver, as the videobuf magic hits when the data segment 
is pointing to the wrong place. This may also help to find bugs with troubles 
with
the memory allocators.

By looking only at the adm struct magic, I don't see any problem on getting rid
of them.

-- 

Cheers,
Mauro
--
To unsubscribe from this list: send the line 

Plextor ConvertX AV100U

2010-03-15 Thread Don Kramer
Hi I'm Don, I'm new here.  I would like to see if it's possible to get the 
Plextor ConvertX  AV100U to work under Linux, I own this device, and currently 
can use it only under Windows XP.  I believe it is very similar to the Plextor 
ConvertX PX-TV100U which is listed as a device added to kernel but not tested 
(Em28xx).  I believe the AV100U and TV100U both lack hardware encoders (I know 
the AV100U doesn't have it), unlike the Plextor TV-402U with does have hardware 
encoding.   Anyway, I'm able to help out with testing and possibly some 
additional technical tasks as well (with some guidance) of getting this 
accomplished (assuming this is technically feasible in the first place).

In a terminal, lsusb shows the device as this:

Bus 001 Device 003: ID 093b:a003 Plextor Corp. ConvertX AV100U A/V Capture Audio

Thanks,

Don


  
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: [Spca50x-devs] 17a1:0118

2010-03-15 Thread Jean-Francois Moine
On Mon, 15 Mar 2010 19:24:24 +0200
Shahar Or em...@shahar-or.co.il wrote:

 I have a non-supported one, with the ID 17a1:0118. Data attached.
 
 I am willing to cooperate with anything that I can, including testing
 patches.
 
 I've noticed there's one here related:
 http://lists-archives.org/spca50x-devs/01649-patch-for-17a1-0128-xpx-jpeg-webcam-tascorp.html
 
 I can also send the cam over by mail, if that is necessary.
 
 I'm subscribed to the list.

Hello Shahar,

A driver for this webcam is available (you may find it in the last
gspca version that I have just uploaded - 2.9.6 - the subdriver is
'gspca_tasc.ko').

The only problem is that nobody could yet decode the images! (Jens,
Jean-Yves, any news?)

About the list, all the linux video stuff is hosted at LinuxTv.org and
the linux-media mailing-list at vger.kernel.org (see Cc:).

Best regards.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PATCHES FOR 2.6.34] gspca development

2010-03-15 Thread Jean-Francois Moine
Hi Mauro,

The following changes since commit
942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1):
V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135
variants

are available in the git repository at:

  git://linuxtv.org/jfrancois/gspca.git for_2.6.34

Erik Andrén (1):
  gspca - stv06xx: Remove the 046d:08da from the stv06xx driver.

Yong Zhang (1):
  gspca - sn9c20x: Correct onstack wait_queue_head declaration.

 drivers/media/video/gspca/sn9c20x.c |2 +-
 drivers/media/video/gspca/stv06xx/stv06xx.c |2 --
 2 files changed, 1 insertions(+), 3 deletions(-)

Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PATCHES FOR 2.6.34] gspca development

2010-03-15 Thread Jean-Francois Moine
Hi Mauro,

The following changes since commit 942ab4762505a51a7a433a7608ba5d3eed6e4f8b:
  Jean Delvare (1):
V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135 variants

are available in the git repository at:

  git://linuxtv.org/jfrancois/gspca.git for_2.6.35

Olivier Lorin (2):
  gspca - gl860: Updates to prepare the new driver for MI2020 sensor.
  gspca - gl860: New driver for MI2020 sensor.

 drivers/media/video/gspca/gl860/gl860-mi1320.c |1 +
 drivers/media/video/gspca/gl860/gl860-mi2020.c |  731 +---
 drivers/media/video/gspca/gl860/gl860-ov2640.c |1 +
 drivers/media/video/gspca/gl860/gl860-ov9655.c |5 +-
 drivers/media/video/gspca/gl860/gl860.c|   52 +--
 drivers/media/video/gspca/gl860/gl860.h|6 +-
 6 files changed, 288 insertions(+), 508 deletions(-)

Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[GIT PATCHES FOR 2.6.35] gspca development

2010-03-15 Thread Jean-Francois Moine
Hi Mauro,

Sorry, the last pull request for 2.6.35.

The following changes since commit
942ab4762505a51a7a433a7608ba5d3eed6e4f8b: Jean Delvare (1):
V4L/DVB: saa7134: Fix IR support of some ASUS TV-FM 7135
variants

are available in the git repository at:

  git://linuxtv.org/jfrancois/gspca.git for_2.6.35

Olivier Lorin (2):
  gspca - gl860: Updates to prepare the new driver for MI2020
sensor. gspca - gl860: New driver for MI2020 sensor.

 drivers/media/video/gspca/gl860/gl860-mi1320.c |1 +
 drivers/media/video/gspca/gl860/gl860-mi2020.c |  731
 +---
 drivers/media/video/gspca/gl860/gl860-ov2640.c |1 +
 drivers/media/video/gspca/gl860/gl860-ov9655.c |5 +-
 drivers/media/video/gspca/gl860/gl860.c|   52 +--
 drivers/media/video/gspca/gl860/gl860.h|6 +- 6 files
 changed, 288 insertions(+), 508 deletions(-)

Thanks.

-- 
Ken ar c'hentañ | ** Breizh ha Linux atav! **
Jef |   http://moinejf.free.fr/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Excessive rc polling interval in dvb_usb_dib0700 causes interference with USB soundcard

2010-03-15 Thread Pedro Ribeiro
On 15 March 2010 03:55, Devin Heitmueller dheitmuel...@kernellabs.com wrote:
 On Sun, Mar 14, 2010 at 11:06 AM, Pedro Ribeiro ped...@gmail.com wrote:
 Hi Devin,

 after some through investigation I found that your patch solves the
 continuous interference.

 However, I have a second problem. It is also interference but appears
 to be quite random, by which I mean it is not at a fixed interval,
 sometimes it happens past 10 seconds, other times past 30 seconds,
 other times 2 to 5 seconds.

 One thing is sure - it only happens when I'm actually streaming from
 the DVB adapter. If I just plug it in, there is no interference. But
 when I start vdr (for example) the interference starts.

 The DVB adapter and the sound card are not sharing irq's or anything
 like that, and there is no system freeze when the interference
 happens. I also thought it was either my docking bay or power supply,
 but definitely it isn't.

 Any idea what can this be?

 Thank you for your help,
 Pedro

 Hello Pedro,

 Could you describe in more detail what you mean by interference?  Do
 you mean that you get corrupted audio for short bursts?  Or do you
 mean the audio is dropping out for periods of time?  Can you elaborate
 on how long the problem occurs for, and how often it occurs?  For
 example, do you get corrupted audio for 1 second at a time every ten
 or fifteen seconds?


Hi Devin,

by interference I mean cracks and pops in the sound. These occur
rather randomly, and they are regular but not periodic, by which I
mean there is no defined timeframe between them. Sometimes there are 2
or 3 in a row, other times 10 seconds between them, other times 30
seconds or 1 minute.

These cracks and pops only last for a fraction of a second and they do
not interfere with the audio playing. Its like some kind of static
interference, really high pitched and loud.

 This is a USB audio device, correct?  Are both devices on the same USB
 bus?  Is there a USB hub involved?

Yes they are both USB devices. There is no USB hub involved, and they
are in different ports with different interrupts assigned to them.

 It's also possible that this is just a general latency problem - where
 the CPU becomes too busy, it does not service the sound card often
 enough and PCM data is being dropped.  Have you tried running top?
 What does your CPU utilization look like when you are experiencing the
 problem?

There is no jump in cpu utilization when the spikes occur. I am
running a realtime kernel and I also don't see any latency spikes when
the interferences occur.

The problem occurs with both realtime and normal kernels, on 2.6.31,
.32 and .33. Without your patch (commit
6a2071006b72bf887e38c025c60f98d2998ceacb) the problem is aggravated as
the interference is constant.

Something fishy is going on. I've spent countless hours trying to
figure out the problem it is really hard to find a pattern. This is
what I know till now:

- the first time both devices are connected to the laptop after a
fresh boot, usually there is no problem and they work nicely - the
keyword here is usually, it has happened a few times

- if i unplug and replug the dib0700 adapter, then the cracks and pops
immediately start

- stopping vdr seems to stop the cracks and pops MOST of the time -
though sometimes it also cracks without it

One thing I'm sure - without the dib0700 adapter connected to the USB
bus there is cracking at all.

This is a tough nut to crack.

Thanks for the help,
Pedro

PS: This is probably unrelated, but here is a bug report: if I boot
with the dib0700 adapter connected to the computer, the remote control
does not work. Note what dmesg says:

[   13.033653] dib0700: loaded with support for 14 different device-types
[   13.035185] dvb-usb: found a 'Hauppauge Nova-T Stick' in warm state.
[   13.036516] dvb-usb: will pass the complete MPEG2 transport stream
to the software demuxer.
[   13.038045] DVB: registering new adapter (Hauppauge Nova-T Stick)
[   13.235713] DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
[   13.438312] DiB0070: successfully identified
[   13.439741] input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1d.7/usb2/2-1/input/input13
[   13.441301] dvb-usb: schedule remote query interval to 50 msecs.
[   13.442742] dvb-usb: Hauppauge Nova-T Stick successfully
initialized and connected.
[   13.444577] dib0700: rc submit urb failed
[   13.444579]
[   13.447573] usbcore: registered new interface driver dvb_usb_dib0700
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Capturing raw JPEG stream from webcam

2010-03-15 Thread Laurent Pinchart
Hi Basil,

On Monday 15 March 2010 16:09:49 Basil Mohamed Gohar wrote:
 On 03/15/2010 05:40 AM, Laurent Pinchart wrote:
  On Saturday 13 March 2010 02:55:47 Basil Mohamed Gohar wrote:
  I originally posted this to the video4linux mailing list, but I've since
  discovered that this is the appropriate place (or so I understand) for
  video4linux questions.  My question is how can I capture the raw JPEG
  image stream (e.g., MJPEG) from my webcam, which reports through v4l2
  that it is capable of.  I am using the gst-launch cli to gstreamer,
  
  which confirms that my webcam has this capability:
  image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
  30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }
  
  And, indeed, I can capture using this capability, but the framerate is
  not at the specified rate, but at a much lower value (half or less).
  So, even if I specify 30fps, I get something less.  I can capture the
  full 30fps when I use one of the yuv modes, though, so it's clearly
  capable of delivering that framerate.
  
  My webcam is a Logitech QuickCam Pro 5000.  The lsusb output is:
  046d:08ce Logitech, Inc. QuickCam Pro 5000
  
  An example command line I try is as follows:
  gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
  height=480, framerate=30/1' ! jpegdec ! xvimagesink
  
  Have you tried disabling auto-exposure ? The camera is allowed to reduce
  the frame rate in low-light conditions if auto-exposure is turned on.
 
 Thanks for replying.  I haven't actually tried this yet (I am currently
 at work), but I do not think this is the issue, because when I choose
 the YUV-style modes, I can capture at the full framerates.  It's only
 when I select the image/jpeg mode that I get the lower framerates,
 despite explicitly requesting the higher ones.
 
 I suppose it's not impossible that the camera is opting for different
 behavior depending on the mode of the request, but I think that is not
 likely the case.  I do appreciate the suggestion, though, and I'll try
 it when I get home.

It could, but that indeed seems unlikely. The USB descriptors advertise 30fps 
in MJPEG mode. Unless the information is wrong (in which case this would be a 
firmware bug), 30fps should be achievable.

 Meanwhile, does anyone else have any other ideas?

-- 
Regards,

Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: terratec hybrid xs fm

2010-03-15 Thread fogna
Il 03/12/2010 01:56 PM, Adriano Gigante ha scritto:
 Devin,
 I know I'm boring...
 any news about 0072/terratec hybrid xs fm driver develop progress?
 Thanks
 Adri
 -- 
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html

hi, i'm interested too, i've seen catimmi has successfully implemented
the Cinergy Hybrid T USB XS FR driver, maybe the hardware is very
similar to the Cinergy Hybrid T USB XS FM ? it will be great to get at
least dvb-t support.

Thanks bye!
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Fwd: Delivery Status Notification (Failure)

2010-03-15 Thread Shahar Or
OK, only text this time :)

-- Forwarded message --
From: Mail Delivery Subsystem mailer-dae...@googlemail.com
Date: Mon, Mar 15, 2010 at 10:17 PM
Subject: Delivery Status Notification (Failure)
To: mightyiamprese...@gmail.com


Delivery to the following recipient failed permanently:

    linux-media@vger.kernel.org

Technical details of permanent failure:
Google tried to deliver your message, but it was rejected by the
recipient domain. We recommend contacting the other email provider for
further information about the cause of this error. The error that the
other server returned was: 550 550 5.7.1 Content-Policy reject msg:
The message contains HTML subpart, therefore we consider it SPAM or
Outlook Virus.  TEXT/PLAIN is accepted.! BF:U 0.498823;
S936641Ab0COURI (state 18).

- Original message -

MIME-Version: 1.0
Received: by 10.216.178.70 with SMTP id e48mr24691wem.0.1268684226676; Mon, 15
       Mar 2010 13:17:06 -0700 (PDT)
In-Reply-To: 20100315191239.54f4c...@tele
References: bf87febf1003151024k7987318bv6f76a40c4d7da...@mail.gmail.com
        20100315191239.54f4c...@tele
Date: Mon, 15 Mar 2010 22:17:06 +0200
Message-ID: bf87febf1003151317y4f15ef1fs1c1de6bca0360...@mail.gmail.com
Subject: Re: [Spca50x-devs] 17a1:0118
From: Shahar Or mightyiamprese...@gmail.com
To: Jean-Francois Moine moin...@free.fr
Cc: SPCA50x Linux Device Driver Development
spca50x-d...@lists.sourceforge.net, r...@lecurie.org,
       ropers rop...@gmail.com, Jean-Yves Lamoureux
jy...@lnxscene.org, linux-media@vger.kernel.org
Content-Type: multipart/mixed; boundary=001485f274c8a9ca510481dc90b5

On Mon, Mar 15, 2010 at 8:12 PM, Jean-Francois Moine moin...@free.frwrote:

 On Mon, 15 Mar 2010 19:24:24 +0200
 Shahar Or em...@shahar-or.co.il wrote:

  I have a non-supported one, with the ID 17a1:0118. Data attached.
 
  I am willing to cooperate with anything that I can, including testing
  patches.
 
  I've noticed there's one here related:
 
 http://lists-archives.org/spca50x-devs/01649-patch-for-17a1-0128-xpx-jpeg-webcam-tascorp.html
 
  I can also send the cam over by mail, if that is necessary.
 
  I'm subscribed to the list.

 Hello Shahar,

 A driver for this webcam is available (you may find it in the last
 gspca version that I have just uploaded - 2.9.6 - the subdriver is
 'gspca_tasc.ko').

 The only problem is that nobody could yet decode the images! (Jens,
 Jean-Yves, any news?)

 About the list, all the linux video stuff is hosted at LinuxTv.org and
 the linux-media mailing-list at vger.kernel.org (see Cc:).

 Best regards.

 --
 Ken ar c'hentañ |             ** Breizh ha Linux atav! **
 Jef             |               http://moinejf.free.fr/


Yo, I've installed 2.6.9 and tested with vlc. Theres no image but
/dev/video0 exists. Here's dmesg attached.

BTW, I didn't get the part in the README about If you used a distribution
from a LinuxTv mercurial repository,[...].
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS

2010-03-15 Thread Hans Verkuil
This message is generated daily by a cron job that builds v4l-dvb for
the kernels and architectures in the list below.

Results of the daily build of v4l-dvb:

date:Mon Mar 15 19:00:27 CET 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14461:88b0610d72ec
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81
gcc version:  i686-linux-gcc (GCC) 4.4.3
host hardware:x86_64
host os:  2.6.32.5

linux-2.6.32.6-armv5: OK
linux-2.6.33-armv5: OK
linux-2.6.34-rc1-armv5: OK
linux-2.6.32.6-armv5-davinci: WARNINGS
linux-2.6.33-armv5-davinci: WARNINGS
linux-2.6.34-rc1-armv5-davinci: WARNINGS
linux-2.6.32.6-armv5-ixp: WARNINGS
linux-2.6.33-armv5-ixp: WARNINGS
linux-2.6.34-rc1-armv5-ixp: WARNINGS
linux-2.6.32.6-armv5-omap2: WARNINGS
linux-2.6.33-armv5-omap2: WARNINGS
linux-2.6.34-rc1-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.17-i686: WARNINGS
linux-2.6.24.7-i686: WARNINGS
linux-2.6.25.20-i686: WARNINGS
linux-2.6.26.8-i686: WARNINGS
linux-2.6.27.44-i686: WARNINGS
linux-2.6.28.10-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: WARNINGS
linux-2.6.31.12-i686: WARNINGS
linux-2.6.32.6-i686: WARNINGS
linux-2.6.33-i686: WARNINGS
linux-2.6.34-rc1-i686: WARNINGS
linux-2.6.32.6-m32r: OK
linux-2.6.33-m32r: OK
linux-2.6.34-rc1-m32r: OK
linux-2.6.32.6-mips: WARNINGS
linux-2.6.33-mips: WARNINGS
linux-2.6.34-rc1-mips: WARNINGS
linux-2.6.32.6-powerpc64: WARNINGS
linux-2.6.33-powerpc64: WARNINGS
linux-2.6.34-rc1-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: WARNINGS
linux-2.6.23.17-x86_64: WARNINGS
linux-2.6.24.7-x86_64: WARNINGS
linux-2.6.25.20-x86_64: WARNINGS
linux-2.6.26.8-x86_64: WARNINGS
linux-2.6.27.44-x86_64: WARNINGS
linux-2.6.28.10-x86_64: WARNINGS
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: WARNINGS
linux-2.6.31.12-x86_64: WARNINGS
linux-2.6.32.6-x86_64: WARNINGS
linux-2.6.33-x86_64: WARNINGS
linux-2.6.34-rc1-x86_64: WARNINGS
linux-git-armv5: OK
linux-git-armv5-davinci: OK
linux-git-armv5-ixp: OK
linux-git-armv5-omap2: OK
linux-git-i686: WARNINGS
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: WARNINGS
linux-git-x86_64: WARNINGS
spec: ERRORS
spec-git: OK
sparse: ERRORS
linux-2.6.16.62-i686: WARNINGS
linux-2.6.17.14-i686: WARNINGS
linux-2.6.18.8-i686: WARNINGS
linux-2.6.19.7-i686: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.62-x86_64: WARNINGS
linux-2.6.17.14-x86_64: WARNINGS
linux-2.6.18.8-x86_64: WARNINGS
linux-2.6.19.7-x86_64: WARNINGS
linux-2.6.20.21-x86_64: WARNINGS
linux-2.6.21.7-x86_64: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2

The V4L-DVB specification from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/media.html
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


ATSC substreams

2010-03-15 Thread Dr Wowe
Hello,
I have my channels.conf set up for use with my TV tuner, to receive 
over-the-air ATSC broadcasts in the USA.
Some of my local channels have multiple substreams, which are configured in 
channels.conf like this:
---
21.1:509028615:8VSB:49:52:3
21.2:509028615:8VSB:65:68:4
21.3:509028615:8VSB:81:84:5
---
I can record video from a channel using the command-line:
$ azap -r 21.1
$ dd if=/dev/dvb/adapter0/dvr0 of=video.ts

My question is this: How can I configure it so that I am recording all 3 
substreams at the same time, multiplexed into a single MPEG TS?  I know this is 
physically possible, because the old pre-DVB V4L interface I used several years 
ago did that, recording the raw ATSC signal from channel 21, with all of the 
channels included as mpeg substreams.


  
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Ubuntu and AverMedia DVD EZMaker USB Gold

2010-03-15 Thread Adrian Pardini
On 04/03/2010, Jorge Cabrera jorge.cabr...@andago.com wrote:
 Hello again,

 I was wrong here, the driver works, the device works great but what's
 going on is that it uses the tuner as the default input, when I run
 mplayer with input=1 (composite video) or input=2 (s-video) it works good:

 mplayer tv:// -tv input=1:device=/dev/video0

 But this isn't good enough because cheese and camorama and flash use the
 default input. How can I set up default input to composite video or
 s-video? Should I add something to the options that the Avermedia kernel
 module uses?

Try using the v4lctl command. Something like

v4lctl setinput Composite1

will do. You can replace Composite1 with other names like Television
etc. The manpage has more information.


-- 
Adrian.
http://elesquinazotango.com.ar
http://www.noalcodigodescioli.blogspot.com/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


RE: Capturing raw JPEG stream from webcam

2010-03-15 Thread John Selbie

Message bounced the first time because I had HTML on.  Here it is again.
 
I have the same camera (Logi 5000). There's an ordering issue of ioctl
calls that you have to make to get the frame rate set properly. But I'm
away from my home computer and code, so I can't quote the solution to
you yet. I can't speak about gst-launch, but I do I recall fixing
this exact bug in my own code.

I figured out the frame rate issue by examing the code to luvcview.
That sample app can capture jpegs at 640x480x30fps no problem.

I'll post sample code to you later tonight.



 From: laurent.pinch...@ideasonboard.com
 To: abu_huray...@hidayahonline.org
 Subject: Re: Capturing raw JPEG stream from webcam
 Date: Mon, 15 Mar 2010 21:00:05 +0100
 CC: linux-media@vger.kernel.org

 Hi Basil,

 On Monday 15 March 2010 16:09:49 Basil Mohamed Gohar wrote:
 On 03/15/2010 05:40 AM, Laurent Pinchart wrote:
 On Saturday 13 March 2010 02:55:47 Basil Mohamed Gohar wrote:
 I originally posted this to the video4linux mailing list, but I've since
 discovered that this is the appropriate place (or so I understand) for
 video4linux questions. My question is how can I capture the raw JPEG
 image stream (e.g., MJPEG) from my webcam, which reports through v4l2
 that it is capable of. I am using the gst-launch cli to gstreamer,

 which confirms that my webcam has this capability:
 image/jpeg, width=(int)640, height=(int)480, framerate=(fraction){
 30/1, 25/1, 20/1, 15/1, 10/1, 5/1 }

 And, indeed, I can capture using this capability, but the framerate is
 not at the specified rate, but at a much lower value (half or less).
 So, even if I specify 30fps, I get something less. I can capture the
 full 30fps when I use one of the yuv modes, though, so it's clearly
 capable of delivering that framerate.

 My webcam is a Logitech QuickCam Pro 5000. The lsusb output is:
 046d:08ce Logitech, Inc. QuickCam Pro 5000

 An example command line I try is as follows:
 gst-launch-0.10 v4l2src device=/dev/video0 ! 'image/jpeg, width=640,
 height=480, framerate=30/1' ! jpegdec ! xvimagesink

 Have you tried disabling auto-exposure ? The camera is allowed to reduce
 the frame rate in low-light conditions if auto-exposure is turned on.

 Thanks for replying. I haven't actually tried this yet (I am currently
 at work), but I do not think this is the issue, because when I choose
 the YUV-style modes, I can capture at the full framerates. It's only
 when I select the image/jpeg mode that I get the lower framerates,
 despite explicitly requesting the higher ones.

 I suppose it's not impossible that the camera is opting for different
 behavior depending on the mode of the request, but I think that is not
 likely the case. I do appreciate the suggestion, though, and I'll try
 it when I get home.

 It could, but that indeed seems unlikely. The USB descriptors advertise 30fps
 in MJPEG mode. Unless the information is wrong (in which case this would be a
 firmware bug), 30fps should be achievable.

 Meanwhile, does anyone else have any other ideas?

 --
 Regards,

 Laurent Pinchart
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at http://vger.kernel.org/majordomo-info.html 
   
_
Lauren found her dream laptop. Find the PC that’s right for you.
http://www.microsoft.com/windows/choosepc/?ocid=ftp_val_wl_290--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


891,934.000GBP has been awarded to you.

2010-03-15 Thread camelot
Submit Name:Address:Age:Sex:Occupation:Tel:Country
This is to notify you.


--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Magic in videobuf

2010-03-15 Thread Andy Walls
On Mon, 2010-03-15 at 14:26 -0300, Mauro Carvalho Chehab wrote:
 Hans Verkuil wrote:
  Hans Verkuil wrote:
  Pawel Osciak wrote:

  is anyone aware of any other uses for MAGIC_CHECK()s in videobuf code
  besides driver debugging? I intend to remove them, as we weren't able
  to find any particular use for them when we were discussing this at
  the memory handling meeting in Norway...
  It is a sort of paranoid check to avoid the risk of mass memory
  corruption
  if something goes deadly wrong with the video buffers.
 

  What on earth does this magic check have to do with possible DMA
  overruns/memory corruption? This assumes that somehow exactly these
  magic
  fields are overwritten and that you didn't crash because of memory
  corruption elsewhere much earlier.

  All it does is oops anyway, so it really doesn't 'avoid' a crash
  (as if you could in such scenarios). And most likely the damage has been
  done already in that case.
  It won't avoid the damage, but the error message could potentially help
  to track the issue. It will also likely limit the damage.
 
  Please let us get rid of this. It makes no sense whatsoever.
  I don't have a strong opinion about this subject, but if this code might
  help
  to avoid propagating the damage and to track the issue, I don't see why we
  need to remove it, especially since it is easy to disable the entire logic
  by just adding a few #if's to remove this code on environments where no
  problem is expected.
  
  It is highly unlikely that this code ever prevented these issues.
  Especially given the places where the check is done. I think this is just
  debug code that has been dragged along for all these years without anyone
  bothering to remove it.

 I remember I had to re-format one disk, during that time, due to a videobuf 
 issue.
 So, those checks help people that are touching at the videobuf code, reducing 
 the 
 chances of damaging their disk partitions when trying to implement overlay 
 mode and
 userptr on the videobuf implementations that misses those features, or when
 working on a different mmap() logic at the driver.


In a previous job, working on a particularly large application, I had
occasional corruption in a shared memory segment that was shared by many
writer processes and 2 readers.  A simple checksum on the data header
(and contents if appropriate) was enough to detect corrpution and avoid
dereferencing a corrupted pointer to the next data element (when walking
a data area filled with Key-Length-Value encoded data).

This forward error detection was inelegant to me - kind of like
putting armor on one's car instead of learning to drive properly.  I
only resorted to using the checksum because there was almost no way to
find which process was corrupting shared memory in a reasonable amount
of time.  It allowed me to change a show stopper bug into an annoying
data presentation bug, so the product could be released to a production
environment.

In a development environment, it would be much better to disable such
defensive coding and let the kernel Oops.  You'll never find the
problems if you keep hiding them from yourself.


Regards,
Andy

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[PATCH] Add SPI support to V4L2

2010-03-15 Thread Dmitri Belimov
Hi

Add support SPI bus to v4l2. Useful for control some device with SPI bus like
hardware MPEG2 encoders and etc.

diff -r b6b82258cf5e linux/drivers/media/video/v4l2-common.c
--- a/linux/drivers/media/video/v4l2-common.c   Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/v4l2-common.c   Tue Mar 16 05:06:04 2010 +0900
@@ -63,6 +63,10 @@
 
 #include linux/videodev2.h
 #include compat.h
+
+#if defined(CONFIG_SPI)
+#include linux/spi/spi.h
+#endif
 
 MODULE_AUTHOR(Bill Dirks, Justin Schoeman, Gerd Knorr);
 MODULE_DESCRIPTION(misc helper functions for v4l2 device drivers);
@@ -1069,6 +1073,66 @@
 
 #endif /* defined(CONFIG_I2C) */
 
+#if defined(CONFIG_SPI)
+
+/* Load a spi sub-device. */
+
+void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct spi_device *spi,
+   const struct v4l2_subdev_ops *ops)
+{
+   v4l2_subdev_init(sd, ops);
+   sd-flags |= V4L2_SUBDEV_FL_IS_SPI;
+   /* the owner is the same as the spi_device's driver owner */
+   sd-owner = spi-dev.driver-owner;
+   /* spi_device and v4l2_subdev point to one another */
+   v4l2_set_subdevdata(sd, spi);
+   spi_set_drvdata(spi, sd);
+   /* initialize name */
+   strlcpy(sd-name, spi-dev.driver-name, sizeof(sd-name));
+}
+EXPORT_SYMBOL_GPL(v4l2_spi_subdev_init);
+
+struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev,
+   struct spi_master *master, struct spi_board_info *info)
+{
+   struct v4l2_subdev *sd = NULL;
+   struct spi_device *spi = NULL;
+
+   BUG_ON(!v4l2_dev);
+
+   if (info-modalias)
+   request_module(info-modalias);
+
+   spi = spi_new_device(master, info);
+
+   if (spi == NULL || spi-dev.driver == NULL)
+   goto error;
+
+   if (!try_module_get(spi-dev.driver-owner))
+   goto error;
+
+   sd = spi_get_drvdata(spi);
+
+   /* Register with the v4l2_device which increases the module's
+  use count as well. */
+   if (v4l2_device_register_subdev(v4l2_dev, sd))
+   sd = NULL;
+
+   /* Decrease the module use count to match the first try_module_get. */
+   module_put(spi-dev.driver-owner);
+
+error:
+   /* If we have a client but no subdev, then something went wrong and
+  we must unregister the client. */
+   if (spi  sd == NULL)
+   spi_unregister_device(spi);
+
+   return sd;
+}
+EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
+
+#endif /* defined(CONFIG_SPI) */
+
 /* Clamp x to be between min and max, aligned to a multiple of 2^align.  min
  * and max don't have to be aligned, but there must be at least one valid
  * value.  E.g., min=17,max=31,align=4 is not allowed as there are no multiples
diff -r b6b82258cf5e linux/drivers/media/video/v4l2-device.c
--- a/linux/drivers/media/video/v4l2-device.c   Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/drivers/media/video/v4l2-device.c   Tue Mar 16 05:06:04 2010 +0900
@@ -24,6 +24,10 @@
 #include linux/videodev2.h
 #include media/v4l2-device.h
 #include compat.h
+
+#if defined(CONFIG_SPI)
+#include linux/spi/spi.h
+#endif
 
 int v4l2_device_register(struct device *dev, struct v4l2_device *v4l2_dev)
 {
@@ -100,6 +104,14 @@
}
 #endif
 #endif
+#if defined(CONFIG_SPI)
+   if (sd-flags  V4L2_SUBDEV_FL_IS_SPI) {
+   struct spi_device *spi = v4l2_get_subdevdata(sd);
+
+   if (spi)
+   spi_unregister_device(spi);
+   }
+#endif
}
 }
 EXPORT_SYMBOL_GPL(v4l2_device_unregister);
diff -r b6b82258cf5e linux/include/media/v4l2-common.h
--- a/linux/include/media/v4l2-common.h Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/include/media/v4l2-common.h Tue Mar 16 05:06:04 2010 +0900
@@ -191,6 +191,24 @@
 
 /* - */
 
+/* SPI Helper functions */
+#if defined(CONFIG_SPI)
+
+#include linux/spi/spi.h
+
+struct spi_device;
+
+/* Load an spi module and return an initialized v4l2_subdev struct.
+   The client_type argument is the name of the chip that's on the adapter. */
+struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev,
+   struct spi_master *master, struct spi_board_info *info);
+
+/* Initialize an v4l2_subdev with data from an spi_device struct */
+void v4l2_spi_subdev_init(struct v4l2_subdev *sd, struct spi_device *spi,
+   const struct v4l2_subdev_ops *ops);
+#endif
+/* - */
+
 /* Note: these remaining ioctls/structs should be removed as well, but they are
still used in tuner-simple.c (TUNER_SET_CONFIG), cx18/ivtv (RESET) and
v4l2-int-device.h (v4l2_routing). To remove these ioctls some more cleanup
diff -r b6b82258cf5e linux/include/media/v4l2-subdev.h
--- a/linux/include/media/v4l2-subdev.h Thu Dec 31 19:14:54 2009 -0200
+++ b/linux/include/media/v4l2-subdev.h Tue Mar 16 05:06:04 2010 +0900
@@ 

Re: [BUGFIX][PATCH] change some parameters for tlg2300

2010-03-15 Thread Huang Shijie
Hi Mauro:
 This patch has side effect : the radio does not run well with this patch.
   
I tested the patch carefully.
If I listen the radio with mplayer in the root account, the radio does
not run well ( a xrun occurs);
if I listen the radio with mplayer in the normal account (not root). the
radio runs well.

Do you have any advice ? Do you think this is a problem?

thanks.

 Best Regards
 Huang Shijie.

   
 The orgin parameters may cause a bug : The audio may lost in certain
 situation (such as open the VLC at the first time).

 The origin parameters set a small stop_threshold for snd_pcm_runtime{}.
 So a xrun occurs in some situation.

 Signed-off-by: Huang Shijie shij...@gmail.com
 ---
  drivers/media/video/tlg2300/pd-alsa.c |   10 --
  1 files changed, 0 insertions(+), 10 deletions(-)

 diff --git a/drivers/media/video/tlg2300/pd-alsa.c 
 b/drivers/media/video/tlg2300/pd-alsa.c
 index 6f42621..e9ad715 100644
 --- a/drivers/media/video/tlg2300/pd-alsa.c
 +++ b/drivers/media/video/tlg2300/pd-alsa.c
 @@ -21,9 +21,6 @@
  static void complete_handler_audio(struct urb *urb);
  #define AUDIO_EP(0x83)
  #define AUDIO_BUF_SIZE  (512)
 -#define PERIOD_SIZE (1024 * 8)
 -#define PERIOD_MIN  (4)
 -#define PERIOD_MAX  PERIOD_MIN
  
  static struct snd_pcm_hardware snd_pd_hw_capture = {
  .info = SNDRV_PCM_INFO_BLOCK_TRANSFER |
 @@ -38,18 +35,11 @@ static struct snd_pcm_hardware snd_pd_hw_capture = {
  .rate_max = 48000,
  .channels_min = 2,
  .channels_max = 2,
 -.buffer_bytes_max = PERIOD_SIZE * PERIOD_MIN,
 -.period_bytes_min = PERIOD_SIZE,
 -.period_bytes_max = PERIOD_SIZE,
 -.periods_min = PERIOD_MIN,
 -.periods_max = PERIOD_MAX,
 -/*
  .buffer_bytes_max = 62720 * 8,
  .period_bytes_min = 64,
  .period_bytes_max = 12544,
  .periods_min = 2,
  .periods_max = 98
 -*/
  };
  
  static int snd_pd_capture_open(struct snd_pcm_substream *substream)
   
 
   

--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html