Re: [linux-dvb] Rotor not working Skystar hd2(VP1041/STB0899) S2API MYTHTV

[Hartmut]

Hi Tonda,

I can not help you with this topic, but you can tell me (us) wether you
are able to receive HDTV with this card? I'm not ...

Hartmut


kutil2010 schrieb:
 I have the same problem. Skystar HD2, a new S2-liplianin driver and
 motor Optikum DM3800 don't spin. Of course extra power cord connected.
 Logs without mistake. Is somebody, who knows the solution?

 Tonda

 ___
 linux-dvb users mailing list
 For V4L/DVB development, please use instead linux-media@vger.kernel.org
 linux-...@linuxtv.org
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb


   

--
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: Compile error saa7134 - compro videomate S350

[Dominic Fernandes]

Hi Hermann,

 unload the driver with modprobe -vr saa7134-alsa saa7134-dvb.

When I tried this I got the message FATAL: saa7134-alsa is in use (or 
something like that).

You might have to close mixers using saa7134-alsa previously.
 With modinfo saa7134 you get available options.

I wasn't sure what to look for here, there was a lot of info. being displayed.

I carried on with modprobe -v saa7134 card=169 command.  I ran dmesg to see 
the status of the card.  It did get the card id 169 but the board decription 
came up as unknown instead of the name of the videomate S350.  Is this expected?

The modification of the GPIO address Instead of 0x8000 used in Jan's patch, 
use 0xC000 for GPIO setup I'm not sure what I changed was the correct value.  
Looking at the code lines I found relate to the Remote that I had changed 
(saa7134-cards.c):


+   case SAA7134_BOARD_VIDEOMATE_S350:
+   dev-has_remote = SAA7134_REMOTE_GPIO;
+   saa_andorl(SAA7134_GPIO_GPMODE0  2,   0x8000, 0x8000);
+   saa_andorl(SAA7134_GPIO_GPSTATUS0  2, 0x8000, 0x8000);
+   break;

Which leads to the question where the GPIO address of 0x8000 is currently 
specified?


Thanks,
Dominic




- Original Message 
From: hermann pitton hermann-pit...@arcor.de
To: Dominic Fernandes dalf...@yahoo.com
Cc: linux-media@vger.kernel.org
Sent: Wed, November 25, 2009 6:14:27 PM
Subject: Re: Compile error saa7134 - compro videomate S350

Hi Dominic,

Am Mittwoch, den 25.11.2009, 08:31 -0800 schrieb Dominic Fernandes:
 Hi Hermann,
 
 Thanks for your reply.  I'm a little lost in what to do next.
 
 How do I force the card to be recongised as card 169 (the compro videomate 
 S350) instead of card 139?

unload the driver with modprobe -vr saa7134-alsa saa7134-dvb.

You might have to close mixers using saa7134-alsa previously.
With modinfo saa7134 you get available options.

With modprobe -v saa7134 card=169 you can force that card then.

If we disable the T750 auto detection in saa7134-cards.c, both have to
force the correct card number.

Cheers,
Hermann


  

--
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] New driver for the radio FM module on Miro PCM20 sound card

[Krzysztof Helt]

From: Krzysztof Helt krzysztof...@wp.pl

This is recreated driver for the FM module found on Miro
PCM20 sound cards. This driver was removed around the 2.6.2x
kernels because it relied on the removed OSS module. Now, it
uses a current ALSA module (snd-miro) and is adapted to v4l2
layer.

It provides only basic functionality: frequency changing and
FM module muting.

Signed-off-by: Krzysztof Helt krzysztof...@wp.pl
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
---
This is the third version of the patch with fixed issues pointed
by Takashi Iwai.

 drivers/media/radio/Kconfig   |   18 +++
 drivers/media/radio/Makefile  |1 +
 drivers/media/radio/radio-miropcm20.c |  270 +
 3 files changed, 289 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/radio/radio-miropcm20.c

diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
index a87a477..b134553 100644
--- a/drivers/media/radio/Kconfig
+++ b/drivers/media/radio/Kconfig
@@ -195,6 +195,24 @@ config RADIO_MAESTRO
  To compile this driver as a module, choose M here: the
  module will be called radio-maestro.
 
+config RADIO_MIROPCM20
+   tristate miroSOUND PCM20 radio
+   depends on ISA  VIDEO_V4L2
+   select SND_MIRO
+   ---help---
+ Choose Y here if you have this FM radio card. You also need to enable
+ the ALSA sound system. This choice automatically selects the ALSA
+ sound card driver Miro miroSOUND PCM1pro/PCM12/PCM20radio as this
+ is required for the radio-miropcm20.
+
+ In order to control your radio card, you will need to use programs
+ that are compatible with the Video For Linux API.  Information on
+ this API and pointers to v4l 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-miropcm20.
+
 config RADIO_SF16FMI
tristate SF16FMI Radio
depends on ISA  VIDEO_V4L2
diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
index 2a1be3b..8a63d54 100644
--- a/drivers/media/radio/Makefile
+++ b/drivers/media/radio/Makefile
@@ -18,6 +18,7 @@ obj-$(CONFIG_RADIO_TRUST) += radio-trust.o
 obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o
 obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o
 obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o
+obj-$(CONFIG_RADIO_MIROPCM20) += radio-miropcm20.o
 obj-$(CONFIG_USB_DSBR) += dsbr100.o
 obj-$(CONFIG_RADIO_SI470X) += si470x/
 obj-$(CONFIG_USB_MR800) += radio-mr800.o
diff --git a/drivers/media/radio/radio-miropcm20.c 
b/drivers/media/radio/radio-miropcm20.c
new file mode 100644
index 000..4ff8854
--- /dev/null
+++ b/drivers/media/radio/radio-miropcm20.c
@@ -0,0 +1,270 @@
+/* Miro PCM20 radio driver for Linux radio support
+ * (c) 1998 Ruurd Reitsma r.a.reit...@wbmt.tudelft.nl
+ * Thanks to Norberto Pellici for the ACI device interface specification
+ * The API part is based on the radiotrack driver by M. Kirkwood
+ * This driver relies on the aci mixer provided by the snd-miro
+ * ALSA driver.
+ * Look there for further info...
+ */
+
+/* What ever you think about the ACI, version 0x07 is not very well!
+ * I can't get frequency, 'tuner status', 'tuner flags' or mute/mono
+ * conditions...Robert
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-ioctl.h
+#include sound/aci.h
+
+static int radio_nr = -1;
+module_param(radio_nr, int, 0);
+MODULE_PARM_DESC(radio_nr, Set radio device number (/dev/radioX).  Default: 
-1 (autodetect));
+
+static int mono;
+module_param(mono, bool, 0);
+MODULE_PARM_DESC(mono, Force tuner into mono mode.);
+
+struct pcm20 {
+   struct v4l2_device v4l2_dev;
+   struct video_device vdev;
+   unsigned long freq;
+   int muted;
+   struct snd_miro_aci *aci;
+};
+
+static struct pcm20 pcm20_card = {
+   .freq   = 87*16000,
+   .muted  = 1,
+};
+
+static int pcm20_mute(struct pcm20 *dev, unsigned char mute)
+{
+   dev-muted = mute;
+   return snd_aci_cmd(dev-aci, ACI_SET_TUNERMUTE, mute, -1);
+}
+
+static int pcm20_stereo(struct pcm20 *dev, unsigned char stereo)
+{
+   return snd_aci_cmd(dev-aci, ACI_SET_TUNERMONO, !stereo, -1);
+}
+
+static int pcm20_setfreq(struct pcm20 *dev, unsigned long freq)
+{
+   unsigned char freql;
+   unsigned char freqh;
+   struct snd_miro_aci *aci = dev-aci;
+
+   dev-freq = freq;
+
+   freq /= 160;
+   if (!(aci-aci_version == 0x07 || aci-aci_version = 0xb0))
+   freq /= 10;  /* I don't know exactly which version
+ * needs this hack */
+   freql = freq  0xff;
+   freqh = freq  8;
+
+   pcm20_stereo(dev, !mono);
+   return snd_aci_cmd(aci, ACI_WRITE_TUNE, freql, freqh);
+}
+
+static const struct v4l2_file_operations pcm20_fops = {
+   .owner  

Re: [PATCH] New driver for the radio FM module on Miro PCM20 sound card

[Takashi Iwai]

At Fri, 27 Nov 2009 11:24:13 +0100,
Krzysztof Helt wrote:
 
 From: Krzysztof Helt krzysztof...@wp.pl
 
 This is recreated driver for the FM module found on Miro
 PCM20 sound cards. This driver was removed around the 2.6.2x
 kernels because it relied on the removed OSS module. Now, it
 uses a current ALSA module (snd-miro) and is adapted to v4l2
 layer.
 
 It provides only basic functionality: frequency changing and
 FM module muting.
 
 Signed-off-by: Krzysztof Helt krzysztof...@wp.pl
 Reviewed-by: Hans Verkuil hverk...@xs4all.nl
 ---
 This is the third version of the patch with fixed issues pointed
 by Takashi Iwai.

Thanks, I merged now this to sound tree exceptionally since it's purely
depends on snd-miro driver.  Will appear in the next linux-next.


Takashi

 
  drivers/media/radio/Kconfig   |   18 +++
  drivers/media/radio/Makefile  |1 +
  drivers/media/radio/radio-miropcm20.c |  270 
 +
  3 files changed, 289 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/radio/radio-miropcm20.c
 
 diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig
 index a87a477..b134553 100644
 --- a/drivers/media/radio/Kconfig
 +++ b/drivers/media/radio/Kconfig
 @@ -195,6 +195,24 @@ config RADIO_MAESTRO
 To compile this driver as a module, choose M here: the
 module will be called radio-maestro.
  
 +config RADIO_MIROPCM20
 + tristate miroSOUND PCM20 radio
 + depends on ISA  VIDEO_V4L2
 + select SND_MIRO
 + ---help---
 +   Choose Y here if you have this FM radio card. You also need to enable
 +   the ALSA sound system. This choice automatically selects the ALSA
 +   sound card driver Miro miroSOUND PCM1pro/PCM12/PCM20radio as this
 +   is required for the radio-miropcm20.
 +
 +   In order to control your radio card, you will need to use programs
 +   that are compatible with the Video For Linux API.  Information on
 +   this API and pointers to v4l 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-miropcm20.
 +
  config RADIO_SF16FMI
   tristate SF16FMI Radio
   depends on ISA  VIDEO_V4L2
 diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile
 index 2a1be3b..8a63d54 100644
 --- a/drivers/media/radio/Makefile
 +++ b/drivers/media/radio/Makefile
 @@ -18,6 +18,7 @@ obj-$(CONFIG_RADIO_TRUST) += radio-trust.o
  obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o
  obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o
  obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o
 +obj-$(CONFIG_RADIO_MIROPCM20) += radio-miropcm20.o
  obj-$(CONFIG_USB_DSBR) += dsbr100.o
  obj-$(CONFIG_RADIO_SI470X) += si470x/
  obj-$(CONFIG_USB_MR800) += radio-mr800.o
 diff --git a/drivers/media/radio/radio-miropcm20.c 
 b/drivers/media/radio/radio-miropcm20.c
 new file mode 100644
 index 000..4ff8854
 --- /dev/null
 +++ b/drivers/media/radio/radio-miropcm20.c
 @@ -0,0 +1,270 @@
 +/* Miro PCM20 radio driver for Linux radio support
 + * (c) 1998 Ruurd Reitsma r.a.reit...@wbmt.tudelft.nl
 + * Thanks to Norberto Pellici for the ACI device interface specification
 + * The API part is based on the radiotrack driver by M. Kirkwood
 + * This driver relies on the aci mixer provided by the snd-miro
 + * ALSA driver.
 + * Look there for further info...
 + */
 +
 +/* What ever you think about the ACI, version 0x07 is not very well!
 + * I can't get frequency, 'tuner status', 'tuner flags' or mute/mono
 + * conditions...Robert
 + */
 +
 +#include linux/module.h
 +#include linux/init.h
 +#include linux/videodev2.h
 +#include media/v4l2-device.h
 +#include media/v4l2-ioctl.h
 +#include sound/aci.h
 +
 +static int radio_nr = -1;
 +module_param(radio_nr, int, 0);
 +MODULE_PARM_DESC(radio_nr, Set radio device number (/dev/radioX).  Default: 
 -1 (autodetect));
 +
 +static int mono;
 +module_param(mono, bool, 0);
 +MODULE_PARM_DESC(mono, Force tuner into mono mode.);
 +
 +struct pcm20 {
 + struct v4l2_device v4l2_dev;
 + struct video_device vdev;
 + unsigned long freq;
 + int muted;
 + struct snd_miro_aci *aci;
 +};
 +
 +static struct pcm20 pcm20_card = {
 + .freq   = 87*16000,
 + .muted  = 1,
 +};
 +
 +static int pcm20_mute(struct pcm20 *dev, unsigned char mute)
 +{
 + dev-muted = mute;
 + return snd_aci_cmd(dev-aci, ACI_SET_TUNERMUTE, mute, -1);
 +}
 +
 +static int pcm20_stereo(struct pcm20 *dev, unsigned char stereo)
 +{
 + return snd_aci_cmd(dev-aci, ACI_SET_TUNERMONO, !stereo, -1);
 +}
 +
 +static int pcm20_setfreq(struct pcm20 *dev, unsigned long freq)
 +{
 + unsigned char freql;
 + unsigned char freqh;
 + struct snd_miro_aci *aci = dev-aci;
 +
 + dev-freq = freq;
 +
 + freq /= 160;
 + if (!(aci-aci_version == 0x07 || aci-aci_version = 0xb0))
 + freq /= 10;  /* I don't know exactly which version
 +  

Re: [PATCH] New driver for the radio FM module on Miro PCM20 sound card

[Mauro Carvalho Chehab]

Krzysztof Helt wrote:
 From: Krzysztof Helt krzysztof...@wp.pl
 
 This is recreated driver for the FM module found on Miro
 PCM20 sound cards. This driver was removed around the 2.6.2x
 kernels because it relied on the removed OSS module. Now, it
 uses a current ALSA module (snd-miro) and is adapted to v4l2
 layer.
 
 It provides only basic functionality: frequency changing and
 FM module muting.
 
 Signed-off-by: Krzysztof Helt krzysztof...@wp.pl
 Reviewed-by: Hans Verkuil hverk...@xs4all.nl

Acked-by: Mauro Carvalho Chehab mche...@redhat.com

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

High cpu load (dvb_usb_dib0700)

[Markus Suvanto]

Hauppauge Nova-T 500 Dual DVB-T generates
high cpu load even if there is nothing going on.
For example:

#!/bin/bash

echo rmmod  dvb_usb_dib0700
rmmod  dvb_usb_dib0700

for ((i=0; i10; i++))
do
cat /proc/loadavg
sleep 30
done

echo modprobe  dvb_usb_dib0700
modprobe  dvb_usb_dib0700

for ((i=0; i10; i++))
do
cat /proc/loadavg
sleep 30
done


rmmod  dvb_usb_dib0700
0.51 0.50 0.47 1/289 8253
0.51 0.50 0.47 1/289 8261
0.31 0.45 0.45 1/289 8269
0.18 0.41 0.43 1/289 8277
0.11 0.37 0.42 1/289 8285
0.07 0.33 0.40 1/289 8295
0.04 0.30 0.39 1/289 8303
0.26 0.33 0.40 1/288 8312
0.16 0.30 0.38 1/289 8321
0.09 0.27 0.37 1/289 8330
modprobe  dvb_usb_dib0700
0.13 0.25 0.36 2/291 8355
0.16 0.24 0.35 1/289 8370
0.64 0.35 0.38 1/289 8378
0.78 0.41 0.40 1/289 8386
0.58 0.40 0.40 1/289 8394
0.35 0.36 0.38 1/289 8404
0.21 0.32 0.37 1/289 8412
0.52 0.39 0.38 1/289 8433
0.84 0.48 0.41 1/289 8441
0.75 0.49 0.42 1/289 8450

Kernel:  2.6.32-rc8  (+
git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git
drm-linus)

Linux 2.6.32-rc8-00020-g5349ef3 #29 SMP Tue Nov 24 09:52:05 EET 2009
x86_64 AMD Phenom(tm) II X3 705e Processor AuthenticAMD GNU/Linux

Gnu C  4.3.4
Gnu make   3.81
binutils   2.18
util-linux 2.14.2
mount  support
module-init-tools  3.5
e2fsprogs  1.41.3
PPP2.4.4
Linux C Library2.9
Dynamic linker (ldd)   2.9
Procps 3.2.8
Net-tools  1.60
Kbd1.13
Sh-utils   7.5
wireless-tools 29
Modules Loaded dvb_usb_dib0700 ipv6 snd_seq_dummy snd_seq_oss
snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss
libafs af_packet bridge stp llc tun bitrev kvm_amd kvm option btrfs
zlib_deflate cryptomgr aead pcompress crypto_blkcipher crc32c
libcrc32c crypto_hash crypto_algapi mt2060 usbserial mousedev usbhid
usbmouse dib7000p dib7000m dib0070 dvb_usb dib3000mc dib8000
dibx000_common dvb_core usb_storage firewire_ohci radeon ohci_hcd
ehci_hcd uhci_hcd ttm firewire_core drm_kms_helper drm usbcore
firmware_class crc_itu_t i2c_algo_bit i2c_piix4 ohci1394 ata_generic
pata_acpi snd_hda_codec_atihdmi ieee1394 processor cfbcopyarea thermal
snd_hda_codec_via i2c_core atl1e thermal_sys snd_hda_intel nls_base
snd_hda_codec pata_atiixp rtc_cmos atkbd snd_pcm floppy snd_timer
rtc_core pcspkr snd rtc_lib sg 8250_pnp cfbimgblt cfbfillrect
soundcore 8250 asus_atk0110 evdev serial_core psmouse snd_page_alloc
hwmon serio_raw button unix ext4 jbd2 crc16 dm_mod raid1 md_mod sd_mod
ahci libata scsi_mod fbcon tileblit crc32 font bitblit softcursor fb

-Markus
--
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 3/3] pxa_camera: remove init() callback

[Guennadi Liakhovetski]

On Tue, 17 Nov 2009, Antonio Ospite wrote:

 pxa_camera init() callback is sometimes abused to setup MFP for PXA CIF, or
 even to request GPIOs to be used by the camera *sensor*. These initializations
 can be performed statically in machine init functions.
 
 The current semantics for this init() callback is ambiguous anyways, it is
 invoked in pxa_camera_activate(), hence at device node open, but its users use
 it like a generic initialization to be done at module init time (configure
 MFP, request GPIOs for *sensor* control).
 
 Signed-off-by: Antonio Ospite osp...@studenti.unina.it

Antonio, to make the merging easier and avoid imposing extra dependencies, 
I would postpone this to 2.6.34, and just remove uses of .init() by 
pxa-camera users as per your other two patches. Would this be ok with you?

Thanks
Guennadi

 ---
  arch/arm/mach-pxa/include/mach/camera.h |2 --
  drivers/media/video/pxa_camera.c|   10 --
  2 files changed, 0 insertions(+), 12 deletions(-)
 
 diff --git a/arch/arm/mach-pxa/include/mach/camera.h 
 b/arch/arm/mach-pxa/include/mach/camera.h
 index 31abe6d..6709b1c 100644
 --- a/arch/arm/mach-pxa/include/mach/camera.h
 +++ b/arch/arm/mach-pxa/include/mach/camera.h
 @@ -35,8 +35,6 @@
  #define PXA_CAMERA_VSP   0x400
  
  struct pxacamera_platform_data {
 - int (*init)(struct device *);
 -
   unsigned long flags;
   unsigned long mclk_10khz;
  };
 diff --git a/drivers/media/video/pxa_camera.c 
 b/drivers/media/video/pxa_camera.c
 index 51b683c..49f2bf9 100644
 --- a/drivers/media/video/pxa_camera.c
 +++ b/drivers/media/video/pxa_camera.c
 @@ -882,18 +882,8 @@ static void recalculate_fifo_timeout(struct 
 pxa_camera_dev *pcdev,
  
  static void pxa_camera_activate(struct pxa_camera_dev *pcdev)
  {
 - struct pxacamera_platform_data *pdata = pcdev-pdata;
 - struct device *dev = pcdev-soc_host.v4l2_dev.dev;
   u32 cicr4 = 0;
  
 - dev_dbg(dev, Registered platform device at %p data %p\n,
 - pcdev, pdata);
 -
 - if (pdata  pdata-init) {
 - dev_dbg(dev, %s: Init gpios\n, __func__);
 - pdata-init(dev);
 - }
 -
   /* disable all interrupts */
   __raw_writel(0x3ff, pcdev-base + CICR0);
  
 -- 
 1.6.5.2
 

---
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: [PATCH 2/2 v2] soc-camera: convert to the new mediabus API

[Hans Verkuil]

Hi Guennadi,

 Convert soc-camera core and all soc-camera drivers to the new mediabus
 API. This also takes soc-camera client drivers one step closer to also be
 usable with generic v4l2-subdev host drivers.

Just a quick question:

 @@ -323,28 +309,39 @@ static int mt9m001_s_fmt(struct v4l2_subdev *sd,
 struct v4l2_format *f)
   /* No support for scaling so far, just crop. TODO: use skipping */
   ret = mt9m001_s_crop(sd, a);
   if (!ret) {
 - pix-width = mt9m001-rect.width;
 - pix-height = mt9m001-rect.height;
 - mt9m001-fourcc = pix-pixelformat;
 + mf-width   = mt9m001-rect.width;
 + mf-height  = mt9m001-rect.height;
 + mt9m001-fmt= soc_mbus_find_datafmt(mf-code,
 + mt9m001-fmts, mt9m001-num_fmts);
 + mf-colorspace  = mt9m001-fmt-colorspace;
   }

   return ret;
  }

 -static int mt9m001_try_fmt(struct v4l2_subdev *sd, struct v4l2_format *f)
 +static int mt9m001_try_fmt(struct v4l2_subdev *sd,
 +struct v4l2_mbus_framefmt *mf)
  {
   struct i2c_client *client = sd-priv;
   struct mt9m001 *mt9m001 = to_mt9m001(client);
 - struct v4l2_pix_format *pix = f-fmt.pix;
 + const struct soc_mbus_datafmt *fmt;

 - v4l_bound_align_image(pix-width, MT9M001_MIN_WIDTH,
 + v4l_bound_align_image(mf-width, MT9M001_MIN_WIDTH,
   MT9M001_MAX_WIDTH, 1,
 - pix-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
 + mf-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
   MT9M001_MAX_HEIGHT + mt9m001-y_skip_top, 0, 0);

 - if (pix-pixelformat == V4L2_PIX_FMT_SBGGR8 ||
 - pix-pixelformat == V4L2_PIX_FMT_SBGGR16)
 - pix-height = ALIGN(pix-height - 1, 2);
 + if (mt9m001-fmts == mt9m001_colour_fmts)
 + mf-height = ALIGN(mf-height - 1, 2);
 +
 + fmt = soc_mbus_find_datafmt(mf-code, mt9m001-fmts,
 + mt9m001-num_fmts);
 + if (!fmt) {
 + fmt = mt9m001-fmt;
 + mf-code = fmt-code;
 + }
 +
 + mf-colorspace  = fmt-colorspace;

   return 0;
  }

Why do the sensor drivers use soc_mbus_find_datafmt? They only seem to be
interested in the colorspace field, but I don't see the reason for that.
Most if not all sensors have a fixed colorspace depending on the
pixelcode, so they can just ignore the colorspace that the caller
requested and replace it with their own.

I didn't have time for a full review, so I might have missed something.

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: how to get a registered adapter name

[Brice Dubost]

Benedict bdc091 wrote:
 Hi list,
 
 I'd like to enumerate connected DVB devices from my softawre, based on
 DVB API V3.
 Thank to ioctl FE_GET_INFO, I'm able to get frontends name, but they
 are not clear enough for users.
 
 After a quick look in /var/log/messages I discovered that adapters
 name are much expressives:
 
 ...
 DVB: registering new adapter (ASUS My Cinema U3000 Mini DVBT Tuner)
 DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)...
 ...
 
 So, I tried to figure out a way to get ASUS My Cinema U3000 Mini DVBT
 Tuner string from adapter, instead of DiBcom 7000PC from adapter's
 frontend...
 Unsuccefully so far.
 
 Any suggestions?
 

Hello,

I have the same issue, I look a bit to the code of the DVB drivers, it
seems not obvious to recover this name as it is written now

It is stored in the struct dvb_adapter. and printed by
dvb_register_adapter, but doesn't seems to be available by other functions

I don't think changing the v3 API or adding a new IOCTL for this is a
good idea.

What about using the new DVB API (v5) to do this? Since I'm not an
expert with this API, is there some people familiar with it which can
give me advices about the good way to do it (and if it is a good idea)
so that I can start to write some code.

Thank you

Regards
--
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 3/3] pxa_camera: remove init() callback

[Antonio Ospite]

On Fri, 27 Nov 2009 15:06:53 +0100 (CET)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:

 On Tue, 17 Nov 2009, Antonio Ospite wrote:
 
  pxa_camera init() callback is sometimes abused to setup MFP for PXA CIF, or
  even to request GPIOs to be used by the camera *sensor*. These 
  initializations
  can be performed statically in machine init functions.
  
  The current semantics for this init() callback is ambiguous anyways, it is
  invoked in pxa_camera_activate(), hence at device node open, but its users 
  use
  it like a generic initialization to be done at module init time (configure
  MFP, request GPIOs for *sensor* control).
  
  Signed-off-by: Antonio Ospite osp...@studenti.unina.it
 
 Antonio, to make the merging easier and avoid imposing extra dependencies, 
 I would postpone this to 2.6.34, and just remove uses of .init() by 
 pxa-camera users as per your other two patches. Would this be ok with you?
 
 Thanks
 Guennadi


Perfectly fine with me.

Feel also free to anticipate me and edit the commit messages to
whatever you want in the first two patches. Now that we aren't removing
init() immediately after these it makes even more sense to change the
phrasing from a future referencing
init() is going to be removed
to a more present focused
better not to use init() at all
form.

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


pgpWQ1eKqkrY5.pgp
Description: PGP signature

Re: [PATCH 2/2 v2] soc-camera: convert to the new mediabus API

[Guennadi Liakhovetski]

On Fri, 27 Nov 2009, Hans Verkuil wrote:

 Hi Guennadi,
 
  Convert soc-camera core and all soc-camera drivers to the new mediabus
  API. This also takes soc-camera client drivers one step closer to also be
  usable with generic v4l2-subdev host drivers.
 
 Just a quick question:
 
  @@ -323,28 +309,39 @@ static int mt9m001_s_fmt(struct v4l2_subdev *sd,
  struct v4l2_format *f)
  /* No support for scaling so far, just crop. TODO: use skipping */
  ret = mt9m001_s_crop(sd, a);
  if (!ret) {
  -   pix-width = mt9m001-rect.width;
  -   pix-height = mt9m001-rect.height;
  -   mt9m001-fourcc = pix-pixelformat;
  +   mf-width   = mt9m001-rect.width;
  +   mf-height  = mt9m001-rect.height;
  +   mt9m001-fmt= soc_mbus_find_datafmt(mf-code,
  +   mt9m001-fmts, mt9m001-num_fmts);
  +   mf-colorspace  = mt9m001-fmt-colorspace;
  }
 
  return ret;
   }
 
  -static int mt9m001_try_fmt(struct v4l2_subdev *sd, struct v4l2_format *f)
  +static int mt9m001_try_fmt(struct v4l2_subdev *sd,
  +  struct v4l2_mbus_framefmt *mf)
   {
  struct i2c_client *client = sd-priv;
  struct mt9m001 *mt9m001 = to_mt9m001(client);
  -   struct v4l2_pix_format *pix = f-fmt.pix;
  +   const struct soc_mbus_datafmt *fmt;
 
  -   v4l_bound_align_image(pix-width, MT9M001_MIN_WIDTH,
  +   v4l_bound_align_image(mf-width, MT9M001_MIN_WIDTH,
  MT9M001_MAX_WIDTH, 1,
  -   pix-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
  +   mf-height, MT9M001_MIN_HEIGHT + mt9m001-y_skip_top,
  MT9M001_MAX_HEIGHT + mt9m001-y_skip_top, 0, 0);
 
  -   if (pix-pixelformat == V4L2_PIX_FMT_SBGGR8 ||
  -   pix-pixelformat == V4L2_PIX_FMT_SBGGR16)
  -   pix-height = ALIGN(pix-height - 1, 2);
  +   if (mt9m001-fmts == mt9m001_colour_fmts)
  +   mf-height = ALIGN(mf-height - 1, 2);
  +
  +   fmt = soc_mbus_find_datafmt(mf-code, mt9m001-fmts,
  +   mt9m001-num_fmts);
  +   if (!fmt) {
  +   fmt = mt9m001-fmt;
  +   mf-code = fmt-code;
  +   }
  +
  +   mf-colorspace  = fmt-colorspace;
 
  return 0;
   }
 
 Why do the sensor drivers use soc_mbus_find_datafmt? They only seem to be
 interested in the colorspace field, but I don't see the reason for that.
 Most if not all sensors have a fixed colorspace depending on the
 pixelcode, so they can just ignore the colorspace that the caller
 requested and replace it with their own.

Right, that's exactly what's done here. mt9m001 and mt9v022 drivers 
support different formats, depending on the exact detected or specified by 
the user model. That's why they have to search for the requested format in 
supported list. and then - yes, they just put the found format into user 
request:

  +   mf-colorspace  = fmt-colorspace;

 I didn't have time for a full review, so I might have missed something.

Thanks
Guennadi
---
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: [PATCH 3/3] pxa_camera: remove init() callback

[Guennadi Liakhovetski]

On Fri, 27 Nov 2009, Antonio Ospite wrote:

 On Fri, 27 Nov 2009 15:06:53 +0100 (CET)
 Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
 
  On Tue, 17 Nov 2009, Antonio Ospite wrote:
  
   pxa_camera init() callback is sometimes abused to setup MFP for PXA CIF, 
   or
   even to request GPIOs to be used by the camera *sensor*. These 
   initializations
   can be performed statically in machine init functions.
   
   The current semantics for this init() callback is ambiguous anyways, it is
   invoked in pxa_camera_activate(), hence at device node open, but its 
   users use
   it like a generic initialization to be done at module init time (configure
   MFP, request GPIOs for *sensor* control).
   
   Signed-off-by: Antonio Ospite osp...@studenti.unina.it
  
  Antonio, to make the merging easier and avoid imposing extra dependencies, 
  I would postpone this to 2.6.34, and just remove uses of .init() by 
  pxa-camera users as per your other two patches. Would this be ok with you?
  
  Thanks
  Guennadi
 
 
 Perfectly fine with me.
 
 Feel also free to anticipate me and edit the commit messages to
 whatever you want in the first two patches. Now that we aren't removing
 init() immediately after these it makes even more sense to change the
 phrasing from a future referencing
   init() is going to be removed
 to a more present focused
   better not to use init() at all
 form.

I cannot edit those subject lines, because I will not be handling those 
patches, they will go via the PXA tree, that's why it is easier to wait 
with the pxa patch.

Thanks
Guennadi
---
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: [PATCH 3/3] pxa_camera: remove init() callback

[Antonio Ospite]

On Fri, 27 Nov 2009 15:37:19 +0100 (CET)
Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:

 On Fri, 27 Nov 2009, Antonio Ospite wrote:
 
  On Fri, 27 Nov 2009 15:06:53 +0100 (CET)
  Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
  
   On Tue, 17 Nov 2009, Antonio Ospite wrote:
   
pxa_camera init() callback is sometimes abused to setup MFP for PXA 
CIF, or
even to request GPIOs to be used by the camera *sensor*. These 
initializations
can be performed statically in machine init functions.

The current semantics for this init() callback is ambiguous anyways, it 
is
invoked in pxa_camera_activate(), hence at device node open, but its 
users use
it like a generic initialization to be done at module init time 
(configure
MFP, request GPIOs for *sensor* control).

Signed-off-by: Antonio Ospite osp...@studenti.unina.it
   
   Antonio, to make the merging easier and avoid imposing extra 
   dependencies, 
   I would postpone this to 2.6.34, and just remove uses of .init() by 
   pxa-camera users as per your other two patches. Would this be ok with you?
   
   Thanks
   Guennadi
  
  
  Perfectly fine with me.
  
  Feel also free to anticipate me and edit the commit messages to
  whatever you want in the first two patches. Now that we aren't removing
  init() immediately after these it makes even more sense to change the
  phrasing from a future referencing
  init() is going to be removed
  to a more present focused
  better not to use init() at all
  form.
 
 I cannot edit those subject lines, because I will not be handling those 
 patches, they will go via the PXA tree, that's why it is easier to wait 
 with the pxa patch.


I see, I am sending a v2 for the first two patches with changed commit
messages in some hours then. Sorry for the delay.

 Thanks
 Guennadi
 ---
 Guennadi Liakhovetski, Ph.D.
 Freelance Open-Source Software Developer
 http://www.open-technology.de/

Regards,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


pgpELo6MV1WoT.pgp
Description: PGP signature

Re: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

[Jon Smirl]

On Fri, Nov 27, 2009 at 2:33 AM, Christoph Bartelmus l...@bartelmus.de wrote:
 Hi Jon,

 on 27 Nov 09 at 00:06, Jon Smirl wrote:
 [...]
 code for the fun of it, I have no commercial interest in IR. I was
 annoyed with how LIRC handled Sony remotes on my home system.

 Can you elaborate on this?
 I'm not aware of any issue with Sony remotes.

irrecord can't figure out that Sony remotes transmit multiple
protocols so it reverts to raw mode. When trying to figure that out I
started working on the concept of running simultaneous state machines
to decode the pulse timings.  I also had an embedded system with an IR
receiver hooked to a timer input pin.  I started off with a
implementation that ran multiple Sony protocol decoders and used the
input from the timer pin. I know now that I could use irrecord
individually for each group of keys on the Sony remote and then glue
the flies together. But that's the path that caused me to write the
code.

Also throw into pot that I had previously had some very bad
experiences trying to deal with the old mouse and kbd device inside of
the X server. I was aware that evdev was designed to fix all of those
problems. That made me want a fully evdev based design.


 Christoph
 --
 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




-- 
Jon Smirl
jonsm...@gmail.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: [PATCH/RFC v2] V4L core cleanups HG tree

[Steven Toth]

 I can't wait for an explicit ack from all maintainers (mostly because I
  don't know you all), so I'll send a pull request in a week if there's no
  blocking issue. I'd like this to get in 2.6.33 if possible.

 I have a pile of testing in the next few days. In light of Devin's
 OOPS I'll test the cx88 and cx23885 changes and report back by sunday.

 Thanks for the cleanups Laurent.

I'm fine with the cx88 and cx23885 changes.

Acked-By: Steven Toth st...@kernellabs.com


-- 
Steven Toth - Kernel Labs
http://www.kernellabs.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

[RFC] What are the goals for the architecture of an in-kernel IR system?

[Jon Smirl]

On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
christ...@bartelmus.de wrote:
 Hi Mauro,

 on 26 Nov 09 at 14:25, Mauro Carvalho Chehab wrote:
 Christoph Bartelmus wrote:
 [...]
 But I'm still a bit hesitant about the in-kernel decoding. Maybe it's just
 because I'm not familiar at all with input layer toolset.
 [...]
 I hope it helps for you to better understand how this works.

 So the plan is to have two ways of using IR in the future which are
 incompatible to each other, the feature-set of one being a subset of the
 other?

Take advantage of the fact that we don't have a twenty year old legacy
API already in the kernel. Design an IR API that uses current kernel
systems. Christoph, ignore the code I wrote and make a design proposal
that addresses these goals...

1) Unified input in Linux using evdev. IR is on equal footing with
mouse and keyboard.
2) plug and play for basic systems - you only need an external app for scripting
3) No special tools - use mkdir, echo, cat, shell scripts to build maps
4) Use of modern Linux features like sysfs, configfs and udev.
5) Direct multi-app support - no daemon
6) Hide timing data from user as much as possible.

What are other goals for this subsystem?

Maybe we decide to take the existing LIRC system as is and not
integrate it into the input subsystem. But I think there is a window
here to update the LIRC design to use the latest kernel features. We
don't want to build another /dev/mouse and have to rip it out in five
years.


 When designing the key mapping in the kernel you should be aware that
 there are remotes out there that send a sequence of scan codes for some
 buttons, e.g.
 http://lirc.sourceforge.net/remotes/pioneer/CU-VSX159

This is good input.


-- 
Jon Smirl
jonsm...@gmail.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: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Andy Walls]

On Fri, 2009-11-27 at 10:57 -0500, Jon Smirl wrote:
 On Fri, Nov 27, 2009 at 2:45 AM, Christoph Bartelmus
 christ...@bartelmus.de wrote:

  So the plan is to have two ways of using IR in the future which are
  incompatible to each other, the feature-set of one being a subset of the
  other?
 
 Take advantage of the fact that we don't have a twenty year old legacy
 API already in the kernel. Design an IR API that uses current kernel
 systems. Christoph, ignore the code I wrote and make a design proposal
 that addresses these goals...

Jon,

It's good to have clear, sensible goals.  I'd also like to have
concurrence on what are driving requirements vs. nice-to-have's and also
on priorities.


 1) Unified input in Linux using evdev. IR is on equal footing with
 mouse and keyboard.

Sounds fine.  I think some of the discussion so far indicates the devil
may be in the details.  I understand the driving requirement is to avoid
user(?) problems experienced in the past with PS/2 keyboards, etc.


 2) plug and play for basic systems - you only need an external app for 
 scripting

I concur.  Users needing hardware to Just Work is *the* driving
requirment for in kernel IR from the discussion.  I would only say that
you may not need any application for the default configuration on basic
systems.


 3) No special tools - use mkdir, echo, cat, shell scripts to build maps

Sounds fine.  I also was a user who used setkeys, loadkeys, et. al. once
years ago, and can't remeber for the life of me why I had to do so or
how they work anymore.


 4) Use of modern Linux features like sysfs, configfs and udev.

I'm not sure this is strictly driven by anything; it's an implementation
decision stated in advance.  One uses features, if one needs them.


 5) Direct multi-app support - no daemon

I understand the rationale for this to really be a desire for minimal
userspace components.  If you think/know that the input system can
multiplex or multicast events in a sane way for applications, then I
suppose it's feasible.

I don't hear users asking for minimal userspace components, as their
dsitribution packaging system usually handles this for them.  I suspect
this is mostly driven by kernel developers or embedded systems
developers.


 6) Hide timing data from user as much as possible.

I do not strictly agree with this.  I understand this goal is to
insulate users from the low level details of IR protocols.  I think that
hinders users' ability to solve or diagnose problems on their own.  Some
people like details and flexible control.  I think users being able to
report about timing data of unknown remotes or protocols has value as
well.


 What are other goals for this subsystem?

7. Support IR transmit by applications.

8. Support IR transmit without using special applications - just cat,
mkdir, shell, etc.
(Following your lead here.)

9. For flexible IR transmit hardware, the one IR transmitter should be
capable of sending codes to STBs with different protocols or keymaps
(not at the same time of course).



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: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Jon Smirl]

On Fri, Nov 27, 2009 at 12:29 PM, Christoph Bartelmus l...@bartelmus.de wrote:
 Maybe we decide to take the existing LIRC system as is and not
 integrate it into the input subsystem. But I think there is a window
 here to update the LIRC design to use the latest kernel features.

 If it ain't broke, don't fix it.

 I'm also not against using the input layer where it makes sense.

 For devices that do the decoding in hardware, the only thing that I don't
 like about the current kernel implementation is the fact that there are
 mapping tables in the kernel source. I'm not aware of any tools that let
 you change them without writing some keymaps manually.

 I'm also not against in-kernel decoding in general. We already agreed last
 year that we can include an interface in lirc_dev that feeds the signal
 data to an in-kernel decoder if noone from userspace reads it. That's
 close to an one line change in lirc_dev. You won't have to change a single
 device driver for this. I think there also was common understanding that
 there will be cases where in-kernel decoding will not be possible for
 esoteric protocols and that there needs to be an interface to deliver the
 raw data to userspace.

 My point just is that it took LIRC a very long time until the most common
 protocols have been fully supported, with all the toggle bits, toggle
 masks, repeat codes, sequences, headers, differing gap values, etc. Or
 take a look at crappy hardware like the Igor Cesko's USB IR Receiver. This
 device cripples the incoming signal except RC-5 because it has a limited
 buffer size. LIRC happily accepts the data because it does not make any
 assumptions on the protocol or bit length. With the approach that you
 suggested for the in-kernel decoder, this device simply will not work for
 anything but RC-5. The devil is in all the details. If we decide to do the
 decoding in-kernel, how long do you think this solution will need to
 become really stable and mainline? Currently I don't even see any
 consensus on the interface yet. But maybe you will prove me wrong and it's
 just that easy to get it all working.
 I also understand that people want to avoid dependency on external
 userspace tools. All I can tell you is that the lirc tools already do
 support everything you need for IR control. And as it includes a lot of
 drivers that are implemented in userspace already, LIRC will just continue
 to do it's work even when there is an alternative in-kernel.
 If LIRC is being rejected I don't have a real problem with this either,
 but we finally need a decision because for me this is definitely the last
 attempt to get this into the kernel.

Christoph, take what you know from all of the years of working on LIRC
and design the perfect in-kernel system. This is the big chance to
redesign IR support and get rid of any past mistakes. Incorporate any
useful chunks of code and knowledge from the existing LIRC into the
new design. Drop legacy APIs, get rid of daemons, etc. You can do this
redesign in parallel with existing LIRC. Everyone can continue using
the existing code while the new scheme is being built. Think of it as
LIRC 2.0. You can lead this design effort, you're the most experience
developer in the IR area.  Take advantage of this window to make a
design that is fully integrated with Linux - put IR on equal footing
with the keyboard and mouse as it should be.

-- 
Jon Smirl
jonsm...@gmail.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: how to get a registered adapter name

[Matthias Schwarzott]

On Freitag, 27. November 2009, Brice Dubost wrote:
 Benedict bdc091 wrote:
  Hi list,
 
  I'd like to enumerate connected DVB devices from my softawre, based on
  DVB API V3.

  So, I tried to figure out a way to get ASUS My Cinema U3000 Mini DVBT
  Tuner string from adapter, instead of DiBcom 7000PC from adapter's
  frontend...
  Unsuccefully so far.
 
  Any suggestions?

 Hello,

 I have the same issue, I look a bit to the code of the DVB drivers, it
 seems not obvious to recover this name as it is written now

 It is stored in the struct dvb_adapter. and printed by
 dvb_register_adapter, but doesn't seems to be available by other functions


I think putting it somewhere into sysfs is a good idea (along with frontend 
name).
Best is to move all dvb sysfs-devices into a per adapter subdirectory.

Matthias
--
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

[PULL] http://mercurial.intuxication.org/hg/v4l-dvb-commits

[Igor M. Liplianin]

Mauro,

Please pull from http://mercurial.intuxication.org/hg/v4l-dvb-commits

for the following changeset:

01/01: Add support for yet another DvbWorld, TeVii and Prof USB devices
http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=ab7f084779b0


 Kconfig  |8 -
 dw2102.c |  456 ++-
 2 files changed, 315 insertions(+), 149 deletions(-)

Thanks,
Igor


--
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: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Ferenc Wagner]

Jon Smirl jonsm...@gmail.com writes:

 On Fri, Nov 27, 2009 at 12:29 PM, Christoph Bartelmus l...@bartelmus.de 
 wrote:

 Maybe we decide to take the existing LIRC system as is and not
 integrate it into the input subsystem. But I think there is a window
 here to update the LIRC design to use the latest kernel features.

 If it ain't broke, don't fix it.  [...]

 We already agreed last year that we can include an interface in
 lirc_dev that feeds the signal data to an in-kernel decoder if noone
 from userspace reads it.  [...]

 I also understand that people want to avoid dependency on external
 userspace tools. All I can tell you is that the lirc tools already do
 support everything you need for IR control. And as it includes a lot of
 drivers that are implemented in userspace already, LIRC will just continue
 to do it's work even when there is an alternative in-kernel.

 Christoph, take what you know from all of the years of working on LIRC
 and design the perfect in-kernel system.

Hi,

I'm reading this thread with great interest.  Thank you (plural) for the
very informative conversation, I think I learnt a lot.  But now I
somehow lost the point, please correct me if the following is wrong.

It looks like having lirc_dev (or a similar raw interface) is a must.
It could be disguised as an input device, or changed in various ways,
but is it worth the effort?  As I understand Christoph, he does not want
to do so, because he finds it wasted work, and also there's already a
*single* user space daemon using it and doing everything users could
want.  Except for plugplay.

On the other hand, a one-liner could make in-kernel decoding possible,
so those who haven't got lircd running could have plugplay easily, if
somebody writes the necessary in-kernel decoders to feed the input
subsystem (which lircd also does, through uinput).

But even if you can't find anybody at the moment to write those, this is
still good stuff (I don't know about the code), which is hurt by being
developed out of kernel.  Is there any reason to keep this so?
Admittedly, I don't know why /dev/mouse is evil, maybe I'd understand if
somebody pointed me to some reading.
-- 
Thanks,
Feri.
--
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: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Jon Smirl]

On Fri, Nov 27, 2009 at 2:03 PM, Ferenc Wagner wf...@niif.hu wrote:
 Jon Smirl jonsm...@gmail.com writes:

 On Fri, Nov 27, 2009 at 12:29 PM, Christoph Bartelmus l...@bartelmus.de 
 wrote:

 Maybe we decide to take the existing LIRC system as is and not
 integrate it into the input subsystem. But I think there is a window
 here to update the LIRC design to use the latest kernel features.

 If it ain't broke, don't fix it.  [...]

 We already agreed last year that we can include an interface in
 lirc_dev that feeds the signal data to an in-kernel decoder if noone
 from userspace reads it.  [...]

 I also understand that people want to avoid dependency on external
 userspace tools. All I can tell you is that the lirc tools already do
 support everything you need for IR control. And as it includes a lot of
 drivers that are implemented in userspace already, LIRC will just continue
 to do it's work even when there is an alternative in-kernel.

 Christoph, take what you know from all of the years of working on LIRC
 and design the perfect in-kernel system.

 Hi,

 I'm reading this thread with great interest.  Thank you (plural) for the
 very informative conversation, I think I learnt a lot.  But now I
 somehow lost the point, please correct me if the following is wrong.

 It looks like having lirc_dev (or a similar raw interface) is a must.
 It could be disguised as an input device, or changed in various ways,
 but is it worth the effort?  As I understand Christoph, he does not want
 to do so, because he finds it wasted work, and also there's already a
 *single* user space daemon using it and doing everything users could
 want.  Except for plugplay.

The high level summary:

LIRC has developed it's own way of doing things. It has its own device
protocol, user space daemon, tools, etc. No one is denying that all of
that works.

The alternative is to rework IR to use standard kernel interfaces
(evdev, sysfs, configfs), standard user space tools (udev, ls, mkdir,
cat) and make the daemon optional.

Since IR hasn't been added to the kernel yet we are still free to
design the user space API before locking it in stone for the next
twenty years.


This is an architectural debate, not a debate on specific features.



 On the other hand, a one-liner could make in-kernel decoding possible,
 so those who haven't got lircd running could have plugplay easily, if
 somebody writes the necessary in-kernel decoders to feed the input
 subsystem (which lircd also does, through uinput).

 But even if you can't find anybody at the moment to write those, this is
 still good stuff (I don't know about the code), which is hurt by being
 developed out of kernel.  Is there any reason to keep this so?
 Admittedly, I don't know why /dev/mouse is evil, maybe I'd understand if

/dev/mouse is evil because it is possible to read partial mouse
messages. evdev fixes things so that you only get complete messages.

 somebody pointed me to some reading.
 --
 Thanks,
 Feri.




-- 
Jon Smirl
jonsm...@gmail.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

[PATCH 1/3 v2] em-x270: don't use pxa_camera init() callback

[Antonio Ospite]

pxa_camera init() is ambiguous, it's better to statically configure the sensor.

Signed-off-by: Antonio Ospite osp...@studenti.unina.it
Acked-by: Mike Rapoport m...@compulab.co.il
---

The only change from previous version is the commit message, we don't want to
mention .init() removal yet. Since the code is not changed the ack from Mike
Rapoport still holds.

 arch/arm/mach-pxa/em-x270.c |9 +
 1 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index aec7f42..f71f34c 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -967,7 +967,7 @@ static inline void em_x270_init_gpio_keys(void) {}
 #if defined(CONFIG_VIDEO_PXA27x) || defined(CONFIG_VIDEO_PXA27x_MODULE)
 static struct regulator *em_x270_camera_ldo;
 
-static int em_x270_sensor_init(struct device *dev)
+static int em_x270_sensor_init(void)
 {
int ret;
 
@@ -996,7 +996,6 @@ static int em_x270_sensor_init(struct device *dev)
 }
 
 struct pxacamera_platform_data em_x270_camera_platform_data = {
-   .init   = em_x270_sensor_init,
.flags  = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN,
.mclk_10khz = 2600,
@@ -1049,8 +1048,10 @@ static struct platform_device em_x270_camera = {
 
 static void  __init em_x270_init_camera(void)
 {
-   pxa_set_camera_info(em_x270_camera_platform_data);
-   platform_device_register(em_x270_camera);
+   if (em_x270_sensor_init() == 0) {
+   pxa_set_camera_info(em_x270_camera_platform_data);
+   platform_device_register(em_x270_camera);
+   }
 }
 #else
 static inline void em_x270_init_camera(void) {}
-- 
1.6.5.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

[PATCH 2/3 v2] pcm990-baseboard: don't use pxa_camera init() callback

[Antonio Ospite]

pxa_camera init() is ambiguous, it's better to configure PXA CIF pins
statically in machine init function.

Signed-off-by: Antonio Ospite osp...@studenti.unina.it
---

The only change from previous version is the commit message, we don't want to
mention .init() removal yet.

 arch/arm/mach-pxa/pcm990-baseboard.c |8 +---
 1 files changed, 1 insertions(+), 7 deletions(-)

diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c 
b/arch/arm/mach-pxa/pcm990-baseboard.c
index bbda570..d5255ae 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -359,19 +359,12 @@ static unsigned long pcm990_camera_pin_config[] = {
GPIO44_CIF_LV,
 };
 
-static int pcm990_pxacamera_init(struct device *dev)
-{
-   pxa2xx_mfp_config(ARRAY_AND_SIZE(pcm990_camera_pin_config));
-   return 0;
-}
-
 /*
  * CICR4: PCLK_EN: Pixel clock is supplied by the sensor
  * MCLK_EN:Master clock is generated by PXA
  * PCP:Data sampled on the falling edge of pixel clock
  */
 struct pxacamera_platform_data pcm990_pxacamera_platform_data = {
-   .init   = pcm990_pxacamera_init,
.flags  = PXA_CAMERA_MASTER | PXA_CAMERA_DATAWIDTH_8 | 
PXA_CAMERA_DATAWIDTH_10 |
PXA_CAMERA_PCLK_EN | PXA_CAMERA_MCLK_EN/* | PXA_CAMERA_PCP*/,
.mclk_10khz = 1000,
@@ -532,6 +525,7 @@ void __init pcm990_baseboard_init(void)
pxa_set_ac97_info(NULL);
 
 #if defined(CONFIG_VIDEO_PXA27x) || defined(CONFIG_VIDEO_PXA27x_MODULE)
+   pxa2xx_mfp_config(ARRAY_AND_SIZE(pcm990_camera_pin_config));
pxa_set_camera_info(pcm990_pxacamera_platform_data);
 
i2c_register_board_info(0, ARRAY_AND_SIZE(pcm990_i2c_devices));
-- 
1.6.5.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 0/3] pxa_camera: remove init() callback

[Antonio Ospite]

On Tue, 17 Nov 2009 23:04:20 +0100
Antonio Ospite osp...@studenti.unina.it wrote:

 Hi,
 
 this series removes the init() callback from pxa_camera_platform_data, and
 fixes its users to do initialization statically at machine init time.
 
[...]
 Antonio Ospite (3):
   em-x270: don't use pxa_camera init() callback
   pcm990-baseboard: don't use pxa_camera init() callback

Eric, if Guennadi ACKs v2 for these two please apply them only, we are
postponing the third one, hence you can discard it.

   pxa_camera: remove init() callback
 

Thanks,
   Antonio

-- 
Antonio Ospite
http://ao2.it

PGP public key ID: 0x4553B001

A: Because it messes up the order in which people normally read text.
   See http://en.wikipedia.org/wiki/Posting_style
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


pgpuOgQu287IB.pgp
Description: PGP signature

KWorld 380U, qt1010, em28xx

[agris]

Hi,

I'm into problem with KWorld 380U (e1ba:e359) usb stick.

As I see in http://linuxtv.org/hg/v4l-dvb/, there is still no support for my
dvb-t stick, but there should be support for Kworld 355U, so in em28xx-cards.c
I have changed in line 1729 '(0xeb1a, 0xe355)' to '(0xeb1a, 0xe359)', compiled,
installed and loaded new modules.

After plugging in dvb-t usb stick, dmesg shows:
Nov 27 22:48:24 dtv kernel: usb 1-7: new high speed USB device using
ehci_hcd and address 9
Nov 27 22:48:24 dtv kernel: usb 1-7: New USB device found, idVendor=eb1a,
idProduct=e359
Nov 27 22:48:24 dtv kernel: usb 1-7: New USB device strings: Mfr=0,
Product=1, SerialNumber=0
Nov 27 22:48:24 dtv kernel: usb 1-7: Product: USB 2870 Device
Nov 27 22:48:24 dtv kernel: usb 1-7: configuration #1 chosen from 1 choice
Nov 27 22:48:24 dtv kernel: em28xx #0: chip ID is em2870
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 59
e3 c0 12 62 40 6a 22 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 10: 00 00 04 57 60 0d 00
00 60 00 00 00 02 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 20: 54 00 00 00 f0 10 01
00 00 00 00 00 5b 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02
20 01 01 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00
00 00 00 22 03 55 00 53 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38
00 37 00 30 00 20 00 44 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63
00 65 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00
Nov 27 22:48:24 dtv kernel: em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash =
0xa4317302
Nov 27 22:48:24 dtv kernel: em28xx #0: EEPROM info:
Nov 27 22:48:24 dtv kernel: em28xx #0:^INo audio on board.
Nov 27 22:48:24 dtv kernel: em28xx #0:^I500mA max power
Nov 27 22:48:24 dtv kernel: em28xx #0:^ITable at 0x04, strings=0x226a,
0x, 0x
Nov 27 22:48:24 dtv kernel: em28xx #0: Identified as Kworld 355 U DVB-T
(card=42)
Nov 27 22:48:24 dtv kernel: tuner 4-0062: chip found @ 0xc4 (em28xx #0)
Nov 27 22:48:24 dtv kernel: em28xx #0: v4l2 driver version 0.1.2
Nov 27 22:48:24 dtv kernel: em28xx #0: V4L2 video device registered as
/dev/video0


And still, no dvb devices made. Where did I go wrong and how to find the way to
solution of this problem?



Agris

--
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

cx25840: GPIO settings wrong for HVR-1850 IR Tx

[Andy Walls]

Steve,

This code in cx25840-core.c mucks up HVR-1850 IR Tx:

/* Drive GPIO2 direction and values for HVR1700
 * where an onboard mux selects the output of demodulator
 * vs the 417. Failure to set this results in no DTV.
 * It's safe to set this across all Hauppauge boards
 * currently, regardless of the board type.
 */
cx25840_write(client, 0x160, 0x1d);
cx25840_write(client, 0x164, 0x00);

This changes the IR_TX pin to act as GPIO_20 and defaults it to low,
keeping the IR Transmitter LED illuminated.

Setting register 0x160 to 0x1f makes the pin the IR Tx function again.
I don't want to hack it in there though, as I don't know the
implications for other CX2388[578] boards.  I also perceive the cx23885
module GPIOs could be an easy place to introduce regressions if not
careful.


Steve and Hans,

Any ideas?

I know on the list I had bantered around a configure, enable, set, get
etc v4l2_subdev ops for gpio, but I can't remember the details nor the
requirements.

The cx25840 module really needs a way for the cx23885 bridge driver to
set GPIOs cleanly.

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: [GIT PULL for 2.6.32] V4L/DVB updates

[Stefan Lippers-Hollmann]

Hi

On Friday 27 November 2009, Mauro Carvalho Chehab wrote:
 Hi Linus,
 
 Please pull from:
 
 ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git 
 for_linus
 
 For the following drivers and building fixes:
 
- radio-gemtek-pci: fix double mutex_lock
- v4l: add more missing linux/sched.h includes
- soc-camera: properly initialise the device object when reusing
- soc-camera: sh_mobile_ceu_camera: call pm_runtime_disable
- em28xx: fix Reddo DVB-C USB TV Box GPIO
- davinci: remove stray duplicate config pointer
- SMS_SIANO_MDTV should depend on HAS_DMA
- cxusb: Fix hang on DViCO FusionHDTV DVB-T Dual Digital 4 (rev 1)
- sh_mobile_ceu_camera: fix compile warning
- Fix wrong parameter order in memset
[...]

Please consider cherry picking the following two patches from Hans 
Verkuil [1]:
- add the missing s2250-loader.h
- s2250 mutex patch 

or revert the patch which broke compiling go7007-usb (imho it would be 
better to re-add the 2 externs [2], than throwing away the needed mutex 
conversion, but it would be an option)
Commit: fd9a40da1db372833e1af6397d2f6c94ceff3dad
V4L/DVB (12859): go7007: semaphore - mutex conversion

or mark CONFIG_VIDEO_GO7007_USB_S2250_BOARD as BROKEN, as it fails to 
compile since the afforementioned patch was merged on september 19th (this 
is a 2.6.31 -- 2.6.32 regression) [2,3].

Regards
Stefan Lippers-Hollmann

[1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg11736.html
[2] http://lkml.indiana.edu/hypermail/linux/kernel/0911.1/02303.html
[3] http://lkml.indiana.edu/hypermail/linux/kernel/0909.3/00062.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

Re: Compile error saa7134 - compro videomate S350

[hermann pitton]

Hi,

Am Freitag, den 27.11.2009, 02:12 -0800 schrieb Dominic Fernandes:
 Hi Hermann,
 
  unload the driver with modprobe -vr saa7134-alsa saa7134-dvb.
 
 When I tried this I got the message FATAL: saa7134-alsa is in use (or 
 something like that).

that are mixers and such using saa7134-alsa. They prevent you from
unloading saa7134 too. With options saa7134 alsa=0 the alsa device is
not created.

 You might have to close mixers using saa7134-alsa previously.
  With modinfo saa7134 you get available options.
 
 I wasn't sure what to look for here, there was a lot of info. being displayed.

I just tried to tell that you can force a card=number.

 I carried on with modprobe -v saa7134 card=169 command.  I ran dmesg to see 
 the status of the card.  It did get the card id 169 but the board decription 
 came up as unknown instead of the name of the videomate S350.  Is this 
 expected?

No, modprobe -v saa7134 should show if something in etc/modules.d
or /etc/modprobe.conf overrides your card=169 command line.

If I force a card=96 to card=169 it looks like that.

saa7130/34: v4l2 driver version 0.2.15 loaded
saa7133[0]: setting pci latency timer to 64
saa7133[0]: found at :04:01.0, rev: 209, irq: 22, latency: 64, mmio: 
0xfebff800
saa7133[0]: subsystem: 16be:0008, board: Compro VideoMate S350/S300 
[card=169,insmod option]
saa7133[0]: board init: gpio is 0
saa7133[0]: gpio: mode=0x0008000 in=0x000 out=0x0008000 [pre-init]
input: saa7134 IR (Compro VideoMate S3 as /class/input/input6
IRQ 22/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7133[0]: i2c eeprom 00: be 16 08 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7133[0]: i2c eeprom 20: 01 40 01 02 02 03 01 0f 0f ff 00 3c 02 51 96 2b
saa7133[0]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7133[0]: i2c eeprom 40: ff 28 00 c0 96 10 03 01 c0 1c fd 79 44 9f c2 8f
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
saa7133[1]: setting pci latency timer to 64
saa7133[1]: found at :04:02.0, rev: 209, irq: 20, latency: 64, mmio: 
0xfebff000
saa7133[1]: subsystem: 16be:0007, board: Medion Md8800 Quadro 
[card=96,autodetected]
saa7133[1]: board init: gpio is 0
saa7133[1]: gpio: mode=0x000 in=0x000 out=0x000 [pre-init]
IRQ 20/saa7133[1]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7133[1]: i2c eeprom 00: be 16 07 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[1]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7133[1]: i2c eeprom 20: 01 40 01 02 02 03 01 00 06 ff 00 23 02 51 96 2b
saa7133[1]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7133[1]: i2c eeprom 40: ff 28 00 c0 96 10 03 00 c0 1c fd 79 44 9f c2 8f

Note, saa7134 gpio_tracking=1 is enabled.
saa7133[0]: gpio: mode=0x0008000 in=0x000 out=0x0008000 [pre-init]

Means gpio 15 is set to 1, output.


 The modification of the GPIO address Instead of 0x8000 used in Jan's patch, 
 use 0xC000 for GPIO setup I'm not sure what I changed was the correct value. 
  Looking at the code lines I found relate to the Remote that I had changed 
 (saa7134-cards.c):
 
 
 + case SAA7134_BOARD_VIDEOMATE_S350:
 + dev-has_remote = SAA7134_REMOTE_GPIO;
 + saa_andorl(SAA7134_GPIO_GPMODE0  2,   0x8000, 0x8000);
 + saa_andorl(SAA7134_GPIO_GPSTATUS0  2, 0x8000, 0x8000);
 + break;
 
 Which leads to the question where the GPIO address of 0x8000 is currently 
 specified?

This is exactly caused by and only by the above, likely powering up some
chip.

If you change all to 0xc000, gpio 14 and 15 are set to 1, output.

Don't know what exactly is going on with your card variant, but such are
the reports.

Cheers,
Hermann




--
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 0/4 v10] Support for TVP7002 in DM365

[Santiago Nunez-Corrales]

This series of patches provide support for the TVP7002 decoder in DM365.

Support includes:

* Inclusion of the chip in v4l2 definitions
* Definition of TVP7002 specific data structures
* Kconfig and Makefile support

This series corrects many issued pointed out by Snehaprabha Narnakaje,
Muralidharan Karicheri, Vaibhav Hiremath and Hans Verkuil and solves
testing problems.  Tested on DM365 TI EVM with resolutions 720p,
10...@60, 576P and 480P with video capture application and video
output in 480P, 576P, 720P and 1080I. This driver depends upon
board-dm365-evm.c and vpfe_capture.c to be ready for complete
integration. Uses the new V4L2 DV API sent by Muralidharan Karicheri.
Removed shadow register values. Removed unnecesary power down and up
of the device (tests work fine). Improved readability.


--
Santiago Nunez-Corrales, Eng.
RidgeRun Engineering, LLC

Guayabos, Curridabat
San Jose, Costa Rica
+(506) 2271 1487
+(506) 8313 0536
http://www.ridgerun.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

[PATCH 2/4 v10] Definitions for TVP7002 in DM365

[santiago . nunez]

From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides the required definitions for the TVP7002 driver
in DM365.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 drivers/media/video/tvp7002_reg.h |  150 +
 include/media/tvp7002.h   |   57 ++
 2 files changed, 207 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/tvp7002_reg.h
 create mode 100644 include/media/tvp7002.h

diff --git a/drivers/media/video/tvp7002_reg.h 
b/drivers/media/video/tvp7002_reg.h
new file mode 100644
index 000..0e34ca9
--- /dev/null
+++ b/drivers/media/video/tvp7002_reg.h
@@ -0,0 +1,150 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Naming conventions
+ * --
+ *
+ * FDBK:  Feedback
+ * DIV:   Divider
+ * CTL:   Control
+ * SEL:   Select
+ * IN:Input
+ * OUT:   Output
+ * R: Red
+ * G: Green
+ * B: Blue
+ * OFF:   Offset
+ * THRS:  Threshold
+ * DGTL:  Digital
+ * LVL:   Level
+ * PWR:   Power
+ * MVIS:  Macrovision
+ * W: Width
+ * H: Height
+ * ALGN:  Alignment
+ * CLK:   Clocks
+ * TOL:   Tolerance
+ * BWTH:  Bandwidth
+ * COEF:  Coefficient
+ * STAT:  Status
+ * AUTO:  Automatic
+ * FLD:   Field
+ * L:Line
+ */
+
+#define TVP7002_CHIP_REV   0x00
+#define TVP7002_HPLL_FDBK_DIV_MSBS 0x01
+#define TVP7002_HPLL_FDBK_DIV_LSBS 0x02
+#define TVP7002_HPLL_CRTL  0x03
+#define TVP7002_HPLL_PHASE_SEL 0x04
+#define TVP7002_CLAMP_START0x05
+#define TVP7002_CLAMP_W0x06
+#define TVP7002_HSYNC_OUT_W0x07
+#define TVP7002_B_FINE_GAIN0x08
+#define TVP7002_G_FINE_GAIN0x09
+#define TVP7002_R_FINE_GAIN0x0a
+#define TVP7002_B_FINE_OFF_MSBS0x0b
+#define TVP7002_G_FINE_OFF_MSBS 0x0c
+#define TVP7002_R_FINE_OFF_MSBS 0x0d
+#define TVP7002_SYNC_CTL_1 0x0e
+#define TVP7002_HPLL_AND_CLAMP_CTL 0x0f
+#define TVP7002_SYNC_ON_G_THRS 0x10
+#define TVP7002_SYNC_SEPARATOR_THRS0x11
+#define TVP7002_HPLL_PRE_COAST 0x12
+#define TVP7002_HPLL_POST_COAST0x13
+#define TVP7002_SYNC_DETECT_STAT   0x14
+#define TVP7002_OUT_FORMATTER  0x15
+#define TVP7002_MISC_CTL_1 0x16
+#define TVP7002_MISC_CTL_2  0x17
+#define TVP7002_MISC_CTL_3  0x18
+#define TVP7002_IN_MUX_SEL_1   0x19
+#define TVP7002_IN_MUX_SEL_20x1a
+#define TVP7002_B_AND_G_COARSE_GAIN0x1b
+#define TVP7002_R_COARSE_GAIN  0x1c
+#define TVP7002_FINE_OFF_LSBS  0x1d
+#define TVP7002_B_COARSE_OFF   0x1e
+#define TVP7002_G_COARSE_OFF0x1f
+#define TVP7002_R_COARSE_OFF0x20
+#define TVP7002_HSOUT_OUT_START0x21
+#define TVP7002_MISC_CTL_4 0x22
+#define TVP7002_B_DGTL_ALC_OUT_LSBS0x23
+#define TVP7002_G_DGTL_ALC_OUT_LSBS 0x24
+#define TVP7002_R_DGTL_ALC_OUT_LSBS 0x25
+#define TVP7002_AUTO_LVL_CTL_ENABLE0x26
+#define TVP7002_DGTL_ALC_OUT_MSBS  0x27
+#define TVP7002_AUTO_LVL_CTL_FILTER0x28
+/* Reserved 0x29*/
+#define TVP7002_FINE_CLAMP_CTL 0x2a
+#define TVP7002_PWR_CTL0x2b
+#define TVP7002_ADC_SETUP  0x2c
+#define TVP7002_COARSE_CLAMP_CTL   0x2d
+#define TVP7002_SOG_CLAMP  0x2e
+#define TVP7002_RGB_COARSE_CLAMP_CTL   0x2f
+#define TVP7002_SOG_COARSE_CLAMP_CTL   0x30
+#define TVP7002_ALC_PLACEMENT  0x31
+/* Reserved 0x32 */
+/* Reserved 0x33 */
+#define TVP7002_MVIS_STRIPPER_W0x34
+#define TVP7002_VSYNC_ALGN 0x35
+#define TVP7002_SYNC_BYPASS0x36
+#define TVP7002_L_FRAME_STAT_LSBS  0x37
+#define TVP7002_L_FRAME_STAT_MSBS  0x38
+#define 

[PATCH 3/4 v10] TVP7002 driver for DM365

[santiago . nunez]

From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides the implementation of the TVP7002 decoder
driver for DM365. Implemented using the V4L2 DV presets API.
Removed shadow register values. Testing shows that the device
needs not to be powered down and up for correct behaviour.
Improved readability.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 drivers/media/video/tvp7002.c | 1230 +
 1 files changed, 1230 insertions(+), 0 deletions(-)
 create mode 100644 drivers/media/video/tvp7002.c

diff --git a/drivers/media/video/tvp7002.c b/drivers/media/video/tvp7002.c
new file mode 100644
index 000..071361e
--- /dev/null
+++ b/drivers/media/video/tvp7002.c
@@ -0,0 +1,1230 @@
+/* Texas Instruments Triple 8-/10-BIT 165-/110-MSPS Video and Graphics
+ * Digitizer with Horizontal PLL registers
+ *
+ * Copyright (C) 2009 Texas Instruments Inc
+ * Author: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
+ *
+ * This code is partially based upon the TVP5150 driver
+ * written by Mauro Carvalho Chehab (mche...@infradead.org),
+ * the TVP514x driver written by Vaibhav Hiremath hvaib...@ti.com
+ * and the TVP7002 driver in the TI LSP 2.10.00.14. Revisions by
+ * Muralidharan Karicheri and Snehaprabha Narnakaje (TI).
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+#include linux/delay.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/tvp7002.h
+#include media/v4l2-device.h
+#include media/v4l2-chip-ident.h
+#include tvp7002_reg.h
+
+MODULE_DESCRIPTION(TI TVP7002 Video and Graphics Digitizer driver);
+MODULE_AUTHOR(Santiago Nunez-Corrales santiago.nu...@ridgerun.com);
+MODULE_LICENSE(GPL);
+
+/* Module Name */
+#define TVP7002_MODULE_NAMEtvp7002
+
+/* I2C retry attempts */
+#define I2C_RETRY_COUNT(5)
+
+/* End of registers */
+#define TVP7002_EOR0x5c
+
+/* Read write definition for registers */
+#define TVP7002_READ   0
+#define TVP7002_WRITE  1
+#define TVP7002_RESERVED   2
+
+/* Interlaced vs progressive mask and shift */
+#define TVP7002_IP_SHIFT   5
+#define TVP7002_INPR_MASK  (0x01  TVP7002_IP_SHIFT)
+
+/* Shift for CPL and LPF registers */
+#define TVP7002_CL_SHIFT   8
+#define TVP7002_CL_MASK0x0f
+
+/* Debug functions */
+static int debug;
+module_param(debug, bool, 0644);
+MODULE_PARM_DESC(debug, Debug level (0-2));
+
+/* Structure for register values */
+struct i2c_reg_value {
+   u8 reg;
+   u8 value;
+   u8 type;
+};
+
+/*
+ * Register default values (according to tvp7002 datasheet)
+ * In the case of read-only registers, the value (0xff) is
+ * never written. R/W functionality is controlled by the
+ * writable bit in the register struct definition.
+ */
+static const struct i2c_reg_value tvp7002_init_default[] = {
+   { TVP7002_CHIP_REV, 0xff, TVP7002_READ },
+   { TVP7002_HPLL_FDBK_DIV_MSBS, 0x67, TVP7002_WRITE },
+   { TVP7002_HPLL_FDBK_DIV_LSBS, 0x20, TVP7002_WRITE },
+   { TVP7002_HPLL_CRTL, 0xa0, TVP7002_WRITE },
+   { TVP7002_HPLL_PHASE_SEL, 0x80, TVP7002_WRITE },
+   { TVP7002_CLAMP_START, 0x32, TVP7002_WRITE },
+   { TVP7002_CLAMP_W, 0x20, TVP7002_WRITE },
+   { TVP7002_HSYNC_OUT_W, 0x60, TVP7002_WRITE },
+   { TVP7002_B_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_G_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_R_FINE_GAIN, 0x00, TVP7002_WRITE },
+   { TVP7002_B_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_G_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_R_FINE_OFF_MSBS, 0x80, TVP7002_WRITE },
+   { TVP7002_SYNC_CTL_1, 0x20, TVP7002_WRITE },
+   { TVP7002_HPLL_AND_CLAMP_CTL, 0x2e, TVP7002_WRITE },
+   { TVP7002_SYNC_ON_G_THRS, 0x5d, TVP7002_WRITE },
+   { TVP7002_SYNC_SEPARATOR_THRS, 0x47, TVP7002_WRITE },
+   { TVP7002_HPLL_PRE_COAST, 0x00, TVP7002_WRITE },
+   { TVP7002_HPLL_POST_COAST, 0x00, TVP7002_WRITE },
+   { TVP7002_SYNC_DETECT_STAT, 0xff, TVP7002_READ },
+   { TVP7002_OUT_FORMATTER, 0x47, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_1, 0x01, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_2, 0x00, TVP7002_WRITE },
+   { TVP7002_MISC_CTL_3, 0x01, TVP7002_WRITE },
+   { TVP7002_IN_MUX_SEL_1, 0x00, TVP7002_WRITE },
+   { 

[PATCH 4/4 v10] Menu support for TVP7002 in DM365

[santiago . nunez]

From: Santiago Nunez-Corrales santiago.nu...@ridgerun.com

This patch provides menu configuration options for the TVP7002
decoder driver in DM365. Includes only TVP7002.

Signed-off-by: Santiago Nunez-Corrales santiago.nu...@ridgerun.com
---
 drivers/media/video/Kconfig  |9 +
 drivers/media/video/Makefile |1 +
 2 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index e6186b3..25f5735 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -392,6 +392,15 @@ config VIDEO_TVP5150
  To compile this driver as a module, choose M here: the
  module will be called tvp5150.
 
+config VIDEO_TVP7002
+   tristate Texas Instruments TVP7002 video decoder
+   depends on VIDEO_V4L2  I2C
+   ---help---
+ Support for the Texas Instruments TVP7002 video decoder.
+
+ To compile this driver as a module, choose M here: the
+ module will be called tvp7002.
+
 config VIDEO_VPX3220
tristate vpx3220a, vpx3216b  vpx3214c video decoders
depends on VIDEO_V4L2  I2C
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index e541932..a4fff2a 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_VIDEO_THS7303) += ths7303.o
 obj-$(CONFIG_VIDEO_VINO) += indycam.o
 obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o
 obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o
+obj-$(CONFIG_VIDEO_TVP7002) += tvp7002.o
 obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o
 obj-$(CONFIG_VIDEO_CS5345) += cs5345.o
 obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o
-- 
1.6.0.4

--
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: Compile error saa7134 - compro videomate S350

[Dominic Fernandes]

hi,

where does  options saa7134 alsa=0 need to be declared?  Is it in 
/etc/modprobe.d/options.conf ?  If so, it didn't work - FATAL: saa7134-alsa is 
in use

thanks,
Dominic



- Original Message 
From: hermann pitton hermann-pit...@arcor.de
To: Dominic Fernandes dalf...@yahoo.com
Cc: linux-media@vger.kernel.org
Sent: Fri, November 27, 2009 10:14:10 PM
Subject: Re: Compile error saa7134 - compro videomate S350

Hi,

Am Freitag, den 27.11.2009, 02:12 -0800 schrieb Dominic Fernandes:
 Hi Hermann,
 
  unload the driver with modprobe -vr saa7134-alsa saa7134-dvb.
 
 When I tried this I got the message FATAL: saa7134-alsa is in use (or 
 something like that).

that are mixers and such using saa7134-alsa. They prevent you from
unloading saa7134 too. With options saa7134 alsa=0 the alsa device is
not created.

 You might have to close mixers using saa7134-alsa previously.
  With modinfo saa7134 you get available options.
 
 I wasn't sure what to look for here, there was a lot of info. being displayed.

I just tried to tell that you can force a card=number.

 I carried on with modprobe -v saa7134 card=169 command.  I ran dmesg to see 
 the status of the card.  It did get the card id 169 but the board decription 
 came up as unknown instead of the name of the videomate S350.  Is this 
 expected?

No, modprobe -v saa7134 should show if something in etc/modules.d
or /etc/modprobe.conf overrides your card=169 command line.

If I force a card=96 to card=169 it looks like that.

saa7130/34: v4l2 driver version 0.2.15 loaded
saa7133[0]: setting pci latency timer to 64
saa7133[0]: found at :04:01.0, rev: 209, irq: 22, latency: 64, mmio: 
0xfebff800
saa7133[0]: subsystem: 16be:0008, board: Compro VideoMate S350/S300 
[card=169,insmod option]
saa7133[0]: board init: gpio is 0
saa7133[0]: gpio: mode=0x0008000 in=0x000 out=0x0008000 [pre-init]
input: saa7134 IR (Compro VideoMate S3 as /class/input/input6
IRQ 22/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7133[0]: i2c eeprom 00: be 16 08 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[0]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7133[0]: i2c eeprom 20: 01 40 01 02 02 03 01 0f 0f ff 00 3c 02 51 96 2b
saa7133[0]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7133[0]: i2c eeprom 40: ff 28 00 c0 96 10 03 01 c0 1c fd 79 44 9f c2 8f
saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
saa7133[0]: registered device video0 [v4l2]
saa7133[0]: registered device vbi0
saa7133[1]: setting pci latency timer to 64
saa7133[1]: found at :04:02.0, rev: 209, irq: 20, latency: 64, mmio: 
0xfebff000
saa7133[1]: subsystem: 16be:0007, board: Medion Md8800 Quadro 
[card=96,autodetected]
saa7133[1]: board init: gpio is 0
saa7133[1]: gpio: mode=0x000 in=0x000 out=0x000 [pre-init]
IRQ 20/saa7133[1]: IRQF_DISABLED is not guaranteed on shared IRQs
saa7133[1]: i2c eeprom 00: be 16 07 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
saa7133[1]: i2c eeprom 10: 00 ff 86 0f ff 20 ff 00 01 50 32 79 01 3c ca 50
saa7133[1]: i2c eeprom 20: 01 40 01 02 02 03 01 00 06 ff 00 23 02 51 96 2b
saa7133[1]: i2c eeprom 30: a7 58 7a 1f 03 8e 84 5e da 7a 04 b3 05 87 b2 3c
saa7133[1]: i2c eeprom 40: ff 28 00 c0 96 10 03 00 c0 1c fd 79 44 9f c2 8f

Note, saa7134 gpio_tracking=1 is enabled.
saa7133[0]: gpio: mode=0x0008000 in=0x000 out=0x0008000 [pre-init]

Means gpio 15 is set to 1, output.


 The modification of the GPIO address Instead of 0x8000 used in Jan's patch, 
 use 0xC000 for GPIO setup I'm not sure what I changed was the correct value. 
  Looking at the code lines I found relate to the Remote that I had changed 
 (saa7134-cards.c):
 
 
 +case SAA7134_BOARD_VIDEOMATE_S350:
 +dev-has_remote = SAA7134_REMOTE_GPIO;
 +saa_andorl(SAA7134_GPIO_GPMODE0  2,   0x8000, 0x8000);
 +saa_andorl(SAA7134_GPIO_GPSTATUS0  2, 0x8000, 0x8000);
 +break;
 
 Which leads to the question where the GPIO address of 0x8000 is currently 
 specified?

This is exactly caused by and only by the above, likely powering up some
chip.

If you change all to 0xc000, gpio 14 and 15 are set to 1, output.

Don't know what exactly is going on with your card 

Re: Compile error saa7134 - compro videomate S350

[hermann pitton]

Hi Dominic,

Am Freitag, den 27.11.2009, 14:59 -0800 schrieb Dominic Fernandes:
 hi,
 
 where does  options saa7134 alsa=0 need to be declared?  Is it in 
 /etc/modprobe.d/options.conf ?  If so, it didn't work - FATAL: saa7134-alsa 
 is in use

yes, you can only unload saa7134-alsa after you close all apps using it.

It is very distribution depending and I'm not aware of all, where to put
options.

If it doesn't work for options.conf, it should still work with a
recently deprecated declared /etc/modprobe.conf file you have to create
as a work around for all distros.

You must issue a depmod -a after that and reboot, if you don't know
how to unload saa7134-alsa by closing all apps using it.

A modprobe -vr saa7134-alsa saa7134-dvb and then load it with
modprobe -v saa7134 card=169 gpio_tracking=1 should still reveal
something configured in the system overriding your command line with
card=169.

I'm not on latest here ...

Cheers,
Hermann


--
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: [RFC] What are the goals for the architecture of an in-kernel IR system?

[Maxim Levitsky]

On Fri, 2009-11-27 at 22:49 +0100, Stefan Richter wrote: 
 Jon Smirl wrote:
  3) No special tools - use mkdir, echo, cat, shell scripts to build maps
 
 From the POV of a distributor, there is always a special tool required.
 Whether it is implemented in bash, Python, or C doesn't make a
 difference to him.
 
 For an enduser whose distributor doesn't package that tool, it also
 doesn't matter whether it is bash or Python.  (C is awkward because it
 needs to be run through gcc first.)  A Pyton tool can operate the
 existing EVIOCSKEYCODE interface just as well as a C tool.
 
 Your mkdir/ echo/ cat programs would still just this:  Programs.  Sure,
 these programs would be interpreted by an interpreter which is installed
 everywhere, and the data they operate on is in a clear text format.  The
 downside is that these programs do not exist yet.
 
  5) Direct multi-app support - no daemon
 
 Think of lircd (when it feeds into uinput) as of a userspace driver
 rather than a daemon.  The huge benefit of a userspace driver is that it
 can load configuration files.
And bear in mind the fact that only handful of lirc drivers are in
kernel.
Many drivers are pure userspace and live in  the lirc daemon itself.
These drivers ether will have to be reimplemented in kernel (huge job)
Or we will have a lot of duplication, because same remote can be used
with kernel or userspace drivers.

Look at daemons subdirectory of lircd to get the idea of how many such
drivers exist.


Btw, for _some_ user space drivers its not possible to re implement them
in kernel, like driver that reads input from a sound card, which I can
say is nice very cheap way to have a receiver.


I want to repeat the correct way of doing things:

1 - all drivers that do all processing in hardware, will use input
system. 

2 - all drivers that decode protocol will use ether lirc, to keep
configuration in one place.

3 - all drivers that send pulse/space will use lirc.

lirc will process the data, convert it to input events and feed them
back to kernel.

Please note, and note again.
We aren't taking about two interfaces for userspace!
Everybody agree that userspace programs will only recieve input events.
The point is that we give an exception for one program that yes is just
a userspace driver to recieve the raw data, process it, and feed it
back.

Also same program (lircd) could receive data from other sources, and
convert that to input events.

Whats wrong with that?

If we add in-kernel decoding, we still will end up with two different
decoding, one in kernel and one in lirc.

Could we finally end this discussion and move forward?

Best regards,
Maxim Levitsky

--
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: [RFC] Should we create a raw input interface for IR's ? - Was: Re: [PATCH 1/3 v2] lirc core device driver infrastructure

[Mauro Carvalho Chehab]

Em Thu, 26 Nov 2009 17:06:03 -0200
Mauro Carvalho Chehab mche...@redhat.com escreveu:

 Krzysztof Halasa wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
  
  Technically, it is not hard to port this solution to the other
  drivers, but the issue is that we don't have all those IR's to know
  what is the complete scancode that each key produces. So, the hardest
  part is to find a way for doing it without causing regressions, and to
  find a group of people that will help testing the new way.
  
  We don't want to port it to other drivers. We need to have a common
  module which does all RCx decoding. The individual drivers should be as
  simple as possible, something that I outlined in a previous mail.
 
 With the current 7bits mask applied to almost all devices, it is probably not 
 very
 useful for those who want to use generic IRs. We really need to port the 
 solution
 we've done on dvb-usb to the other drivers, allowing them to have the entire
 scancode at the tables while keep supporting table replacement. 
 
 The issue is that we currently have only 7bits of the scan codes produced by 
 the IR's.
 So, we need to re-generate the keycode tables for each IR after the changes 
 got applied.

Ok, I got some time to add support for tables with the full scan codes at the 
V4L drivers.
In order to not break all tables, I've confined the changes to just one device 
(HVR-950,
at the em28xx driver). The patches were already committed at the -hg 
development tree.

In order to support tables with the full scan codes, all that is needed is to 
add the 
RC5 address + RC5 data when calling ir_input_keydown. So, the change is as 
simple as:

-   ir_input_keydown(ir-input, ir-ir,
-poll_result.rc_data[0]);
+   ir_input_keydown(ir-input, ir-ir,
+poll_result.rc_address  8 |
+poll_result.rc_data[0]);
+   else

An example of such patch can be seen at:
http://linuxtv.org/hg/v4l-dvb/rev/9c38704cfd56

There are still some work to do, since, currently, the drivers will use a table 
with a fixed
size. So, you can replace the current values, but it is not possible to add new 
keys.

The fix for it is simple, but we need to think what would be the better way for 
it. There are
two alternatives:
- A table with a fixed size (like 128 or 256 entries - maybe a modprobe 
parameter
could be used to change its size);
- some way to increase/reduce the table size. In this case, we'll 
likely need some
ioctl for it.

-- 

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