[PATCH] pxa_camera: move fifo reset direct before dma start

2010-04-20 Thread Stefan Herbrechtsmeier
Move the fifo reset from pxa_camera_start_capture to pxa_camera_irq direct
before the dma start after an end of frame interrupt to prevent images from
shifting because of old data at the begin of the frame.

Signed-off-by: Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de
---
 drivers/media/video/pxa_camera.c |   11 ++-
 1 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/media/video/pxa_camera.c b/drivers/media/video/pxa_camera.c
index 5ecc30d..04bf5c1 100644
--- a/drivers/media/video/pxa_camera.c
+++ b/drivers/media/video/pxa_camera.c
@@ -609,12 +609,9 @@ static void pxa_dma_add_tail_buf(struct pxa_camera_dev 
*pcdev,
  */
 static void pxa_camera_start_capture(struct pxa_camera_dev *pcdev)
 {
-   unsigned long cicr0, cifr;
+   unsigned long cicr0;
 
dev_dbg(pcdev-soc_host.v4l2_dev.dev, %s\n, __func__);
-   /* Reset the FIFOs */
-   cifr = __raw_readl(pcdev-base + CIFR) | CIFR_RESET_F;
-   __raw_writel(cifr, pcdev-base + CIFR);
/* Enable End-Of-Frame Interrupt */
cicr0 = __raw_readl(pcdev-base + CICR0) | CICR0_ENB;
cicr0 = ~CICR0_EOFM;
@@ -935,7 +932,7 @@ static void pxa_camera_deactivate(struct pxa_camera_dev 
*pcdev)
 static irqreturn_t pxa_camera_irq(int irq, void *data)
 {
struct pxa_camera_dev *pcdev = data;
-   unsigned long status, cicr0;
+   unsigned long status, cifr, cicr0;
struct pxa_buffer *buf;
struct videobuf_buffer *vb;
 
@@ -949,6 +946,10 @@ static irqreturn_t pxa_camera_irq(int irq, void *data)
__raw_writel(status, pcdev-base + CISR);
 
if (status  CISR_EOF) {
+   /* Reset the FIFOs */
+   cifr = __raw_readl(pcdev-base + CIFR) | CIFR_RESET_F;
+   __raw_writel(cifr, pcdev-base + CIFR);
+
pcdev-active = list_first_entry(pcdev-capture,
   struct pxa_buffer, vb.queue);
vb = pcdev-active-vb;
-- 
1.5.4.3

--
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 v4 0/2] Mem-to-mem device framework

2010-04-20 Thread Hiremath, Vaibhav

 -Original Message-
 From: Pawel Osciak [mailto:p.osc...@samsung.com]
 Sent: Monday, April 19, 2010 6:00 PM
 To: linux-media@vger.kernel.org
 Cc: p.osc...@samsung.com; m.szyprow...@samsung.com;
 kyungmin.p...@samsung.com; Hiremath, Vaibhav
 Subject: [PATCH v4 0/2] Mem-to-mem device framework
 
 Hello,
 
 this is the fourth version of the mem-to-mem device framework.
 
 Changes in v4:
 - v4l2_m2m_poll() now also reports POLLOUT | POLLWRNORM when an output
   buffer is ready to be dequeued
 - more cleaning up, addressing most of the comments to v3
 
 Vaibhav: your clean-up patch didn't apply after my changes. I incorporated
 most
 of your clean-up changes. If you prefer it to be separate, we will have
 to prepare another one somehow. 
[Hiremath, Vaibhav] No need to create separate patch for this, it's ok as long 
as you included all the required changes.

You can add Tested-By Or Reviewed-By in your patch series, that should be 
ok.

I will take a final look to this patch and respond.

 Also, sorry, but I cannot agree with
 changing
 unsigned types into u32, I do not see any reason to use fixed-width types
 there.
 
[Hiremath, Vaibhav] As I mentioned there no strict rule for this, it was 
learning from my first patch.

Thanks,
Vaibhav
 This series contains:
 [PATCH v4 1/2] v4l: Add memory-to-memory device helper framework for
 videobuf.
 [PATCH v4 2/2] v4l: Add a mem-to-mem videobuf framework test device.
 
 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


Re: [PATCH] pxa_camera: move fifo reset direct before dma start

2010-04-20 Thread Guennadi Liakhovetski
Robert, what do you think? Are you still working with PXA camera?

Thanks
Guennadi

On Tue, 20 Apr 2010, Stefan Herbrechtsmeier wrote:

 Move the fifo reset from pxa_camera_start_capture to pxa_camera_irq direct
 before the dma start after an end of frame interrupt to prevent images from
 shifting because of old data at the begin of the frame.
 
 Signed-off-by: Stefan Herbrechtsmeier hbme...@hni.uni-paderborn.de
 ---
  drivers/media/video/pxa_camera.c |   11 ++-
  1 files changed, 6 insertions(+), 5 deletions(-)
 
 diff --git a/drivers/media/video/pxa_camera.c 
 b/drivers/media/video/pxa_camera.c
 index 5ecc30d..04bf5c1 100644
 --- a/drivers/media/video/pxa_camera.c
 +++ b/drivers/media/video/pxa_camera.c
 @@ -609,12 +609,9 @@ static void pxa_dma_add_tail_buf(struct pxa_camera_dev 
 *pcdev,
   */
  static void pxa_camera_start_capture(struct pxa_camera_dev *pcdev)
  {
 - unsigned long cicr0, cifr;
 + unsigned long cicr0;
  
   dev_dbg(pcdev-soc_host.v4l2_dev.dev, %s\n, __func__);
 - /* Reset the FIFOs */
 - cifr = __raw_readl(pcdev-base + CIFR) | CIFR_RESET_F;
 - __raw_writel(cifr, pcdev-base + CIFR);
   /* Enable End-Of-Frame Interrupt */
   cicr0 = __raw_readl(pcdev-base + CICR0) | CICR0_ENB;
   cicr0 = ~CICR0_EOFM;
 @@ -935,7 +932,7 @@ static void pxa_camera_deactivate(struct pxa_camera_dev 
 *pcdev)
  static irqreturn_t pxa_camera_irq(int irq, void *data)
  {
   struct pxa_camera_dev *pcdev = data;
 - unsigned long status, cicr0;
 + unsigned long status, cifr, cicr0;
   struct pxa_buffer *buf;
   struct videobuf_buffer *vb;
  
 @@ -949,6 +946,10 @@ static irqreturn_t pxa_camera_irq(int irq, void *data)
   __raw_writel(status, pcdev-base + CISR);
  
   if (status  CISR_EOF) {
 + /* Reset the FIFOs */
 + cifr = __raw_readl(pcdev-base + CIFR) | CIFR_RESET_F;
 + __raw_writel(cifr, pcdev-base + CIFR);
 +
   pcdev-active = list_first_entry(pcdev-capture,
  struct pxa_buffer, vb.queue);
   vb = pcdev-active-vb;
 -- 
 1.5.4.3
 

---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: xHCI bandwidth error with USB webcam

2010-04-20 Thread Andiry Xu
On Fri, 2010-04-16 at 07:51 -0700, Sarah Sharp wrote:
  I'm also verifying usb webcam these days. The host controller also
  rejects alternate setting, indicating not enough bandwidth. Fortunately
  the webcam I used is using gspca and the patch for gspca below does
  work. After several times of failure, it will set the alt setting
  successfully. See the log and descriptors.
 
 Good to know that works!  I'll resubmit it as a real patch then.
 
  But I don't think it's normal behavior. The xHC should accept the alt
  setting request at the first time. I'm also using the NEC chips, perhaps
  it's a HW or FW issue but I can't make sure. 
 
 I have a patch to fix this.  I wasn't setting the Average TRB Length or
 Max ESIT fields in the isoc endpoint descriptor.  Apparently the NEC
 chip only needs the avg. TRB length to accept the alternate setting, but
 the xHCI spec says it's really the max ESIT payload that is used for
 scheduling, so I've set both.

I've tested the patches and they works. Thanks. 

 I'll send the patch in a view minutes.  Unfortunately, with my gspca
 full speed webcam, I hang my machine after installing the interface,
 when the driver first submits an isochronous URB.  It's a scheduling
 while atomic error with a very odd backtrace.  But it happens every
 time I plug in the webcam, so I know it's related to that.  Gzipped log
 file is attached.  Ignore the values of the tx_info field in the
 endpoint, I had a bug with the math in the patch that I've since fixed.

I've checked this issue and figured out the root cause. I used
prepare_ring() to check the room for each td in the URB, but not for the
whole URB. If a URB carrying multple packets/tds is failed to enqueue
due to not enough room on the ring, perhaps some of its tds have already
been inserted to the ring before the check failure, which is a mistake.
A URB should be inserted to the ring as a whole: either it can be
enqueued, or not. Not part of it.

I'll submit the updated patches to fix this issue. It used
prepare_ring() in the beginning to guarantee there is enough room for
the whole URB. This should fix your issue. 

  Another problem of the isoc transfer is the size of the transfer ring.
  Currently in xhci_endpoint_init() of xhci-mem.c, the ring allocated
  for each endpoint just contains one segment, which can hold 64 - 1 =
  63 trbs. But the gspca will submit 3 urbs at one time, each consists
  of 32 packets. Each packet needs an isoc TD to carry, and the driver
  will insert 96 trbs to the ring at one time. It will cause the
  room_on_ring check failure since the xHC cannot process the trbs in
  time.  After I modify the parameter of xhci_ring_alloc() in
  xhci_endpoint_init() to allocate 2 segments, the webcam works
  smoothly. It looks like dynamic ring allocation is necessary for isoc
  endpoint since it will put multiple trbs on the ring and the fixed
  size is too small.
 
 Yes, it looks like dynamic ring resizing is necessary, but feel free to
 submit your patch for xhci_endpoint_init() for now.

I will submit the patch to allocate bigger ring for isoc endpoints as a
temporary workaround. 

Andiry Xu

--
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 2/3] ASoC: WL1273 FM Radio: Digital audio codec.

2010-04-20 Thread Matti J. Aaltonen
The codec handles digital audio input to and output from the
WL1273 FM radio.

Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
 sound/soc/codecs/Kconfig  |6 +
 sound/soc/codecs/Makefile |2 +
 sound/soc/codecs/wl1273.c |  708 +
 sound/soc/codecs/wl1273.h |   49 +++
 4 files changed, 765 insertions(+), 0 deletions(-)
 create mode 100644 sound/soc/codecs/wl1273.c
 create mode 100644 sound/soc/codecs/wl1273.h

diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 52b005f..c4769f2 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -35,6 +35,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_UDA134X
select SND_SOC_UDA1380 if I2C
+   select SND_SOC_WL1273 if I2C
select SND_SOC_WM8350 if MFD_WM8350
select SND_SOC_WM8400 if MFD_WM8400
select SND_SOC_WM8510 if SND_SOC_I2C_AND_SPI
@@ -161,6 +162,11 @@ config SND_SOC_UDA134X
 config SND_SOC_UDA1380
 tristate
 
+config SND_SOC_WL1273
+   tristate
+   select WL1273_CORE
+   default n
+
 config SND_SOC_WM8350
tristate
 
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index dbaecb1..2a7c564 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -22,6 +22,7 @@ snd-soc-tlv320dac33-objs := tlv320dac33.o
 snd-soc-twl4030-objs := twl4030.o
 snd-soc-uda134x-objs := uda134x.o
 snd-soc-uda1380-objs := uda1380.o
+snd-soc-wl1273-objs := wl1273.o
 snd-soc-wm8350-objs := wm8350.o
 snd-soc-wm8400-objs := wm8400.o
 snd-soc-wm8510-objs := wm8510.o
@@ -78,6 +79,7 @@ obj-$(CONFIG_SND_SOC_TLV320DAC33) += snd-soc-tlv320dac33.o
 obj-$(CONFIG_SND_SOC_TWL4030)  += snd-soc-twl4030.o
 obj-$(CONFIG_SND_SOC_UDA134X)  += snd-soc-uda134x.o
 obj-$(CONFIG_SND_SOC_UDA1380)  += snd-soc-uda1380.o
+obj-$(CONFIG_SND_SOC_WL1273)   += snd-soc-wl1273.o
 obj-$(CONFIG_SND_SOC_WM8350)   += snd-soc-wm8350.o
 obj-$(CONFIG_SND_SOC_WM8400)   += snd-soc-wm8400.o
 obj-$(CONFIG_SND_SOC_WM8510)   += snd-soc-wm8510.o
diff --git a/sound/soc/codecs/wl1273.c b/sound/soc/codecs/wl1273.c
new file mode 100644
index 000..2efe865
--- /dev/null
+++ b/sound/soc/codecs/wl1273.c
@@ -0,0 +1,708 @@
+/*
+ * ALSA SoC WL1273 codec driver
+ *
+ * Author:  Matti Aaltonen, matti.j.aalto...@nokia.com
+ *
+ * Copyright:   (C) 2010 Nokia Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#undef DEBUG
+
+#include linux/mfd/wl1273-core.h
+#include linux/module.h
+#include sound/pcm.h
+#include sound/pcm_params.h
+#include sound/soc.h
+#include sound/soc-dapm.h
+#include sound/initval.h
+
+#include wl1273.h
+
+static int wl1273_get_audio_route(struct snd_kcontrol *kcontrol,
+ struct snd_ctl_elem_value *ucontrol)
+{
+   struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+   struct wl1273_priv *wl1273 = codec-private_data;
+
+   ucontrol-value.integer.value[0] = wl1273-mode;
+
+   return 0;
+}
+
+static int wl1273_set_audio_route(struct snd_kcontrol *kcontrol,
+struct snd_ctl_elem_value *ucontrol)
+{
+   struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+   struct wl1273_priv *wl1273 = codec-private_data;
+
+   /* Do not allow changes while stream is running */
+   if (codec-active)
+   return -EPERM;
+
+   wl1273-mode = ucontrol-value.integer.value[0];
+
+   return 1;
+}
+
+static const char *wl1273_audio_route[] = { Bt, FmRx, FmTx };
+
+static const struct soc_enum wl1273_enum[] = {
+   SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(wl1273_audio_route), wl1273_audio_route),
+};
+
+static int snd_wl1273_fm_ctune_get(struct snd_kcontrol *kcontrol,
+  struct snd_ctl_elem_value *ucontrol)
+{
+   struct snd_soc_codec *codec = snd_kcontrol_chip(kcontrol);
+   struct wl1273_priv *wl1273 = codec-private_data;
+
+   dev_dbg(codec-dev, %s: enter.\n, __func__);
+
+   wl1273-ctune = wl1273_fm_get_tx_ctune(wl1273-core);
+   ucontrol-value.integer.value[0] = wl1273-ctune;
+
+   return 0;
+}
+
+static int snd_wl1273_fm_power_get(struct snd_kcontrol *kcontrol,
+  struct snd_ctl_elem_value *ucontrol)
+{
+   struct snd_soc_codec *codec = 

[PATCH 3/3] V4L2: WL1273 FM Radio: Controls for the FM radio.

2010-04-20 Thread Matti J. Aaltonen
This file implements V4L2 controls for using the Texas Instruments
WL1273 FM Radio.

Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
 drivers/media/radio/Kconfig|   15 +
 drivers/media/radio/Makefile   |1 +
 drivers/media/radio/radio-wl1273.c |  805 
 3 files changed, 821 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/radio/radio-wl1273.c

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index 83567b8..209fd37 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -452,4 +452,19 @@ config RADIO_TIMBERDALE
  found behind the Timberdale FPGA on the Russellville board.
  Enabling this driver will automatically select the DSP and tuner.
 
+config RADIO_WL1273
+   tristate Texas Instruments WL1273 I2C FM Radio
+depends on I2C  VIDEO_V4L2  SND
+   select FW_LOADER
+   ---help---
+ Choose Y here if you have this FM radio chip.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux 2 API.  Information on
+ this API and pointers to v4l2 programs may be found at
+ file:Documentation/video4linux/API.html.
+
+ To compile this driver as a module, choose M here: the
+ module will be called radio-wl1273.
+
 endif # RADIO_ADAPTERS
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index f615583..d297074 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -26,5 +26,6 @@ obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o
 obj-$(CONFIG_RADIO_SAA7706H) += saa7706h.o
 obj-$(CONFIG_RADIO_TEF6862) += tef6862.o
 obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o
+obj-$(CONFIG_RADIO_WL1273) += radio-wl1273.o
 
 EXTRA_CFLAGS += -Isound
diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
new file mode 100644
index 000..07f6787
--- /dev/null
+++ b/drivers/media/radio/radio-wl1273.c
@@ -0,0 +1,805 @@
+/*
+ * Driver for the Texas Instruments WL1273 FM radio.
+ *
+ * Copyright (C) Nokia Corporation
+ * Author: Matti J. Aaltonen matti.j.aalto...@nokia.com
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#undef DEBUG
+
+#include asm/unaligned.h
+#include linux/mfd/wl1273-core.h
+#include linux/platform_device.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+
+#define DRIVER_DESC Wl1273 FM Radio - V4L2
+
+/*
+ * static int radio_nr - The number of the radio device
+ *
+ * The default is 0.
+ */
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, Radio Nr);
+
+struct wl1273_device {
+   struct video_device *videodev;
+   struct device *dev;
+   struct wl1273_core *core;
+   bool rds_on;
+};
+
+static ssize_t wl1273_fm_fops_write(struct file *file, const char __user *buf,
+   size_t count, loff_t *ppos)
+{
+   struct wl1273_device *radio = video_get_drvdata(video_devdata(file));
+   unsigned char *s;
+   u16 val;
+   int r;
+
+   dev_dbg(radio-dev, %s\n, __func__);
+
+   if (radio-core-mode == WL1273_MODE_RX)
+   return count;
+
+   if (mutex_lock_interruptible(radio-core-lock))
+   return -EINTR;
+
+   /* Manual Mode */
+   if (count  255)
+   val = 255;
+   else
+   val = count;
+
+   wl1273_fm_write_cmd(radio-core, WL1273_RDS_CONFIG_DATA_SET, val);
+
+   s = kmalloc(val + 1, GFP_KERNEL);
+   if (!s) {
+   r = -ENOMEM;
+   goto out;
+   }
+
+   if (copy_from_user(s + 1, buf, val)) {
+   kfree(s);
+   r = -EFAULT;
+   goto out;
+   }
+
+   dev_dbg(radio-dev, Count: %d\n, val);
+   dev_dbg(radio-dev, From user: \%s\\n, s);
+
+   s[0] = WL1273_RDS_DATA_SET;
+   wl1273_fm_write_data(radio-core, s, val + 1);
+
+   kfree(s);
+   r = val;
+
+out:
+   mutex_unlock(radio-core-lock);
+
+   return r;
+}
+
+static unsigned int wl1273_fm_fops_poll(struct file *file,
+   struct poll_table_struct *pts)
+{
+   struct wl1273_device *radio = video_get_drvdata(video_devdata(file));
+   struct wl1273_core *core = radio-core;
+   unsigned int 

[PATCH 1/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.

2010-04-20 Thread Matti J. Aaltonen
This is a parent driver for two child drivers: the V4L2 driver and
the ALSA codec driver. The MFD part provides the I2C communication
to the device and the state handling.

Signed-off-by: Matti J. Aaltonen matti.j.aalto...@nokia.com
---
 drivers/mfd/Kconfig |6 +
 drivers/mfd/Makefile|2 +
 drivers/mfd/wl1273-core.c   | 1825 +++
 include/linux/mfd/wl1273-core.h |  265 ++
 4 files changed, 2098 insertions(+), 0 deletions(-)
 create mode 100644 drivers/mfd/wl1273-core.c
 create mode 100644 include/linux/mfd/wl1273-core.h

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 413576a..c16d500 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -135,6 +135,12 @@ config TWL4030_CODEC
select MFD_CORE
default n
 
+config WL1273_CORE
+   tristate
+   depends on I2C
+   select MFD_CORE
+   default n
+
 config MFD_TMIO
bool
default n
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index 16a349f..5381cd3 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -30,6 +30,8 @@ obj-$(CONFIG_TWL4030_CORE)+= twl-core.o twl4030-irq.o 
twl6030-irq.o
 obj-$(CONFIG_TWL4030_POWER)+= twl4030-power.o
 obj-$(CONFIG_TWL4030_CODEC)+= twl4030-codec.o
 
+obj-$(CONFIG_WL1273_CORE)  += wl1273-core.o
+
 obj-$(CONFIG_MFD_MC13783)  += mc13783-core.o
 
 obj-$(CONFIG_MFD_CORE) += mfd-core.o
diff --git a/drivers/mfd/wl1273-core.c b/drivers/mfd/wl1273-core.c
new file mode 100644
index 000..77b9442
--- /dev/null
+++ b/drivers/mfd/wl1273-core.c
@@ -0,0 +1,1825 @@
+/*
+ * MFD driver for wl1273 FM radio and audio codec submodules.
+ *
+ * Author: Matti Aaltonen matti.j.aalto...@nokia.com
+ *
+ * Copyright:   (C) 2010 Nokia Corporation
+ *
+ * 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.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA
+ * 02110-1301 USA
+ *
+ */
+
+#undef DEBUG
+
+#include asm/unaligned.h
+#include linux/completion.h
+#include linux/delay.h
+#include linux/firmware.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/module.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/fs.h
+#include linux/platform_device.h
+#include linux/mfd/core.h
+#include linux/mfd/wl1273-core.h
+#include media/v4l2-common.h
+
+#define DRIVER_DESC WL1273 FM Radio Core
+
+#define WL1273_FR_EVENT(1  0)
+#define WL1273_BL_EVENT(1  1)
+#define WL1273_RDS_EVENT   (1  2)
+#define WL1273_BBLK_EVENT  (1  3)
+#define WL1273_LSYNC_EVENT (1  4)
+#define WL1273_LEV_EVENT   (1  5)
+#define WL1273_IFFR_EVENT  (1  6)
+#define WL1273_PI_EVENT(1  7)
+#define WL1273_PD_EVENT(1  8)
+#define WL1273_STIC_EVENT  (1  9)
+#define WL1273_MAL_EVENT   (1  10)
+#define WL1273_POW_ENB_EVENT   (1  11)
+#define WL1273_SCAN_OVER_EVENT (1  12)
+#define WL1273_ERROR_EVENT (1  13)
+
+#define WL1273_IRQ_MASK (WL1273_FR_EVENT   |   \
+ WL1273_POW_ENB_EVENT)
+
+/* I2S protocol, left channel first, data width 16 bits */
+#define WL1273_PCM_DEF_MODE0x00
+
+/* Rx */
+#define WL1273_AUDIO_ENABLE_I2S(1  0)
+#define WL1273_AUDIO_ENABLE_ANALOG (1  1)
+
+/* Tx */
+#define WL1273_AUDIO_IO_SET_ANALOG 0
+#define WL1273_AUDIO_IO_SET_I2S1
+
+#define WL1273_POWER_SET_OFF   0
+#define WL1273_POWER_SET_FM(1  0)
+#define WL1273_POWER_SET_RDS   (1  1)
+#define WL1273_POWER_SET_RETENTION (1  4)
+
+#define WL1273_PUPD_SET_OFF0x00
+#define WL1273_PUPD_SET_ON 0x01
+#define WL1273_PUPD_SET_RETENTION  0x10
+
+#define TUNER_MODE_STOP_SEARCH 0
+#define TUNER_MODE_PRESET  1
+#define TUNER_MODE_AUTO_SEEK   2
+#define TUNER_MODE_AF  3
+
+/* I2S mode */
+#define WL1273_IS2_WIDTH_320x0
+#define WL1273_IS2_WIDTH_400x1
+#define WL1273_IS2_WIDTH_22_23 0x2
+#define WL1273_IS2_WIDTH_23_22 0x3
+#define WL1273_IS2_WIDTH_480x4
+#define WL1273_IS2_WIDTH_500x5
+#define WL1273_IS2_WIDTH_600x6
+#define WL1273_IS2_WIDTH_640x7
+#define WL1273_IS2_WIDTH_800x8
+#define WL1273_IS2_WIDTH_960x9
+#define WL1273_IS2_WIDTH_128   0xa
+#define WL1273_IS2_WIDTH   0xf
+
+#define 

[PATCH 0/3] Driver for TI WL1273 FM radio.

2010-04-20 Thread Matti J. Aaltonen
Hi.

This is the initial version of my driver for Texas Instruments
WL1273 FM receiver transmitter. The driver is divided into three parts:
the MFD core which handles the communication with the chip and also
keeps the chip state, ASoC codec takes care of the digital audio part and
the V4L2 control part with some private IOCTLs.

This is my first up-streaming effort so all comments are welcome.

Cheers,
Matti

Matti J. Aaltonen (3):
  MFD: WL1273 FM Radio: MFD driver for the FM radio.
  ASoC: WL1273 FM Radio: Digital audio codec.
  V4L2: WL1273 FM Radio: Controls for the FM radio.

 drivers/media/radio/Kconfig|   15 +
 drivers/media/radio/Makefile   |1 +
 drivers/media/radio/radio-wl1273.c |  805 
 drivers/mfd/Kconfig|6 +
 drivers/mfd/Makefile   |2 +
 drivers/mfd/wl1273-core.c  | 1825 
 include/linux/mfd/wl1273-core.h|  265 ++
 sound/soc/codecs/Kconfig   |6 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/wl1273.c  |  708 ++
 sound/soc/codecs/wl1273.h  |   49 +
 11 files changed, 3684 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/radio/radio-wl1273.c
 create mode 100644 drivers/mfd/wl1273-core.c
 create mode 100644 include/linux/mfd/wl1273-core.h
 create mode 100644 sound/soc/codecs/wl1273.c
 create mode 100644 sound/soc/codecs/wl1273.h

--
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: cx5000 default auto sleep mode

2010-04-20 Thread Timothy D. Lenz



On 4/14/2010 10:40 AM, Devin Heitmueller wrote:

On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com  wrote:

Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
Dual express. Didn't know linux supported an auto sleep mode on the tuner
chips and that it defaulted to on. Seems like it would be better to default
to off. If someone wants an auto power down/sleep mode and their software
supports it, then let the program activate it. Seems people are more likely
to want the tuners to stay on then keep shutting down.

Spent over a year trying to figure out why vdr would loose control of 1 of
the dual tuners when the atscepg pluging was used thinking it was a problem
with the plugin.


The xc5000 power management changes I made were actually pretty
thoroughly tested with that card (between myself and Michael Krufky,
we tested it with just about every card that uses the tuner).  In
fact, we uncovered several power management bugs in other drivers as a
result of that effort.  It was a grueling effort that I spent almost
three months working on.

Generally I agree with the premise that functionality like this should
only be enabled for boards it was tested with.  However, in this case
it actually was pretty extensively tested with all the cards in
question (including this one), and thus it was deemed safe to enable
by default.  We've had cases in the past where developers exercised
poor judgement and blindly turned on power management to make it work
with one card, disregarding the possible breakage that could occur
with other cards that use the same driver -- this was *not* one of
those cases.

If there is a bug, it should be pretty straightforward to fix provided
it can be reproduced.

Regarding the general assertion that the power management should be
disabled by default, I disagree.  The power savings is considerable,
the time to bring the tuner out of sleep is negligible, and it's
generally good policy.

Andy, do you have any actual details regarding the nature of the problem?

Devin



This morning a tuner was down. So the long runs it made, maybe where a 
fluke. I still have options xc5000 no_poweroff=1 debug=1. I posted new 
logs, to http://24.255.17.209:2400/vdr/logs/. The files with .new ext 
are the new ones with lognig when the tuner went down.

--
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] cx25821-video-upstream.c: Added severity to printk calls

2010-04-20 Thread Ricardo Maraschini
Signed-off-by: Ricardo Maraschini ricardo.marasch...@gmail.com

--- a/linux/drivers/staging/cx25821/cx25821-video-upstream.cSun Apr 18 
11:12:11 2010 -0300
+++ b/linux/drivers/staging/cx25821/cx25821-video-upstream.cTue Apr 20 
11:21:17 2010 -0300
@@ -257,7 +257,7 @@
 
if (!dev-_is_running) {
printk
-  (cx25821: No video file is currently running so return!\n);
+  (KERN_INFO cx25821: No video file is currently running so 
return!\n);
return;
}
/* Disable RISC interrupts */
@@ -345,19 +345,19 @@
 
if (IS_ERR(myfile)) {
const int open_errno = -PTR_ERR(myfile);
-   printk(%s(): ERROR opening file(%s) with errno = %d!\n,
+   printk(KERN_ERR %s(): ERROR opening file(%s) with errno = 
%d!\n,
   __func__, dev-_filename, open_errno);
return PTR_ERR(myfile);
} else {
if (!(myfile-f_op)) {
-   printk(%s: File has no file operations registered!,
+   printk(KERN_ERR %s: File has no file operations 
registered!,
   __func__);
filp_close(myfile, NULL);
return -EIO;
}
 
if (!myfile-f_op-read) {
-   printk(%s: File has no READ operations registered!,
+   printk(KERN_ERR %s: File has no READ operations 
registered!,
   __func__);
filp_close(myfile, NULL);
return -EIO;
@@ -410,7 +410,7 @@
container_of(work, struct cx25821_dev, _irq_work_entry);
 
if (!dev) {
-   printk(ERROR %s(): since container_of(work_struct) FAILED!\n,
+   printk(KERN_ERR ERROR %s(): since container_of(work_struct) 
FAILED!\n,
   __func__);
return;
}
@@ -436,12 +436,12 @@
 
if (IS_ERR(myfile)) {
const int open_errno = -PTR_ERR(myfile);
-   printk(%s(): ERROR opening file(%s) with errno = %d!\n,
+   printk(KERN_ERR %s(): ERROR opening file(%s) with errno = 
%d!\n,
   __func__, dev-_filename, open_errno);
return PTR_ERR(myfile);
} else {
if (!(myfile-f_op)) {
-   printk(%s: File has no file operations registered!,
+   printk(KERN_ERR %s: File has no file operations 
registered!,
   __func__);
filp_close(myfile, NULL);
return -EIO;
@@ -449,7 +449,7 @@
 
if (!myfile-f_op-read) {
printk
-   (%s: File has no READ operations registered!  
Returning.,
+   (KERN_ERR %s: File has no READ operations 
registered!  Returning.,
 __func__);
filp_close(myfile, NULL);
return -EIO;
@@ -525,7 +525,7 @@
 
if (!dev-_dma_virt_addr) {
printk
-   (cx25821: FAILED to allocate memory for Risc buffer! 
Returning.\n);
+   (KERN_ERR cx25821: FAILED to allocate memory for Risc 
buffer! Returning.\n);
return -ENOMEM;
}
 
@@ -546,7 +546,7 @@
 
if (!dev-_data_buf_virt_addr) {
printk
-   (cx25821: FAILED to allocate memory for data buffer! 
Returning.\n);
+   (KERN_ERR cx25821: FAILED to allocate memory for data 
buffer! Returning.\n);
return -ENOMEM;
}
 
@@ -641,20 +641,20 @@
} else {
if (status  FLD_VID_SRC_UF)
printk
-   (%s: Video Received Underflow Error Interrupt!\n,
+   (KERN_ERR %s: Video Received Underflow Error 
Interrupt!\n,
 __func__);
 
if (status  FLD_VID_SRC_SYNC)
-   printk(%s: Video Received Sync Error Interrupt!\n,
+   printk(KERN_ERR %s: Video Received Sync Error 
Interrupt!\n,
   __func__);
 
if (status  FLD_VID_SRC_OPC_ERR)
-   printk(%s: Video Received OpCode Error Interrupt!\n,
+   printk(KERN_ERR %s: Video Received OpCode Error 
Interrupt!\n,
   __func__);
}
 
if (dev-_file_status == END_OF_FILE) {
-   printk(cx25821: EOF Channel 1 Framecount = %d\n,
+   printk(KERN_ERR cx25821: EOF Channel 1 Framecount = %d\n,
   dev-_frame_count);
return -1;
}
@@ -794,7 +794,7 @@
int str_length = 0;
 
if (dev-_is_running) {
-   printk(Video Channel is still running so return!\n);
+   

Re: [PATCH] pxa_camera: move fifo reset direct before dma start

2010-04-20 Thread Robert Jarzmik
Guennadi Liakhovetski g.liakhovet...@gmx.de writes:

 Robert, what do you think? Are you still working with PXA camera?
Hi Guennadi,

Yes, I'm still working with pxa_camera :)

About the patch, I have a very good feeling about it. I have not tested it, but
it looks good to me. I'll assume Stefan has tested it, and if you want it,
please take my :
Acked-by: Robert Jarzmik robert.jarz...@free.fr

Cheers.

--
Robert
--
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/3] MFD: WL1273 FM Radio: MFD driver for the FM radio.

2010-04-20 Thread Jonathan Corbet
On Tue, 20 Apr 2010 18:20:05 +0300
Matti J. Aaltonen matti.j.aalto...@nokia.com wrote:

 This is a parent driver for two child drivers: the V4L2 driver and
 the ALSA codec driver. The MFD part provides the I2C communication
 to the device and the state handling.

So I was taking a quick look at this; it mostly looks OK (though I wonder
about all those symbol exports - does all that stuff need to be in the
core?).  One thing caught my eye, though:

 +int wl1273_fm_rds_off(struct wl1273_core *core)
 +{
 + struct device *dev = core-i2c_dev-dev;
 + int r;
 +
 + if (core-mode == WL1273_MODE_TX)
 + return 0;
 +
 + wait_for_completion_timeout(core-busy, msecs_to_jiffies(1000));

The use of a completion here looks like a mistake to me.  This isn't a
normal pattern, and I'm not quite sure what you're trying to do.  Here,
also, you're ignoring the return value, so you don't know if completion
was signaled or not.

If you look in functions like:

 +int wl1273_fm_set_rx_freq(struct wl1273_core *core, unsigned int freq)
 +{

[...]

 + INIT_COMPLETION(core-busy);
 + r = wl1273_fm_write_cmd(core, WL1273_TUNER_MODE_SET,
 + TUNER_MODE_PRESET);
 + if (r) {
 + complete(core-busy);
 + goto err;
 + }

What will prevent multiple threads from doing INIT_COMPLETION()
simultaneously?  It  looks racy to me.  What happens if multiple
threads try to wait simultaneously on the completion?

OK, looking further, you're not using it for mutual exclusion.  In fact,
you're not using anything for mutual exclusion; how do you prevent
concurrent access to the hardware registers?

What I would suggest you do is remove the completion in favor of a wait
queue which the interrupt handler can use to signal that something has
completed.  You can then use wait_event() to wait for a wakeup and test
that the specific condition you are waiting for has come to pass.

jon
--
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-04-20 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:Tue Apr 20 19:00:18 CEST 2010
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   14592:b438301e588f
git master:   f6760aa024199cfbce564311dc4bc4d47b6fb349
git media-master: 184b7c85f31583632ad00c062a295b622759eef3
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: OK
linux-2.6.33-armv5-davinci: OK
linux-2.6.34-rc1-armv5-davinci: OK
linux-2.6.32.6-armv5-ixp: OK
linux-2.6.33-armv5-ixp: OK
linux-2.6.34-rc1-armv5-ixp: OK
linux-2.6.32.6-armv5-omap2: OK
linux-2.6.33-armv5-omap2: OK
linux-2.6.34-rc1-armv5-omap2: OK
linux-2.6.22.19-i686: WARNINGS
linux-2.6.23.17-i686: WARNINGS
linux-2.6.24.7-i686: OK
linux-2.6.25.20-i686: OK
linux-2.6.26.8-i686: OK
linux-2.6.27.44-i686: OK
linux-2.6.28.10-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30.10-i686: OK
linux-2.6.31.12-i686: OK
linux-2.6.32.6-i686: OK
linux-2.6.33-i686: OK
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: OK
linux-2.6.33-mips: OK
linux-2.6.34-rc1-mips: OK
linux-2.6.32.6-powerpc64: OK
linux-2.6.33-powerpc64: OK
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: OK
linux-2.6.25.20-x86_64: OK
linux-2.6.26.8-x86_64: OK
linux-2.6.27.44-x86_64: OK
linux-2.6.28.10-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30.10-x86_64: OK
linux-2.6.31.12-x86_64: OK
linux-2.6.32.6-x86_64: OK
linux-2.6.33-x86_64: OK
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: OK
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/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.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


[PATCH] cx25821-video-upstream.c: Added severity to printk calls

2010-04-20 Thread Ricardo Maraschini
Signed-off-by: Ricardo Maraschini ricardo.marasch...@gmail.com

--- a/linux/drivers/staging/cx25821/cx25821-video-upstream.c    Sun
Apr 18 11:12:11 2010 -0300
+++ b/linux/drivers/staging/cx25821/cx25821-video-upstream.c    Tue
Apr 20 11:21:17 2010 -0300
@@ -257,7 +257,7 @@

       if (!dev-_is_running) {
               printk
-                  (cx25821: No video file is currently running so return!\n);
+                  (KERN_INFO cx25821: No video file is currently
running so return!\n);
               return;
       }
       /* Disable RISC interrupts */
@@ -345,19 +345,19 @@

       if (IS_ERR(myfile)) {
               const int open_errno = -PTR_ERR(myfile);
-               printk(%s(): ERROR opening file(%s) with errno = %d!\n,
+               printk(KERN_ERR %s(): ERROR opening file(%s) with
errno = %d!\n,
                      __func__, dev-_filename, open_errno);
               return PTR_ERR(myfile);
       } else {
               if (!(myfile-f_op)) {
-                       printk(%s: File has no file operations registered!,
+                       printk(KERN_ERR %s: File has no file
operations registered!,
                              __func__);
                       filp_close(myfile, NULL);
                       return -EIO;
               }

               if (!myfile-f_op-read) {
-                       printk(%s: File has no READ operations registered!,
+                       printk(KERN_ERR %s: File has no READ
operations registered!,
                              __func__);
                       filp_close(myfile, NULL);
                       return -EIO;
@@ -410,7 +410,7 @@
           container_of(work, struct cx25821_dev, _irq_work_entry);

       if (!dev) {
-               printk(ERROR %s(): since container_of(work_struct) FAILED!\n,
+               printk(KERN_ERR ERROR %s(): since
container_of(work_struct) FAILED!\n,
                      __func__);
               return;
       }
@@ -436,12 +436,12 @@

       if (IS_ERR(myfile)) {
               const int open_errno = -PTR_ERR(myfile);
-               printk(%s(): ERROR opening file(%s) with errno = %d!\n,
+               printk(KERN_ERR %s(): ERROR opening file(%s) with
errno = %d!\n,
                      __func__, dev-_filename, open_errno);
               return PTR_ERR(myfile);
       } else {
               if (!(myfile-f_op)) {
-                       printk(%s: File has no file operations registered!,
+                       printk(KERN_ERR %s: File has no file
operations registered!,
                              __func__);
                       filp_close(myfile, NULL);
                       return -EIO;
@@ -449,7 +449,7 @@

               if (!myfile-f_op-read) {
                       printk
-                           (%s: File has no READ operations
registered!  Returning.,
+                           (KERN_ERR %s: File has no READ operations
registered!  Returning.,
                            __func__);
                       filp_close(myfile, NULL);
                       return -EIO;
@@ -525,7 +525,7 @@

       if (!dev-_dma_virt_addr) {
               printk
-                   (cx25821: FAILED to allocate memory for Risc
buffer! Returning.\n);
+                   (KERN_ERR cx25821: FAILED to allocate memory for
Risc buffer! Returning.\n);
               return -ENOMEM;
       }

@@ -546,7 +546,7 @@

       if (!dev-_data_buf_virt_addr) {
               printk
-                   (cx25821: FAILED to allocate memory for data
buffer! Returning.\n);
+                   (KERN_ERR cx25821: FAILED to allocate memory for
data buffer! Returning.\n);
               return -ENOMEM;
       }

@@ -641,20 +641,20 @@
       } else {
               if (status  FLD_VID_SRC_UF)
                       printk
-                           (%s: Video Received Underflow Error Interrupt!\n,
+                           (KERN_ERR %s: Video Received Underflow
Error Interrupt!\n,
                            __func__);

               if (status  FLD_VID_SRC_SYNC)
-                       printk(%s: Video Received Sync Error Interrupt!\n,
+                       printk(KERN_ERR %s: Video Received Sync Error
Interrupt!\n,
                              __func__);

               if (status  FLD_VID_SRC_OPC_ERR)
-                       printk(%s: Video Received OpCode Error Interrupt!\n,
+                       printk(KERN_ERR %s: Video Received OpCode
Error Interrupt!\n,
                              __func__);
       }

       if (dev-_file_status == END_OF_FILE) {
-               printk(cx25821: EOF Channel 1 Framecount = %d\n,
+               printk(KERN_ERR cx25821: EOF Channel 1 Framecount = %d\n,
                      dev-_frame_count);
               return -1;
       }
@@ -794,7 +794,7 @@
       int str_length = 0;

       if (dev-_is_running) {
-               printk(Video Channel is still running so return!\n);
+               printk(KERN_INFO Video Channel is still running so return!\n);
               return 0;
       

Re: [PATCH 3/3] ir-core: add imon driver

2010-04-20 Thread Mauro Carvalho Chehab
Em Fri, 16 Apr 2010 17:29:02 -0400
Jarod Wilson ja...@redhat.com escreveu:

 
 This is a new driver for the SoundGraph iMON and Antec Veris IR/display
 devices commonly found in many home theater pc cases and as after-market
 case additions.


 +/* IR protocol: native iMON, Windows MCE (RC-6), or iMON w/o PAD stabilize */
 +static int ir_protocol;
 +module_param(ir_protocol, int, S_IRUGO | S_IWUSR);
 +MODULE_PARM_DESC(ir_protocol, Which IR protocol to use. 0=auto-detect, 
 +  1=Windows Media Center Ed. (RC-6), 2=iMON native, 
 +  4=iMON w/o PAD stabilize (default: auto-detect));
 +

You don't need this. Let's the protocol to be adjustable via sysfs. All you 
need to do is
to use the set_protocol callbacks with something like:

props-allowed_protos = IR_TYPE_RC6 | IR_TYPE_imon protocol;
props-change_protocol = imon_ir_change_protocol;

You can see an example of such implementation at 
drivers/media/video/em28xx-em28xx-input.c.
Look for em28xx_ir_change_protocol() function.

That's said, I'm not sure what would be better way to map IR_TYPE_imon 
protocol. Maybe we
can just use IR_TYPE_OTHER.

So, basically, we'll have:

IR_TYPE_OTHER | IR_TYPE_RC6 - auto-detected between RC-6 and iMON
IR_TYPE_OTHER   - iMON proprietary protocol
IR_TYPE_RC6 - RC-6 protocol


By doing this, the userspace application ir-keycode will already be able to 
handle the
IR protocol.

I'm not sure how to map the PAD stablilize case, but it seems that the better 
would be to
add a sysfs node for it, at sys/class/rc/rc0. There are other cases where some 
protocols
may require some adjustments, so I'm thinking on having some protocol-specific 
properties there.

Except for that, the patch looked sane to my eyes. So, I'll add it on my tree 
and wait for a
latter patch from you addressing the protocol control.

-- 

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: Fwd: Tevii S660 USB card and dw2102 module generating RC messages

2010-04-20 Thread Paul Shepherd


On 18/04/2010 08:19, william wrote:

Hello Paul,

I know what is happening but i have no solution.

The message: dw2102: query RC enter

is a message from the ir receiver in the device.
I noticed by accident that when you push some buttons on the remote
(which came with the tevii box) while tailing the log file you will see
the buttons on the remote.

i'm not sure because my device did not work at all so i send it back to
my supplier but i think the lib-s2planin drivers could fix it but i had
no chance to test it myself.
If you are going to try the s2planin drivers please let me know how it
works!

With kind regards

William




I also discovered that RC is remote control.  Tried the v4l-dvb in 
various combos which looked promising for a period but usually ended up 
with either the s660 or my nova dvb-t usb flooding the system and 
rendering the usb keyboard unsable.  Tried increasing the query time on 
the RC which seemed to help but still had problems.


Then tried s2-liplianin code at your suggestion which looked promising 
but it was strangely requesting a 2nd upload dvb-fe-ds3000.fw which 
although present in /lib/firmware didn't occur. Later it crashed:



Apr 18 23:23:12 antec300 kernel: [  324.866653] usb 1-1: new high speed USB 
device using ehci_hcd and address 4
Apr 18 23:23:12 antec300 kernel: [  325.458058] usb 1-1: new high speed USB 
device using ehci_hcd and address 5
Apr 18 23:23:12 antec300 kernel: [  325.590133] usb 1-1: configuration #1 
chosen from 1 choice
Apr 18 23:23:12 antec300 kernel: [  325.590330] dvb-usb: found a 'TeVii S660 
USB' in cold state, will try to load a firmware
Apr 18 23:23:12 antec300 kernel: [  325.590339] usb 1-1: firmware: requesting 
dvb-usb-s660.fw
Apr 18 23:23:12 antec300 kernel: [  325.595031] dvb-usb: downloading firmware 
from file 'dvb-usb-s660.fw'
Apr 18 23:23:12 antec300 kernel: [  325.595037] dw2102: start downloading 
DW210X firmware
Apr 18 23:23:12 antec300 kernel: [  325.713426] dvb-usb: found a 'TeVii S660 
USB' in warm state.
Apr 18 23:23:12 antec300 kernel: [  325.713479] dvb-usb: will pass the complete 
MPEG2 transport stream to the software demuxer.
Apr 18 23:23:12 antec300 kernel: [  325.717592] DVB: registering new adapter 
(TeVii S660 USB)
Apr 18 23:23:18 antec300 kernel: [  331.716487] dvb-usb: MAC address: 
00:00:a0:00:00:00
Apr 18 23:23:18 antec300 kernel: [  331.780801] input: IR-receiver inside an 
USB DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/input/input7
Apr 18 23:23:18 antec300 kernel: [  331.780862] dvb-usb: schedule remote query 
interval to 150 msecs.
Apr 18 23:23:18 antec300 kernel: [  331.780866] dvb-usb: TeVii S660 USB 
successfully initialized and connected.
Apr 18 23:23:18 antec300 kernel: [  331.780905] usb 1-1: USB disconnect, 
address 5
Apr 18 23:23:18 antec300 kernel: [  331.813419] dvb-usb: TeVii S660 USB 
successfully deinitialized and disconnected.
Apr 18 23:23:19 antec300 kernel: [  332.051995] usb 1-1: new high speed USB 
device using ehci_hcd and address 6
Apr 18 23:23:19 antec300 kernel: [  332.184522] usb 1-1: config 1 interface 0 
altsetting 0 bulk endpoint 0x81 has invalid maxpacket 2
Apr 18 23:23:19 antec300 kernel: [  332.185114] usb 1-1: configuration #1 
chosen from 1 choice
Apr 18 23:23:19 antec300 kernel: [  332.185298] dvb-usb: found a 'TeVii S660 
USB' in cold state, will try to load a firmware
Apr 18 23:23:19 antec300 kernel: [  332.185304] usb 1-1: firmware: requesting 
dvb-usb-s660.fw
Apr 18 23:23:19 antec300 kernel: [  332.190277] dvb-usb: downloading firmware 
from file 'dvb-usb-s660.fw'
Apr 18 23:23:19 antec300 kernel: [  332.190282] dw2102: start downloading 
DW210X firmware
Apr 18 23:23:19 antec300 kernel: [  332.307623] dvb-usb: found a 'TeVii S660 
USB' in warm state.
Apr 18 23:23:19 antec300 kernel: [  332.307676] dvb-usb: will pass the complete 
MPEG2 transport stream to the software demuxer.
Apr 18 23:23:19 antec300 kernel: [  332.307818] DVB: registering new adapter 
(TeVii S660 USB)
Apr 18 23:23:23 antec300 kernel: [  336.413508] dvb-usb: MAC address: 
00:18:bd:5c:60:b0
Apr 18 23:23:23 antec300 kernel: [  336.462191] DS3000 chip version: 0.192 
attached.
Apr 18 23:23:23 antec300 kernel: [  336.462195] dw2102: Attached ds3000+ds2020!
Apr 18 23:23:23 antec300 kernel: [  336.462197]
Apr 18 23:23:23 antec300 kernel: [  336.462202] DVB: registering adapter 1 
frontend 0 (Montage Technology DS3000/TS2020)...
Apr 18 23:23:23 antec300 kernel: [  336.463198] input: IR-receiver inside an 
USB DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/input/input8
Apr 18 23:23:23 antec300 kernel: [  336.463244] dvb-usb: schedule remote query 
interval to 150 msecs.
Apr 18 23:23:23 antec300 kernel: [  336.463250] dvb-usb: TeVii S660 USB 
successfully initialized and connected.
Apr 18 23:24:00 antec300 kernel: [  373.534616] ds3000_firmware_ondemand: 
Waiting for firmware upload (dvb-fe-ds3000.fw)...
Apr 18 23:24:00 antec300 kernel: [  373.534625] usb 1-1: firmware: requesting 

Re: cx5000 default auto sleep mode

2010-04-20 Thread Timothy D. Lenz



On 4/14/2010 10:40 AM, Devin Heitmueller wrote:

On Wed, Apr 14, 2010 at 1:29 PM, Timothy D. Lenztl...@vorgon.com  wrote:

Thanks to Andy Walls, found out why I kept loosing 1 tuner on a FusionHD7
Dual express. Didn't know linux supported an auto sleep mode on the tuner
chips and that it defaulted to on. Seems like it would be better to default
to off. If someone wants an auto power down/sleep mode and their software
supports it, then let the program activate it. Seems people are more likely
to want the tuners to stay on then keep shutting down.

Spent over a year trying to figure out why vdr would loose control of 1 of
the dual tuners when the atscepg pluging was used thinking it was a problem
with the plugin.


The xc5000 power management changes I made were actually pretty
thoroughly tested with that card (between myself and Michael Krufky,
we tested it with just about every card that uses the tuner).  In
fact, we uncovered several power management bugs in other drivers as a
result of that effort.  It was a grueling effort that I spent almost
three months working on.

Generally I agree with the premise that functionality like this should
only be enabled for boards it was tested with.  However, in this case
it actually was pretty extensively tested with all the cards in
question (including this one), and thus it was deemed safe to enable
by default.  We've had cases in the past where developers exercised
poor judgement and blindly turned on power management to make it work
with one card, disregarding the possible breakage that could occur
with other cards that use the same driver -- this was *not* one of
those cases.

If there is a bug, it should be pretty straightforward to fix provided
it can be reproduced.

Regarding the general assertion that the power management should be
disabled by default, I disagree.  The power savings is considerable,
the time to bring the tuner out of sleep is negligible, and it's
generally good policy.

Andy, do you have any actual details regarding the nature of the problem?

Devin



Went down a second time today, so copied the logs over again. If what is 
needed to fix this isn't in those, will have to look else where.

--
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: [PULL] http://linuxtv.org/hg/~endriss/ngene

2010-04-20 Thread Oliver Endriss
On Sunday 21 March 2010 21:15:01 Oliver Endriss wrote:
 Mauro,

 Please pull from http://linuxtv.org/hg/~endriss/ngene

 for the following changeset:

 01/01: ngene: Workaround for stuck DiSEqC pin
 http://linuxtv.org/hg/~endriss/ngene?cmd=changeset;node=1dc562463f63


  stv090x.c |4 
  1 file changed, 4 insertions(+)

 Thanks,
 Oliver

Ping!

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

--
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] s2255drv: cleanup of device structure

2010-04-20 Thread Mauro Carvalho Chehab
Hi Dean,

Em Mon, 12 Apr 2010 10:19:13 -0700 (PDT)
sensoray-dev linux-...@sensoray.com escreveu:

 # HG changeset patch
 # User Dean Anderson linux-...@sensoray.com
 # Date 1271092523 25200
 # Node ID 686a2330f4a6a4c79e299a17663f0f150031098e
 # Parent  f2f44853e2eb914d4fc6c7004631839b86fb6d0e
 s2255drv: cleanup of device structure
 
 From: Dean Anderson linux-...@sensoray.com
 
 cleanup of device structure
 better organization of channels instead of multiple arrays in device
 simplifies open callback by removing search for channel index
 adding v4l2_device_disconnect
 
 Priority: normal
 
 Signed-off-by: Dean Anderson linux-...@sensoray.com


Sorry, but the patch didn't apply:

patching file drivers/media/video/s2255drv.c
Hunk #1 succeeded at 190 (offset -1 lines).
Hunk #3 succeeded at 305 (offset -1 lines).
Hunk #5 succeeded at 577 (offset -1 lines).
Hunk #7 succeeded at 622 (offset -1 lines).
Hunk #9 succeeded at 661 (offset -1 lines).
Hunk #11 succeeded at 686 (offset -1 lines).
Hunk #13 succeeded at 754 (offset -1 lines).
Hunk #15 succeeded at 778 (offset -1 lines).
Hunk #17 succeeded at 893 (offset -1 lines).
Hunk #19 succeeded at 1013 (offset -1 lines).
Hunk #21 succeeded at 1243 (offset -1 lines).
Hunk #23 succeeded at 1307 (offset -1 lines).
Hunk #25 succeeded at 1353 (offset -1 lines).
Hunk #27 succeeded at 1414 (offset -1 lines).
Hunk #29 succeeded at 1435 (offset -1 lines).
Hunk #31 succeeded at 1477 (offset -1 lines).
Hunk #33 succeeded at 1531 (offset -1 lines).
Hunk #35 succeeded at 1584 (offset -1 lines).
Hunk #37 succeeded at 1632 (offset -1 lines).
Hunk #39 succeeded at 1711 (offset -1 lines).
Hunk #41 succeeded at 1843 (offset -1 lines).
Hunk #43 succeeded at 1925 (offset -1 lines).
Hunk #44 FAILED at 1947.
Hunk #45 succeeded at 2017 (offset 1 line).
Hunk #46 succeeded at 2044 (offset -1 lines).
Hunk #47 succeeded at 2065 (offset 1 line).
Hunk #48 succeeded at 2084 (offset -1 lines).
Hunk #49 succeeded at 2105 (offset 1 line).
Hunk #50 succeeded at 2132 (offset -1 lines).
Hunk #51 succeeded at 2228 (offset 1 line).
Hunk #52 succeeded at 2240 (offset -1 lines).
Hunk #53 succeeded at 2312 (offset 1 line).
Hunk #54 succeeded at 2337 (offset -1 lines).
Hunk #55 succeeded at 2437 (offset 1 line).
Hunk #56 succeeded at 2465 (offset -1 lines).
Hunk #57 succeeded at 2492 (offset 1 line).
Hunk #58 succeeded at 2548 (offset -1 lines).
Hunk #59 succeeded at 2587 (offset 1 line).
Hunk #60 succeeded at 2626 (offset -1 lines).
Hunk #61 succeeded at 2670 (offset 1 line).
1 out of 61 hunks FAILED -- saving rejects to file 
drivers/media/video/s2255drv.c.rej
 Patch patches/lmml_92061_s2255drv_cleanup_of_device_structure.patch doesn't 
 apply

I might try to fix the failed hunk, but I prefer if you could double check 
what's going
wrong, since this is a long patch that are replacing some structs.

Please use my -git tree as the basis, since Douglas is currently in a training
and it may take some time until he could be able to sync the -hg tree.




 
 diff -r f2f44853e2eb -r 686a2330f4a6 linux/drivers/media/video/s2255drv.c
 --- a/linux/drivers/media/video/s2255drv.cFri Apr 09 15:51:28 2010 -0700
 +++ b/linux/drivers/media/video/s2255drv.cMon Apr 12 10:15:23 2010 -0700
 @@ -191,7 +191,6 @@
  struct s2255_dmaqueue {
   struct list_headactive;
   struct s2255_dev*dev;
 - int channel;
  };
  
  /* for firmware loading, fw_state */
 @@ -226,51 +225,60 @@
  };
  
  struct s2255_fmt; /*forward declaration */
 +struct s2255_dev;
 +
 +struct s2255_channel {
 + struct video_device vdev;
 + int resources;
 + struct s2255_dmaqueue   vidq;
 + struct s2255_bufferibuffer;
 + struct s2255_mode   mode;
 + /* jpeg compression */
 + struct v4l2_jpegcompression jc;
 + /* capture parameters (for high quality mode full size) */
 + struct v4l2_captureparm cap_parm;
 + int cur_frame;
 + int last_frame;
 +
 + int b_acquire;
 + /* allocated image size */
 + unsigned long   req_image_size;
 + /* received packet size */
 + unsigned long   pkt_size;
 + int bad_payload;
 + unsigned long   frame_count;
 + /* if JPEG image */
 + int jpg_size;
 + /* if channel configured to default state */
 + int configured;
 + wait_queue_head_t   wait_setmode;
 + int setmode_ready;
 + /* video status items */
 + int vidstatus;
 + wait_queue_head_t   wait_vidstatus;
 + int vidstatus_ready;
 + unsigned intwidth;
 + unsigned intheight;
 + const struct s2255_fmt  *fmt;
 + int idx; /* channel number on device, 0-3 */
 +};
 +
  
  struct s2255_dev {
 - struct video_device vdev[MAX_CHANNELS];
 + struct 

Re: tm6000: firmware

2010-04-20 Thread Mauro Carvalho Chehab
Em Thu, 15 Apr 2010 21:28:39 +0200
Stefan Ringel stefan.rin...@arcor.de escreveu:

 Am 15.04.2010 19:14, schrieb Mauro Carvalho Chehab:
  Em 15-04-2010 07:37, Stefan Ringel escreveu:

  Am 14.04.2010 23:06, schrieb Mauro Carvalho Chehab:
  
  Em 14-04-2010 11:41, Stefan Ringel escreveu:


  Am 14.04.2010 19:44, schrieb Mauro Carvalho Chehab:
  
  
  Hi Stefan,
 
  Em 14-04-2010 09:26, Stefan Ringel escreveu:



  Hi Mauro,
 
  Can you added these three firmwares? The third is into archive file,
  because I'm extracted for an user (Bee Hock Goh).
  
  
  
  Sorry, but for us to put the firmwares at the server and/or add them at 
  linux-firmware 
  git tree, we need to get the distribution rights from the manufacturer,
  as described on:
  
  http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches#Firmware_submission
 
  So, we need Xceive's ack, in order to add the firmware files somewhere. 
  That's why
  currently we're using the procedure described on the comments at the 
  extraction
  tool:
  Documentation/video4linux/extract_xc3028.pl  
 
  Cheers,
  Mauro



  OK. In the archive is the modified extract_xc3028 tool for
  tm6000-xc3028.fw . Is that useful?
  
  
  Yes, but:
 
  1) Please, send it as a patch, with the proper SOB;
 
  2) From a diff I did here:
 
  -   my $sourcefile = UDXTTM6000.sys;
  -   my $hash = cb9deb5508a5e150af2880f5b0066d78;
  -   my $outfile = tm6000-xc3028.fw;
  +   my $sourcefile = hcw85bda.sys;
  +   my $hash = 0e44dbf63bb0169d57446aec21881ff2;
  +   my $outfile = xc3028-v27.fw;
 
  This version works with another *.sys file. The proper way is to
  check for the hash, and use the proper logic, based on the provided
  sys file;
 
  3) Please document where to get the UDXTTTM6000.sys file at the 
  comments;
 
  4) tm6000-xc3028.fw is a really bad name. It made sense only during
  the development of tuner-xc2028.c, since, on that time, it seemed that
  tm6000 had a different firmware version. In fact, the first devices
  appeared with v 1.e firmware. So, a proper name for that version
  would be xc3028-v1e.fw. We should rename it to be consistent.
 


  The firmware name is was you write in tm6000-card.c file and yes it can
  renamed. This firmware work in tm5600 and tm6000 sticks where the
  firmware v2.7 or v3.6 not works. The version isn't v1.e , it is v2.4 see
  log file from Bee Hock Goh (
  
  Ok. then, please send me a patch renaming the firmware used by this card as
  xc3028-v24.fw.
 
  I won't be able to apply any patch until next week (I'm currently abroad for
  the Collaboration Summit).
 

  http://www.mail-archive.com/linux-media@vger.kernel.org/msg17378.html ).
  
  It is not clear what version is provided with this version. Is it
  v3.6? On a few cases, we've seen some modified versions of XC3028 
  firmwares
  shipped with some specific board. Is it the case?

  With respect to your patch, you need to add some logic to decide to generate
  either v2.4 or v2.7, based on the *.sys checksum code. So, instead of just
  renaming things, the proper solution is to create two sub-routines: one for
  v2.7 and another for v2.4, and decide to use either one, based on the 
  checksum
  of the *.sys file.
 

 I have generated new the patch.

Much better! Yet:

+verify($sourcefile_24, $hash_24);
+   verify($sourcefile_27, $hash_27);
+
+   open INFILE, $sourcefile_24;
+   main_firmware_24($outfile_24, $name_24, $version_24, 
$nr_desc_24);
+   close INFILE;
+
+   open INFILE, $sourcefile_27;
+   main_firmware_27($outfile_27, $name_27, $version_27, 
$nr_desc_27);
close INFILE;
 }

Users shouldn't be forced to download both files, as just one file is needed 
for a given device. 
So, instead, the tool should test if the file exists, and handle only the found 
file(s).

-- 

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