saa7134 and µPD61151 MPEG2 encoder

2009-12-03 Thread Dmitri Belimov
Hi All

Our new TV card has MPEG-2 encoder NEC µPD61151. This encoder hasn't I2C bus, 
only SPI.
I wrote SPI bitbang master for saa7134.

[   74.482290] Linux video capture interface: v2.00
[   74.534047] saa7130/34: v4l2 driver version 0.2.15 loaded
[   74.534081] saa7134 :04:01.0: PCI INT A - GSI 19 (level, low) - IRQ 19
[   74.534086] saa7133[0]: found at :04:01.0, rev: 209, irq: 19, latency: 
32, mmio: 0xe510
[   74.534092] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7 
[card=171,autodetected]
[   74.534101] saa7133[0]: board init: gpio is 20
[   74.534108] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[   74.684510] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00 
00 00 00 01
[   74.684531] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684548] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684565] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684582] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684599] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684616] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684633] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684650] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684667] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684684] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684701] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684709] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684717] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684725] saa7133[0]: i2c eeprom e0: 00 00 00 00 ff ff ff ff ff ff ff ff 
ff ff ff ff
[   74.684733] saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff 
ff ff ff ff
[   74.684743] i2c-adapter i2c-7: Invalid 7-bit address 0x7a
[   74.712024] tuner 7-0061: chip found @ 0xc2 (saa7133[0])
[   74.819118] xc5000 7-0061: creating new instance
[   74.828015] xc5000: Successfully identified at address 0x61
[   74.828019] xc5000: Firmware has not been loaded previously
[  103.120811] input: i2c IR (BeholdTV) as /class/input/input5
[  103.120847] ir-kbd-i2c: i2c IR (BeholdTV) detected at i2c-7/7-002d/ir0 
[saa7133[0]]
[  103.152055] saa7133[0]: found muPD61151 MPEG encoder
[  103.152216] saa7134 :04:01.0: spi master registered: bus_num=32766 
num_chipselect=1


[  103.152322] saa7133[0]: registered device video0 [v4l2]
[  103.152340] saa7133[0]: registered device vbi0
[  103.152358] saa7133[0]: registered device radio0
[  103.168060] saa7133[0]: registered device video1 [mpeg]
[  103.196503] saa7134 ALSA driver for DMA sound loaded
[  103.196514] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[  103.196531] saa7133[0]/alsa: saa7133[0] at 0xe510 irq 19 registered as 
card -1
[  103.198892] xc5000: I2C write failed (len=4)
[  103.300018] xc5000: I2C write failed (len=4)
[  103.304799] xc5000: I2C read failed
[  103.304808] xc5000: I2C read failed
[  103.304810] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)...
[  103.304813] saa7134 :04:01.0: firmware: requesting 
dvb-fe-xc5000-1.6.114.fw
[  103.347409] xc5000: firmware read 12401 bytes.
[  103.347413] xc5000: firmware uploading...
[  106.676008] xc5000: firmware upload complete...

Next point I think is write v4l2 workaround for SPI like I2C bus.

Functions:
v4l2_i2c_new_subdev - v4l2_spi_new_subdev
v4l2_i2c_new_subdev_cfg - v4l2_spi_new_subdev_cfg
v4l2_i2c_new_subdev_board - v4l2_spi_new_subdev_board
v4l2_i2c_subdev_init - v4l2_spi_subdev_init
i2c_set_clientdata - spi_set_clientdata

Who can do it?? Or help me with it??

With my best regards, Dmitry.
--
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


/dev/dvb/adapter0/net0 -- what is this for and how to use it?

2009-12-03 Thread Leszek Koltunski
Hello DVB gurus,

I've got a TwinHan DVB-S2 card. I compiled the 'liplianin' drivers and
it's working nicely; thanks for all your work!

One question: in /dev/dvb/adapter0 I can see

les...@satellite:~$ ls -l /dev/dvb/adapter0/
total 0
crw-rw+ 1 root video 212, 4 2009-12-02 18:22 ca0
crw-rw+ 1 root video 212, 0 2009-12-02 18:22 demux0
crw-rw+ 1 root video 212, 1 2009-12-02 18:22 dvr0
crw-rw+ 1 root video 212, 3 2009-12-02 18:22 frontend0
crw-rw+ 1 root video 212, 2 2009-12-02 18:22 net0

What is this 'net0' device and how do I use it? Can I use it to
directly multicast my (FTA) satellite stream to my lan by any chance?

I have found no documentation about this...
--
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: Problem on RJ54N1CB0C

2009-12-03 Thread Guennadi Liakhovetski
Hi Uwe

On Thu, 3 Dec 2009, Uwe Taeubert wrote:

 Hello Guennadi,
 now  our driver is working. I found the registers to fix and manipulate the 
 exposure values. So, now, if I switch from preview to heigher resolution 
 pictures, the taken photo is as bright as the preview. I read out the preview 
 exposure data, modify it according to the desired divider settings and then I 
 switch to the new mode. 
 Now it is also possible to change exposure values in case of flashlight use 
 depending on AF values to prevent over exposure of near objects. But, it is 
 not done, yet.
 The resolution depending divider switching is not tested in all details, yet. 
 It is done for our preferred resolutions.

cool! Thanks for sharing your success! I'm currently busy with getting 
ready for the approaching merge window, but it would be good to get your 
functionality integrated in the mainline driver. I think, it would also be 
good for you to migrate to the in-tree version, so, would be cool, if you 
could try the mainstream version and send us patches against it.

 I'm using the English version.

Hm, good to know...

Thanks
Guennadi
 
 Regard
 Uwe
 
 Am Tuesday 17 November 2009 09:28:18 schrieben Sie:
  Hi Uwe
 
  On Mon, 16 Nov 2009, Uwe Taeubert wrote:
   Hi Guennadi
   You will find the driver sources for our Sharp module in lz0p39ha.c and
   the initialization data in lz0p39ha_init.c. In lz0p35du_set_fmt_cap() you
   can see the resolution depending change of the divider. In our system we
   get correct pictures in all resolution mensioned there. But FYI, if no
   flashlight is desired, we do not switch to still mode - only still mode
   generates flash controll signals.
   We are working with the Technical Manual Ver. 2.2C, also under NDA.
 
  May I ask you if you have an English or a Japanese version?:-) I've got a
  2.3C Japanese...
 
   Concerning the exposure control, I know the use of the registers 0x04d8
   and 0x04d9 is more a hack but a solution. And the result is unsatisfying
   - it was a try.divide  
  
   At the moment I'm checking the influence of RAMPCLK- TGCLK-ratio. I was
   able to get higher exposer by changing RAMPCLK but I wasn't able to
   calculate a well doing relation between all clocks and to have a fast
   frame rate.
  
   The driver content is in a preliminary state. I'm working on
   lz0p35du_set_fmt_cap function. We do not diffenrentialte between preview
   and still mode. It makes it easier to handle buffers in VFL at the
   moment.
 
  Thanks for the code. I looked briefly at it and one essential difference
  that occurred to me is, that you're setting the RESIZE registers at the
  beginning of the format-change function (lz0p35du_set_fmt_cap()), and I am
  doing this following code examples, that I had in the end, followed by a
  killer delay of 230ms... You might try to do that in the end, but it might
  only become worse, because, as I said, my version of the driver has
  problems with bigger images.
 
  My driver also doesn't set autofocus ATM, as there had been errors in
  examples that I had and I didn't have time to experiment with those
  values. I'm also relying on the automatic exposure area selection (0x58c
  bit 7) instead of setting it automatically. You also don't seem to
  dynamically adjust INC_USE_SEL registers, instead you just initialise them
  to 0xff. And in my experience that register does make a difference, so,
  you might try to play with it a bit. Have a look at my driver, although, I
  don't think values I configure there are perfect either.
 
  In fact, it might indeed become a problem for you, that you're updating
  the RESIZE registers too early and not pausing after that.
 
  Unfortunately, I do not have time now to look at the driver in detail ATM,
  let me know your results when you fix your problem.
 
  Thanks
  Guennadi
  ---
  Guennadi Liakhovetski, Ph.D.
  Freelance Open-Source Software Developer
  http://www.open-technology.de/
 
 
 

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


[PATCH 1/2 v4] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-12-03 Thread Guennadi Liakhovetski
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how video
data is stored in RAM. This is not a one-to-one correspondence, therefore we
cannot use fourcc codes to configure subdevice output data formats. This patch
adds codes for several such on-the-bus formats and an API, similar to the
familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
codes. After all users of the old API in struct v4l2_subdev_video_ops are
converted, it will be removed. Also add helper routines to support generic
pass-through mode for the soc-camera framework.

Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---

v3 - v4: more comments addressed - thanks! Now based on the current 
linux-next. Hans, as for _nXk suffixes, I preferred to preserve them to 
keep all notation explicit. Without them a format like 
V4L2_MBUS_FMT_SBGGR10 would be ambiguous, whether one of 
V4L2_MBUS_FMT_SBGGR10_2X8_PAD*_?E or the V4L2_MBUS_FMT_SBGGR10_1X10 is 
meant. I also removed struct soc_mbus_datafmt and soc_mbus_find_datafmt() 
upon your request, although I'm not happy having to open-code it in about 
4 drivers. But we can extract that code in a generic routine later. One of 
the important advantages of that struct and function was, that they 
allowed to keep supported formats in drivers centrally at just one 
location, thus being able to add new or remove deprecated formats easily, 
and to avoid long switch-case blocks by just calling one function to 
search in the array.

Thanks
Guennadi

 drivers/media/video/Makefile   |2 +-
 drivers/media/video/soc_mediabus.c |  157 
 include/media/soc_mediabus.h   |   65 +++
 include/media/v4l2-mediabus.h  |   61 ++
 include/media/v4l2-subdev.h|   19 -
 5 files changed, 302 insertions(+), 2 deletions(-)
 create mode 100644 drivers/media/video/soc_mediabus.c
 create mode 100644 include/media/soc_mediabus.h
 create mode 100644 include/media/v4l2-mediabus.h

diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7a2dcc3..e7bc8da 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
 obj-$(CONFIG_VIDEO_CX23885) += cx23885/
 
 obj-$(CONFIG_VIDEO_OMAP2)  += omap2cam.o
-obj-$(CONFIG_SOC_CAMERA)   += soc_camera.o
+obj-$(CONFIG_SOC_CAMERA)   += soc_camera.o soc_mediabus.o
 obj-$(CONFIG_SOC_CAMERA_PLATFORM)  += soc_camera_platform.o
 # soc-camera host drivers have to be linked after camera drivers
 obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
diff --git a/drivers/media/video/soc_mediabus.c 
b/drivers/media/video/soc_mediabus.c
new file mode 100644
index 000..c54cae7
--- /dev/null
+++ b/drivers/media/video/soc_mediabus.c
@@ -0,0 +1,157 @@
+/*
+ * soc-camera media bus helper routines
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-mediabus.h
+#include media/soc_mediabus.h
+
+#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1)
+
+static const struct soc_mbus_pixelfmt mbus_fmt[] = {
+   [MBUS_IDX(YUYV8_2X8)] = {
+   .fourcc = V4L2_PIX_FMT_YUYV,
+   .name   = YUYV,
+   .bits_per_sample= 8,
+   .packing= SOC_MBUS_PACKING_2X8_PADHI,
+   .order  = SOC_MBUS_ORDER_LE,
+   }, [MBUS_IDX(YVYU8_2X8)] = {
+   .fourcc = V4L2_PIX_FMT_YVYU,
+   .name   = YVYU,
+   .bits_per_sample= 8,
+   .packing= SOC_MBUS_PACKING_2X8_PADHI,
+   .order  = SOC_MBUS_ORDER_LE,
+   }, [MBUS_IDX(UYVY8_2X8)] = {
+   .fourcc = V4L2_PIX_FMT_UYVY,
+   .name   = UYVY,
+   .bits_per_sample= 8,
+   .packing= SOC_MBUS_PACKING_2X8_PADHI,
+   .order  = SOC_MBUS_ORDER_LE,
+   }, [MBUS_IDX(VYUY8_2X8)] = {
+   .fourcc = V4L2_PIX_FMT_VYUY,
+   .name   = VYUY,
+   .bits_per_sample= 8,
+   .packing= SOC_MBUS_PACKING_2X8_PADHI,
+   .order  = SOC_MBUS_ORDER_LE,
+   }, [MBUS_IDX(RGB555_2X8_PADHI_LE)] = {
+   .fourcc = 

[PATCH] V4L/DVB: pms: KERNEL_VERSION requires version.h

2009-12-03 Thread Alexander Beregalov
Fix this build error:
drivers/media/video/pms.c:682: error: implicit declaration of function 
'KERNEL_VERSION'

Signed-off-by: Alexander Beregalov a.berega...@gmail.com
---
 drivers/media/video/pms.c |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/drivers/media/video/pms.c b/drivers/media/video/pms.c
index 00228d5..a118bb1 100644
--- a/drivers/media/video/pms.c
+++ b/drivers/media/video/pms.c
@@ -35,6 +35,7 @@
 #include media/v4l2-ioctl.h
 #include media/v4l2-device.h
 #include linux/mutex.h
+#include linux/version.h
 
 #include asm/uaccess.h
 
-- 
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: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
 On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

 Dmitry Torokhov wrote:
 ...
 (for each remote/substream that they can recognize).
 I'm assuming that, by remote, you're referring to a remote receiver (and 
 not to 
 the remote itself), right?
 If we could separate by remote transmitter that would be the best I
 think, but I understand that it is rarely possible?
 IMHO, the better is to use a separate interface for the IR transmitters,
 on the devices that support this feature. There are only a few devices
 I'm aware of that are able to transmit IR codes.
 If I'm thinking clearly, there are only three lirc kernel drivers that
 support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
 driver was posted, so I won't rehash what it is here. The zilog driver
 binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
 found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
 etc). The serial driver is fairly self-explanatory as well.

 There are also a few userspace-driven devices that do transmit, but
 I'm assuming they're (currently) irrelevant to this discussion.
 
 
 I've got the CX23888 integrated IR Rx done and Tx nearly done.  I was
 waiting to see how kfifo and lirc_dev panned out before making the
 interface to userspace.
 
 The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
 I hope to have CX23885 IR done by Christmas.
 
 Both of those IR devices are/will be encapsulated in a v4l2_subdevice
 object internally.  I was going to write lirc_v4l glue between the
 v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
 
 As for the the I2C chips, I was going to go back and encapsulate those
 in the v4l2_subdevice object as well, so then my notional lirc_v4l could
 pick those up too.  The I2C subsystem only allows one binding to an I2C
 client address/name on a bus.  So without some new glue like a notional
 lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
 lirc_zilog.

Maybe you're having a bad time because you may be trying to integrate lirc
at the wrong place.

All devices at V4L tree including ir-kbd-i2c use ir-common.ko 
(at /drivers/media/common tree) module to communicate to IR's. 
I'm preparing some patches to extend this also to dvb-usb devices 
(that uses a close enough infrastructure). 

Also, most of the decoding code are there, in a form of helper routines.

As the idea is to provide lirc interface to all devices that can work with
raw pulse/space, the proper place is to write a subroutine there that, once
called, will make those pulse/space raw codes available to lirc and will
call the needed decoders to export them also to evdev.

The code at ir-common module was originally built to be used by V4L, but I'm
porting the code there to be generic enough to be a library that can be used
by other drivers. So, lirc_zilog and other lirc devices that will need to open
evdev interfaces after running a decoder can use them.

Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this should
be implemented as a separate module.

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


cx2388x driver appears broken

2009-12-03 Thread Shaun Amy
Hi,

I have successfully been running Ubuntu 9.10 on an old Pentium4
test-box.  The machine has two PCI cards, both of which worked with
stock 9.10 and with a slightly upgraded kernel (2.6.31-14-generic-pae
and 2.6.31-15-generic-pae).  These cards, have, in the past also
worked on Ubuntu 6.10 so have been supported for a long time.  The
output on the 2.6.31-15-generic-pae gives:

[6.173285] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded
[6.173349] cx8800 :02:0b.0: PCI INT A - GSI 23 (level, low) - IRQ 23
[6.174531] cx88[0]: subsystem: 18ac:db10, board: DViCO FusionHDTV
DVB-T Plus [card=21,insmod option], frontend(s): 1
[6.174537] cx88[0]: TV tuner type 4, Radio tuner type -1
[6.183548] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded
[6.340041] cx88[0]/0: found at :02:0b.0, rev: 5, irq: 23,
latency: 32, mmio: 0xef00
[6.340065] IRQ 23/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.340191] cx88[0]/0: registered device video0 [v4l2]
[6.340237] cx88[0]/0: registered device vbi0
[6.340313] cx88[0]/2: cx2388x 8802 Driver Manager
[6.340335] cx88-mpeg driver manager :02:0b.2: PCI INT A - GSI
23 (level, low) - IRQ 23
[6.340349] cx88[0]/2: found at :02:0b.2, rev: 5, irq: 23,
latency: 32, mmio: 0xee00
[6.340358] IRQ 23/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.340395] cx8800 :02:0c.0: PCI INT A - GSI 20 (level, low) - IRQ 20
[6.341628] cx88[1]: subsystem: 17de:a8a6, board: Conexant DVB-T
reference design [card=19,insmod option], frontend(s): 1
[6.341635] cx88[1]: TV tuner type 4, Radio tuner type -1
[6.504094] cx88[1]/0: found at :02:0c.0, rev: 5, irq: 20,
latency: 32, mmio: 0xed00
[6.504166] IRQ 20/cx88[1]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.504294] cx88[1]/0: registered device video1 [v4l2]
[6.504342] cx88[1]/0: registered device vbi1
[6.506583] cx88[1]/2: cx2388x 8802 Driver Manager
[6.506609] cx88-mpeg driver manager :02:0c.2: PCI INT A - GSI
20 (level, low) - IRQ 20
[6.506625] cx88[1]/2: found at :02:0c.2, rev: 5, irq: 20,
latency: 32, mmio: 0xec00
[6.506638] IRQ 20/cx88[1]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.609088]   alloc irq_desc for 18 on node -1
[6.609095]   alloc kstat_irqs on node -1
[6.609108] C-Media PCI :02:0d.0: PCI INT A - GSI 18 (level,
low) - IRQ 18
[6.873923] EXT4-fs (sda11): internal journal on sda11:8
[7.011870] cx88/2: cx2388x dvb driver version 0.0.7 loaded
[7.011877] cx88/2: registering cx8802 driver, type: dvb access: shared
[7.011884] cx88[0]/2: subsystem: 18ac:db10, board: DViCO
FusionHDTV DVB-T Plus [card=21]
[7.011889] cx88[0]/2: cx2388x based DVB/ATSC card
[7.011893] cx8802_alloc_frontends() allocating 1 frontend(s)
[7.092877] ip_tables: (C) 2000-2006 Netfilter Core Team
[7.397447] DVB: registering new adapter (cx88[0])
[7.397457] DVB: registering adapter 0 frontend 0 (Zarlink ZL10353 DVB-T)...
[7.398038] cx88[1]/2: subsystem: 17de:a8a6, board: Conexant DVB-T
reference design [card=19]
[7.398046] cx88[1]/2: cx2388x based DVB/ATSC card
[7.398050] cx8802_alloc_frontends() allocating 1 frontend(s)
[7.434445] DVB: registering new adapter (cx88[1])
[7.434456] DVB: registering adapter 1 frontend 0 (Conexant CX22702 DVB-T)...

In order to debug a problem with a new dual tuner USB module, I
grabbed the latest v4l-dvb and built all the modules from source (sans
FireTV) and installed them using the provided makefile targets.  This
results in the following:

[5.831860] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.7 loaded
[5.833100] cx88[0]: subsystem: 18ac:db10, board: DViCO FusionHDTV
DVB-T Plus [card=21,insmod option], frontend(s): 1
[5.833107] cx88[0]: TV tuner type 4, Radio tuner type -1
[5.846548] cx88/0: cx2388x v4l2 driver version 0.0.7 loaded
[5.884782] EXT4-fs (sda11): internal journal on sda11:8
[6.012069] BUG: unable to handle kernel NULL pointer dereference at (null)
[6.012313] IP: [e0db9aa6] ir_input_free+0x16/0x40 [ir_common]
[6.012490] *pdpt = 1e550001 *pde = 
[6.012725] Oops:  [#1] SMP
[6.012957] last sysfs file: /sys/devices/virtual/dmi/id/sys_vendor
[6.013048] Modules linked in: snd_opl3_lib snd_timer x_tables
snd_hwdep cx8800(+) cx8802(+) snd_mpu401_uart cx88xx ir_common
i2c_algo_bit snd_rawmidi v4l2_common snd_seq_device tveeprom videodev
v4l1_compat videobuf_dma_sg btcx_risc snd videobuf_core soundcore
ppdev parport_pc shpchp lp intel_agp parport agpgart psmouse serio_raw
e100 mii natsemi floppy
[6.015697]
[6.015784] Pid: 534, comm: modprobe Not tainted
(2.6.31-15-generic-pae #50-Ubuntu) System Name
[6.015886] EIP: 0060:[e0db9aa6] EFLAGS: 00010246 CPU: 0
[6.015983] EIP is at ir_input_free+0x16/0x40 [ir_common]
[6.016013] EAX:  EBX:  ECX: ffed EDX: de08778c
[6.016013] ESI: 

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Andy Walls wrote:
 On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
 On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

 Dmitry Torokhov wrote:
 ...
 (for each remote/substream that they can recognize).
 I'm assuming that, by remote, you're referring to a remote receiver (and 
 not to 
 the remote itself), right?
 If we could separate by remote transmitter that would be the best I
 think, but I understand that it is rarely possible?
 IMHO, the better is to use a separate interface for the IR transmitters,
 on the devices that support this feature. There are only a few devices
 I'm aware of that are able to transmit IR codes.
 If I'm thinking clearly, there are only three lirc kernel drivers that
 support transmit, lirc_mceusb, lirc_zilog and lirc_serial. The mceusb
 driver was posted, so I won't rehash what it is here. The zilog driver
 binds to a Zilog z80 microprocessor thingy (iirc) exposed via i2c,
 found on many Hauppauge v4l/dvb devices (PVR-150, HVR-1600, HD-PVR,
 etc). The serial driver is fairly self-explanatory as well.

 There are also a few userspace-driven devices that do transmit, but
 I'm assuming they're (currently) irrelevant to this discussion.
 
 
 I've got the CX23888 integrated IR Rx done and Tx nearly done.  I was
 waiting to see how kfifo and lirc_dev panned out before making the
 interface to userspace.
 
 The CX23885, CX23418, and CX2584x integrated IR is essentially the same.
 I hope to have CX23885 IR done by Christmas.
 
 Both of those IR devices are/will be encapsulated in a v4l2_subdevice
 object internally.  I was going to write lirc_v4l glue between the
 v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
 
 As for the the I2C chips, I was going to go back and encapsulate those
 in the v4l2_subdevice object as well, so then my notional lirc_v4l could
 pick those up too.  The I2C subsystem only allows one binding to an I2C
 client address/name on a bus.  So without some new glue like a notional
 lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
 lirc_zilog.

The better is to add the lirc glue at ir-common module. There, we have the 
support
functions used by all V4L devices, and they'll be expanded to cover also
dvb-usb, as soon as I can find some time to do a patch 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


Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 On Wed, Dec 2, 2009 at 9:22 PM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
 Jon Smirl wrote:
 On Wed, Dec 2, 2009 at 3:04 PM, Jarod Wilson ja...@wilsonet.com wrote:
 On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:

 On Wed, Dec 02, 2009 at 02:22:18PM -0500, Jarod Wilson wrote:
 On 12/2/09 12:30 PM, Jon Smirl wrote:
 (for each remote/substream that they can recognize).
 I'm assuming that, by remote, you're referring to a remote receiver 
 (and not to
 the remote itself), right?
 If we could separate by remote transmitter that would be the best I
 think, but I understand that it is rarely possible?
 The code I posted using configfs did that. Instead of making apps IR
 aware it mapped the vendor/device/command triplets into standard Linux
 keycodes.  Each remote was its own evdev device.
 Note, of course, that you can only do that iff each remote uses distinct
 triplets. A good portion of mythtv users use a universal of some sort,
 programmed to emulate another remote, such as the mce remote bundled
 with mceusb transceivers, or the imon remote bundled with most imon
 receivers. I do just that myself.

 Personally, I've always considered the driver/interface to be the
 receiver, not the remote. The lirc drivers operate at the receiver
 level, anyway, and the distinction between different remotes is made by
 the lirc daemon.
 The fact that lirc does it this way does not necessarily mean it is the
 most corerct way.
 No, I know that, I'm just saying that's how I've always looked at it, and 
 that's how lirc does it right now, not that it must be that way.

 Do you expect all bluetooth input devices be presented
 as a single blob just because they happen to talk to the sane receiver
 in yoru laptop? Do you expect your USB mouse and keyboard be merged
 together just because they end up being serviced by the same host
 controller? If not why remotes should be any different?
 A bluetooth remote has a specific device ID that the receiver has to pair 
 with. Your usb mouse and keyboard each have specific device IDs. A usb IR 
 *receiver* has a specific device ID, the remotes do not. So there's the 
 major difference from your examples.
 Actually remotes do have an ID. They all transmit vendor/device pairs
 which is exactly how USB works.

 Well, the description of NEC and RC5 protocol at 
 http://www.sbprojects.com/knowledge/ir/rc5.htm
 doesn't mention any vendor/device pair, nor I'm able to get them with the IR 
 hardware decoders
 I have.
 
 Some of the protocols were not intended to be multi-vendor  - the
 vendor is implicit in the protocol encoding. You don't have to split
 the IR codes into vendor/device/command triplets. I just do that
 because it is convenient to think of them that way. It is equally
 valid to treat them as a 64b integers and use four bits of the int to
 encode the protocol.  It should really be a quad
 protocol/vendor/device/command and some of the fields may be missing.
 Bottom line, you are looking for unique codes how the fields are split
 up doesn't really matter.

Currently, there aren't any in-kernel driver that support 64 bit IR's.
They support only up to 16 bits. So, we have only address (device)/command. 
As I said before, AFAIK, only RC6 mode 6 remotes support 64 bits. 

As pointed by Andy, it is risky to support such protocol in kernel,
since you won't be able to ship the kernel to countries where RC6 patents 
got accepted, or you would need.

 A fixed protocol receiver is more of a challenge. You have to figure
 out how to make a universal remote transmit device codes for a device
 you don't already own that is also encoded in the protocol your
 hardware supports. 
 There's nothing we can do about that problem in
 Linux, its a side effect of fixed protocol decode hardware. 

With hardware decoders, you're limited to the supported protocols, but yet,
you can use a different scancode than the one that comes with the shipped
device.

If you take a look, for example, at the NEC protocol decoder we have on
drivers/media/video/saa7134/saa7134-input.c [1], you'll see that the
tasklet (nec_task) holds CPU control up to 76.5 ms, in order to be able
to receive the entire sequence at the GPIO port. Fortunately, on the device
where this decoder is called (Avermedia M135A), we can trigger the start
of the IR code via IRQ.

[1]http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-2.6.git;a=blob;f=drivers/media/video/saa7134/saa7134-input.c;h=6e219c2db8419013ab3ced30470ad1c19431974a;hb=HEAD


In this specific decoder I've implemented it some time ago. I think
I tried first to get the pulse/space width using just IRQ without the tasklet,
but the lengths weren't precise enough for decoding. Also, if you have a bad
contact at the IR sensor connector, as it is directly connected to an IRQ pin,
you may end by hanging the machine, if the code is not carefully written.

I remember I had some bad time due to the bad contacts at the IR sensor
with the sample I had available 

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Jon Smirl wrote:
 On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote:
 On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
 ...
 Now I understand that if 2 remotes send completely identical signals we
 won't be able to separate them, but in cases when we can I think we
 should.
 I don't have a problem with that, if its a truly desired feature.  But
 for the most part, I don't see the point.  Generally, you go from
 having multiple remotes, one per device (where device is your TV,
 amplifier, set top box, htpc, etc), to having a single universal remote
 that controls all of those devices.  But for each device (IR receiver),
 *one* IR command set.  The desire to use multiple distinct remotes with
 a single IR receiver doesn't make sense to me.  Perhaps I'm just not
 creative enough in my use of IR.  :)
 Most universal remotes I'm familiar with emulate multiple remotes.  I.e.
 my tv remote generates one set of scancodes for the numeric keys.  The DVD
 remote generates a different set.  The amplifier remote in tv mode
 generates the same codes as the tv remote, and in dvd mode the same codes
 as the dvd remote.  From the perspective of the IR receiver there is no
 difference between having both the DVD and TV remotes, or using the
 aplifier remote to control both devices.
 Okay, in the above scenario, you've still got a single input device...

 Now, my aplifier remote has a number of modes.  Some control devices I
 have, like vcr mode, and there is nothing I can do about that.  Some,
 like md mode don't control devices I have.  That means they are free to
 do things on the computer.  Someone else with the same remote (or any
 number of remotes that use the same protocol and scancodes) might have
 different devices.

 So I want my computer to do stuff when I push JVC MD #xx keys, but ignore
 JVC VCR #yyy yets.  Someone with an MD player and not a VCR would want to
 opposite.  Rather than force everyone to create custom keymaps, it's much
 easier if we can use the standard keymaps from a database of common remotes
 and simply tell mythtv to only use remote #xxx or not to use remote #yyy.
 Sure, but the key is that this can't be done automagically. The IR driver 
 has no way of knowing that user A wants JVC MD keys handled and JVC VCR keys 
 ignored, and user B wants vice versa, while user C wants both ignored, etc. 
 This is somewhat tangential to whether or not there's a separate input 
 device per remote though. You can use multiple remotes/protocols with a 
 single input device or lirc device already (if the hardware doesn't have to 
 be put explicitly into a mode to listen for that proto, of course, but then 
 its a hardware decoding device feeding a single input device anyway, so...).

 It sounds like you're thinking of a receiver that came bundled with a
 remote and that's it.  Not someone with a number of remotes that came with
 different pieces of AV gear that they want to use with their computer.
 No, I just pick *one* remote and use it for everything, not 
 schizophrenically hopping from one remote to another, expecting them all the 
 be able to control everything. :) Its a hell of a lot easier to find buttons 
 w/o looking at the remote if you always use the same one for everything, for 
 one.

 Anyway, I think I'm talking myself in circles. Supporting multiple remotes 
 via multiple input devices (or even via a single input device) isn't at all 
 interesting to me for my own use, but if there really is demand for such 
 support (and it appears there is), then fine, lets do it.
 
 Simple use case:
 
 You have a multifunction remote. Press the CABLE key - it sends out
 commands that control the cable box, press the TV key - now the
 commands control the TV, press CD - now the CD player, etc.
 
 Now imagine a headless Linux box running a music server and a home
 automation app. Press the CD key - commands get routed to the music
 server, press the AUX key - commands get routed to the home automation
 app.
 
 This is accomplished by recognizing the device code part of the IR
 signal and figuring out that there are two different device codes in
 use. The commands of then routed to two evdev devices corresponding to
 the two different device codes.
 
 Using things like Alt-Tab to switch apps is impossible. There's no
 screen to look at.

This usecase makes sense to me.

With the risk of repeating myself, you don't have two physical remotes.
The needed feature is a way to split one source of input events (that
happens to be an infrared remote, but it could also be any other type of input
device, like a bluetooth remote) into several different evdev interfaces,
based on scancode groups. 

Also, as you're thinking on 64 bits scancodes, this also means that the
current evdev KABI and API will require changes to support bigger scancodes.

Anyway, IMO, this subject should be handled as a different requirement than
integrating the lirc drivers.

Cheers,
Mauro.
--
To unsubscribe from this list: 

Re: Replace Mercurial with GIT as SCM

2009-12-03 Thread Laurent Pinchart
On Thursday 03 December 2009 09:04:48 Hans de Goede wrote:
 +1 for git, I really really really miss being able to do
 a simple git rebase, and no rebase is not evil not as long
 as you don't use it for anything but local patches.

For what it's worth, I second that. git rebase -i is one of git's killer 
features (I personally learned about it during Linus' talk at the LPC 2009, so 
if you haven't heard about git rebase -i before, take a look at it).

-- 
Regards,

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


Re: [RFC v2] Another approach to IR

2009-12-03 Thread Andy Walls
On Thu, 2009-12-03 at 08:00 -0200, Mauro Carvalho Chehab wrote:
 Andy Walls wrote:
  On Wed, 2009-12-02 at 14:55 -0500, Jarod Wilson wrote:
  On Dec 2, 2009, at 2:33 PM, Mauro Carvalho Chehab wrote:

 
  Both of those IR devices are/will be encapsulated in a v4l2_subdevice
  object internally.  I was going to write lirc_v4l glue between the
  v4l2_device/v4l2_subdev_ir_ops and lirc_dev.
  
  As for the the I2C chips, I was going to go back and encapsulate those
  in the v4l2_subdevice object as well, so then my notional lirc_v4l could
  pick those up too.  The I2C subsystem only allows one binding to an I2C
  client address/name on a bus.  So without some new glue like a notional
  lirc_v4l, it *may* be hard to share between ir-kbd-i2c and lirc_i2c and
  lirc_zilog.
 
 Maybe you're having a bad time because you may be trying to integrate lirc
 at the wrong place.

These were just ideas.  I haven't done *anything* yet. ;)


 All devices at V4L tree including ir-kbd-i2c use ir-common.ko 
 (at /drivers/media/common tree) module to communicate to IR's. 
 I'm preparing some patches to extend this also to dvb-usb devices 
 (that uses a close enough infrastructure). 
 
 Also, most of the decoding code are there, in a form of helper routines.
 
 As the idea is to provide lirc interface to all devices that can work with
 raw pulse/space, the proper place is to write a subroutine there that, once
 called, will make those pulse/space raw codes available to lirc and will
 call the needed decoders to export them also to evdev.
 
 The code at ir-common module was originally built to be used by V4L, but I'm
 porting the code there to be generic enough to be a library that can be used
 by other drivers. So, lirc_zilog and other lirc devices that will need to open
 evdev interfaces after running a decoder can use them.

I think I see what you are saying (I wish could see look at a whiteboard
somewhere...).  Wherever we come through internally to split to 2
different userspace interfaces is fine, if you've got a big picture plan
you think is feasible.

That seems like a bit of perturbation to lirc_zilog and lirc_i2c.  My
thought was that lirc_v4l using the standardized v4l2_subdev_ir_ops
interface, and maybe some new calls associted with v4l2_device, could
subsume/unify all the functionality of lirc_i2c, lirc_zilog, ...
lirc_whatever.

Maybe that's just a poorly thought out dream though...


 Due to that, we shouldn't add v4l2_subdevice there. Nothing prevents to create
 a v4l2-ir-subdev glue if you want to see the IR's as subdevices, but this 
 should
 be implemented as a separate module.

The v4l_subdevice just abstracted the IR hardware into a nice (mental)
box for me -- easier to keep hardware separate from software decoders
and userspace interface logic.

Also, since v4l2_subdevices may have per subdevice /dev nodes and
the /dev/../mcN nodes providing a discovery mechanism due to the Meda
Controller framework, wrapping things in v4l2_subdevice may be handy for
development and debug.  Or ... as an additional operational interface to
userspace. :D  *ducks and runs for cover*

Regards,
Andy

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

2009-12-03 Thread Gerd Hoffmann

On 12/03/09 05:29, Jarod Wilson wrote:

On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:


Anyway, we shouldn't postpone lirc drivers addition due to that.
There are still lots of work to do before we'll be able to split
the tables from the kernel drivers.


Indeed.  The sysfs bits are future work for both lirc and evdev
drivers.  There is no reason to make the lirc merge wait for it.


At this point, my plan is to try to finish cleaning up lirc_dev and
lirc_mceusb at least over the weekend while at FUDCon up in Toronto,
and resubmit them next week.


Good plan IMHO.  Having lirc_dev merged quickly allows in-kernel drivers 
start supporting lirc.


One final pass over the lirc interface would be good, taking the chance 
to fixup anything before the ABI is set in stone with the mainline 
merge.  Things to look at:


  (1) Make sure ioctl structs are 32/64 bit invariant.
  (2) Maybe add some reserved fields to allow extending later
  without breaking the ABI.
  (3) Someone suggested a 'commit' ioctl which would activate
  the parameters set in (multiple) previous ioctls.  Makes sense?
  (4) Add a ioctl to enable/disable evdev event submission for
  evdev/lirc hybrid drivers.


I'm still on the fence over what to do about lirc_imon. The driver
supports essentially 3 generations of devices. First-gen is very old
imon parts that don't do onboard decoding. Second-gen is the devices
that all got (insanely stupidly) tagged with the exact same usb
device ID (0x15c2:0xffdc), some of which have an attached VFD, some
with an attached LCD, some with neither, some that are actually RF
parts, but all (I think) of which do onboard decoding. Third-gen is
the latest stuff, which is all pretty sane, unique device IDs for
unique devices, onboard decoding, etc.


Do have second-gen and third-gen devices have a 'raw mode'?  If so, then 
there should be a lirc interface for raw data access.



So the lirc_imon I submitted supports all device types, with the
onboard decode devices defaulting to operating as pure input devices,
but an option to pass hex values out via the lirc interface (which is
how they've historically been used -- the pure input stuff I hacked
together just a few weeks ago), to prevent functional setups from
being broken for those who prefer the lirc way.


Hmm.  I'd tend to limit the lirc interface to the 'raw samples' case.

Historically it has also been used to pass decoded data (i.e. rc5) from 
devices with onboard decoding, but for that in-kernel mapping + input 
layer really fits better.



What I'm debating is whether this should be split into two drivers,
one for the older devices that don't do onboard decoding (which would
use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy',
and one that is a pure input driver, not unlike the ati_remote{,2}
drivers, with no lirc_dev dependency at all, probably called simply
'imon'.


i.e. lirc_imon would support first+second gen, and imon third-gen 
devices, without overlap?


 But if I split it out, there may end up being a

fair amount of code duplication,


You could try to split common code into a third module used by the other 
two.  Or have one module for all devices which is a evdev/lirc hybrid.


cheers,
  Gerd

--
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: /dev/dvb/adapter0/net0 -- what is this for and how to use it?

2009-12-03 Thread pierre.gronlier
Leszek Koltunski wrote, On 12/03/2009 09:21 AM:
 Hello DVB gurus,
 
 I've got a TwinHan DVB-S2 card. I compiled the 'liplianin' drivers and
 it's working nicely; thanks for all your work!
 
 One question: in /dev/dvb/adapter0 I can see
 
 les...@satellite:~$ ls -l /dev/dvb/adapter0/
 total 0
 crw-rw+ 1 root video 212, 4 2009-12-02 18:22 ca0
 crw-rw+ 1 root video 212, 0 2009-12-02 18:22 demux0
 crw-rw+ 1 root video 212, 1 2009-12-02 18:22 dvr0
 crw-rw+ 1 root video 212, 3 2009-12-02 18:22 frontend0
 crw-rw+ 1 root video 212, 2 2009-12-02 18:22 net0
 
 What is this 'net0' device and how do I use it? Can I use it to
 directly multicast my (FTA) satellite stream to my lan by any chance?

You can use MuMuDVB for this: http://mumudvb.braice.net/

And net0 is related to network over dvb. look at the dvbnet tool (in
dvb-apps package)

Pierre

 
 I have found no documentation about this...

--
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 v2 0/3] patches for radio-si470x-i2c driver

2009-12-03 Thread Joonyoung Shim
Hi,

I post patches v2 for radio-si470x-i2c driver.

[PATCH v2 1/3] radio-si470x: move some file operations to common file
[PATCH v2 2/3] radio-si470x: support RDS on si470x i2c driver
[PATCH v2 3/3] radio-si470x: support PM functions

1/3 patch is same with v1.
2/3 patch is updated the RDS interrupt enable code by review of Tobias.
3/3 patch is to support PM.

And first patch of v1 is unnecessary by 2/3 patch of v2.

Thanks.
--
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 v2 3/3] radio-si470x: support PM functions

2009-12-03 Thread Joonyoung Shim
This patch is to support PM of the si470x i2c driver.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/media/radio/si470x/radio-si470x-i2c.c |   40 +
 1 files changed, 40 insertions(+), 0 deletions(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 77532e6..4c6e586 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -486,6 +486,44 @@ static __devexit int si470x_i2c_remove(struct i2c_client 
*client)
 }
 
 
+#ifdef CONFIG_PM
+/*
+ * si470x_i2c_suspend - suspend the device
+ */
+static int si470x_i2c_suspend(struct i2c_client *client, pm_message_t mesg)
+{
+   struct si470x_device *radio = i2c_get_clientdata(client);
+
+   /* power down */
+   radio-registers[POWERCFG] |= POWERCFG_DISABLE;
+   if (si470x_set_register(radio, POWERCFG)  0)
+   return -EIO;
+
+   return 0;
+}
+
+
+/*
+ * si470x_i2c_resume - resume the device
+ */
+static int si470x_i2c_resume(struct i2c_client *client)
+{
+   struct si470x_device *radio = i2c_get_clientdata(client);
+
+   /* power up : need 110ms */
+   radio-registers[POWERCFG] |= POWERCFG_ENABLE;
+   if (si470x_set_register(radio, POWERCFG)  0)
+   return -EIO;
+   msleep(110);
+
+   return 0;
+}
+#else
+#define si470x_i2c_suspend NULL
+#define si470x_i2c_resume  NULL
+#endif
+
+
 /*
  * si470x_i2c_driver - i2c driver interface
  */
@@ -496,6 +534,8 @@ static struct i2c_driver si470x_i2c_driver = {
},
.probe  = si470x_i2c_probe,
.remove = __devexit_p(si470x_i2c_remove),
+   .suspend= si470x_i2c_suspend,
+   .resume = si470x_i2c_resume,
.id_table   = si470x_i2c_id,
 };
 
-- 
1.6.3.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 v2 1/3] radio-si470x: move some file operations to common file

2009-12-03 Thread Joonyoung Shim
The read and poll file operations of the si470x usb driver can be used
also equally on the si470x i2c driver, so they go to the common file.

Signed-off-by: Joonyoung Shim jy0922.s...@samsung.com
---
 drivers/media/radio/si470x/radio-si470x-common.c |   98 ++
 drivers/media/radio/si470x/radio-si470x-i2c.c|   15 +---
 drivers/media/radio/si470x/radio-si470x-usb.c|   97 +-
 drivers/media/radio/si470x/radio-si470x.h|3 +-
 4 files changed, 104 insertions(+), 109 deletions(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-common.c 
b/drivers/media/radio/si470x/radio-si470x-common.c
index 7296cf4..f4645d4 100644
--- a/drivers/media/radio/si470x/radio-si470x-common.c
+++ b/drivers/media/radio/si470x/radio-si470x-common.c
@@ -426,6 +426,104 @@ int si470x_rds_on(struct si470x_device *radio)
 
 
 /**
+ * File Operations Interface
+ **/
+
+/*
+ * si470x_fops_read - read RDS data
+ */
+static ssize_t si470x_fops_read(struct file *file, char __user *buf,
+   size_t count, loff_t *ppos)
+{
+   struct si470x_device *radio = video_drvdata(file);
+   int retval = 0;
+   unsigned int block_count = 0;
+
+   /* switch on rds reception */
+   if ((radio-registers[SYSCONFIG1]  SYSCONFIG1_RDS) == 0)
+   si470x_rds_on(radio);
+
+   /* block if no new data available */
+   while (radio-wr_index == radio-rd_index) {
+   if (file-f_flags  O_NONBLOCK) {
+   retval = -EWOULDBLOCK;
+   goto done;
+   }
+   if (wait_event_interruptible(radio-read_queue,
+   radio-wr_index != radio-rd_index)  0) {
+   retval = -EINTR;
+   goto done;
+   }
+   }
+
+   /* calculate block count from byte count */
+   count /= 3;
+
+   /* copy RDS block out of internal buffer and to user buffer */
+   mutex_lock(radio-lock);
+   while (block_count  count) {
+   if (radio-rd_index == radio-wr_index)
+   break;
+
+   /* always transfer rds complete blocks */
+   if (copy_to_user(buf, radio-buffer[radio-rd_index], 3))
+   /* retval = -EFAULT; */
+   break;
+
+   /* increment and wrap read pointer */
+   radio-rd_index += 3;
+   if (radio-rd_index = radio-buf_size)
+   radio-rd_index = 0;
+
+   /* increment counters */
+   block_count++;
+   buf += 3;
+   retval += 3;
+   }
+   mutex_unlock(radio-lock);
+
+done:
+   return retval;
+}
+
+
+/*
+ * si470x_fops_poll - poll RDS data
+ */
+static unsigned int si470x_fops_poll(struct file *file,
+   struct poll_table_struct *pts)
+{
+   struct si470x_device *radio = video_drvdata(file);
+   int retval = 0;
+
+   /* switch on rds reception */
+   if ((radio-registers[SYSCONFIG1]  SYSCONFIG1_RDS) == 0)
+   si470x_rds_on(radio);
+
+   poll_wait(file, radio-read_queue, pts);
+
+   if (radio-rd_index != radio-wr_index)
+   retval = POLLIN | POLLRDNORM;
+
+   return retval;
+}
+
+
+/*
+ * si470x_fops - file operations interface
+ */
+static const struct v4l2_file_operations si470x_fops = {
+   .owner  = THIS_MODULE,
+   .read   = si470x_fops_read,
+   .poll   = si470x_fops_poll,
+   .ioctl  = video_ioctl2,
+   .open   = si470x_fops_open,
+   .release= si470x_fops_release,
+};
+
+
+
+/**
  * Video4Linux Interface
  **/
 
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index 2d53b6a..4816a6d 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -173,7 +173,7 @@ int si470x_disconnect_check(struct si470x_device *radio)
 /*
  * si470x_fops_open - file open
  */
-static int si470x_fops_open(struct file *file)
+int si470x_fops_open(struct file *file)
 {
struct si470x_device *radio = video_drvdata(file);
int retval = 0;
@@ -194,7 +194,7 @@ static int si470x_fops_open(struct file *file)
 /*
  * si470x_fops_release - file release
  */
-static int si470x_fops_release(struct file *file)
+int si470x_fops_release(struct file *file)
 {
struct si470x_device *radio = video_drvdata(file);
int retval = 0;
@@ -215,17 +215,6 @@ static int si470x_fops_release(struct file *file)
 }
 
 
-/*
- * si470x_fops - file operations interface
- */

[PATCH] max2165 32bit build patch

2009-12-03 Thread David T. L. Wong

Randy Dunlap wrote:

On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:


Stephen Rothwell wrote:

Hi all,

Changes since 20091127:

The v4l-dvb tree lost its conflict.


on i386 (X86_32):

a 'double' variable is used, causing:

ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!



linux-next-20091202:

still have this one (above) and similar with
drivers/media/dvb/frontends/atbm8830.c:

drivers/built-in.o: In function `atbm8830_init':
atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'

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


This patch drops usage of floating point variable for 32bit build

Signed-off-by: David T. L. Wong davidtlw...@gmail.com
diff --git a/linux/drivers/media/common/tuners/max2165.c b/linux/drivers/media/common/tuners/max2165.c
--- a/linux/drivers/media/common/tuners/max2165.c
+++ b/linux/drivers/media/common/tuners/max2165.c
@@ -193,7 +193,7 @@
 {
 	u8 tf;
 	u8 tf_ntch;
-	double t;
+	u32 t;
 	u32 quotient, fraction;
 
 	/* Set PLL divider according to RF frequency */
@@ -217,9 +217,6 @@
 	t += (priv-tf_balun_hi_ref - priv-tf_balun_low_ref)
 		* (freq / 1000 - 47) / (78 - 47);
 
-#if 0
-	tf = t + 0.5; /* round up */
-#endif
 	tf = t;
 	dprintk(tf = %X\n, tf);
 	tf |= tf_ntch  4;



[PATCH] atbm8830: replace 64-bit division and floating point usage

2009-12-03 Thread David T. L. Wong

Randy Dunlap wrote:

On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:


Stephen Rothwell wrote:

Hi all,

Changes since 20091127:

The v4l-dvb tree lost its conflict.


on i386 (X86_32):

a 'double' variable is used, causing:

ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!



linux-next-20091202:

still have this one (above) and similar with
drivers/media/dvb/frontends/atbm8830.c:

drivers/built-in.o: In function `atbm8830_init':
atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'

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


This patch replace 64-bit division by do_div() macro and remove usage of 
floating point variable


Signed-off-by: David T. L. Wong davidtlw...@gmail.com
diff --git a/linux/drivers/media/dvb/frontends/atbm8830.c b/linux/drivers/media/dvb/frontends/atbm8830.c
--- a/linux/drivers/media/dvb/frontends/atbm8830.c
+++ b/linux/drivers/media/dvb/frontends/atbm8830.c
@@ -19,6 +19,7 @@
  *Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
+#include asm/div64.h
 #include dvb_frontend.h
 
 #include atbm8830.h
@@ -102,8 +103,12 @@
 static int set_osc_freq(struct atbm_state *priv, u32 freq /*in kHz*/)
 {
 	u32 val;
+	u64 t;
 
-	val = (u64)0x10 * freq / 30400;
+	/* 0x10 * freq / 30.4MHz */
+	t = (u64)0x10 * freq;
+	do_div(t, 30400);
+	val = t;
 
 	atbm8830_write_reg(priv, REG_OSC_CLK, val);
 	atbm8830_write_reg(priv, REG_OSC_CLK + 1, val  8);
@@ -116,14 +121,18 @@
 {
 	
 	u32 fs = priv-config-osc_clk_freq;
-	double t;
+	u64 t;
 	u32 val;
 	u8 dat;
 
-	t = 2 * 3.141593 * (freq - fs) / fs * (1  22);
-	val = t;
+	if (freq != 0) {
+		/* 2 * PI * (freq - fs) / fs * (2 ^ 22) */
+		t = (u64) 2 * 31416 * (freq - fs);
+		t = 22;
+		do_div(t, fs);
+		do_div(t, 1000);
+		val = t;
 
-	if (freq != 0) {
 		atbm8830_write_reg(priv, REG_TUNER_BASEBAND, 1);
 		atbm8830_write_reg(priv, REG_IF_FREQ, val);
 		atbm8830_write_reg(priv, REG_IF_FREQ+1, val  8);


[PULL] http://kernellabs.com/hg/~mkrufky/hcw-ids

2009-12-03 Thread Michael Krufky
Mauro,

Please pull from:

http://kernellabs.com/hg/~mkrufky/hcw-ids

for:

- smsusb: add autodetection support for five additional Hauppauge USB IDs

 smsusb.c |   10 ++
 1 file changed, 10 insertions(+)

Regards,

Mike
--
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://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings

2009-12-03 Thread Karicheri, Muralidharan
Hans,

Thanks for sending this pull request. No problem in my name being mentioned in 
the spec.

Thanks. 

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com
-Original Message-
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: Wednesday, December 02, 2009 11:40 PM
To: linux-media@vger.kernel.org
Cc: Mauro Carvalho Chehab; Karicheri, Muralidharan
Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings

Hi Mauro,

Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-timings for
the following:

- v4l: Adding Digital Video Timings APIs
- v4l2-spec: Digital Video Timings API documentation
- v4l2-spec: updated revision history, updated version to 2.6.33.

Murali, I've added you as one of the authors of the v4l2-spec (you did this
timings API after all) and included your email as well. If that is a
problem
for you (either being mentioned at all, or that your email is mentioned),
then
let me know asap and I'll remove it. I don't expect it to be a problem
since
all this information is already public.

Mauro, before adding these documentation patches it is probably a good idea
to build and release a final 2.6.32 version of the documentation on
http://www.linuxtv.org/docs.php.

If you want to see an example of this api being used, then take a look at
the
tvp7002 driver patches that have been posted recently. I expect that driver
to be merged soon after this pull request is merged.

Thanks,

Hans

diffstat:
 b/linux/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml |  238
+++
 b/linux/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml |  111 +
 b/linux/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml|  224
++
 b/linux/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml |   85 +++
 linux/Documentation/DocBook/media-entities.tmpl  |   18
 linux/Documentation/DocBook/media-indices.tmpl   |4
 linux/Documentation/DocBook/v4l/common.xml   |   35 +
 linux/Documentation/DocBook/v4l/compat.xml   |   16
 linux/Documentation/DocBook/v4l/v4l2.xml |   26 +
 linux/Documentation/DocBook/v4l/videodev2.h.xml  |  116 +
 linux/Documentation/DocBook/v4l/vidioc-enuminput.xml |   36 +
 linux/Documentation/DocBook/v4l/vidioc-enumoutput.xml|   36 +
 linux/drivers/media/video/v4l2-compat-ioctl32.c  |6
 linux/drivers/media/video/v4l2-ioctl.c   |  147 ++
 linux/include/linux/videodev2.h  |  116 +
 linux/include/media/v4l2-ioctl.h |   15
 linux/include/media/v4l2-subdev.h|   21
 media-specs/Makefile |   14
 18 files changed, 1252 insertions(+), 12 deletions(-)



Fwd: DVB-APPS patch for uk-WinterHill

2009-12-03 Thread Justin Hornsby
Since 02 Dec 2009 the UK WinterHill transmitter site has been
broadcasting on different frequencies  in a different mode with
different modulation.  Channels have been re-arranged to occupy five
multiplexes and the original BBC 'B' mux is now broadcasting DVB-T2
for high definition services (which of course cannot yet be tuned by
mere mortals). The 'WinterHill B' transmitter stopped broadcasting on
02 Dec.

The attached file is a patch to reflect these changes.

NOTE: All UK DVB-T services will eventually be moving to 8k mode in
64QAM  other local frequencies will be changing once DSO (digital
switch over) is complete in each area.

Hope this info is of use to you folks :-)

Regards,
Justin

uk-WinterHill.patch

--- uk-WinterHill       2009-12-03 14:30:32.0 +
+++ uk-WinterHill.new   2009-12-03 14:26:05.0 +
@@ -1,13 +1,11 @@
 # UK, Winter Hill
-# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html
-# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html
+# Populated by J. Hornsby from a scan of active multiplexes
 # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
-T 754167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 834167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
-T 850167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
-T 842167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 786167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 810167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-# UK, Winter Hill B
-T 65000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 62600 8MHz 3/4 NONE QAM16 2k 1/32 NONE
+T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+
+# UK, Winter Hill B Ceased broadcasting on 02 December 2009
+
--- uk-WinterHill	2009-12-03 14:30:32.0 +
+++ uk-WinterHill.new	2009-12-03 14:26:05.0 +
@@ -1,13 +1,11 @@
 # UK, Winter Hill
-# Auto-generated from http://www.dtg.org.uk/retailer/dtt_channels.html
-# and http://www.ofcom.org.uk/static/reception_advice/index.asp.html
+# Populated by J. Hornsby from a scan of active multiplexes
 # T freq bw fec_hi fec_lo mod transmission-mode guard-interval hierarchy
-T 754167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 834167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
-T 850167000 8MHz 2/3 NONE QAM64 2k 1/32 NONE
-T 842167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 786167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 810167000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-# UK, Winter Hill B
-T 65000 8MHz 3/4 NONE QAM16 2k 1/32 NONE
-T 62600 8MHz 3/4 NONE QAM16 2k 1/32 NONE
+T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
+
+# UK, Winter Hill B Ceased broadcasting on 02 December 2009
+


Syncing videobuf buffers before an operation

2009-12-03 Thread Pawel Osciak
Hello!

We have been facing the problem of sync()ing buffers before performing
operations on them.

This is the current buffer life cycle in videobuf (for streaming, slightly
simplified):

- qbuf:
  buf_prepare, from which drivers call videobuf_iolock() if the state is
  VIDEOBUF_NEEDS_INIT (i.e. once per streamon)

- dqbuf:
  where per-memory method sync() is called

- streamoff:
  where buffers are released (i.e. iolock is released)


We are working with devices that have a non-coherent cache (ARM-based).
For them sync()ing means flushing CPU cache for the physical memory to
contain valid data. We require syncing buffers not only after, but before
running the operation as well.

For CAPTURE devices this prevents corruption in case a flush occurs after
the operation has finished and overwrites the results with old data (from
before the operation).

For OUTPUT-type devices sync()ing is even more important, as the source
data may be completely invalid before the operation - before DMA can
be started, CPU cache has to be flushed.


We have divided sync operations into the following types:
- sync CAPTURE buffers before the operation
- sync CAPTURE buffers after the operation
- sync OUTPUT buffers before the operation

Our idea is to add an additional sync() call to videobuf_qbuf and
a parameter that would allow differentiating between syncs before and
after the operation. Alternatively, an additional function for that
could be added, if we don't want to change the API.

Please note that this is different from iolock(). Iolock is performed
once per streamon and what we need is a sync (which should also be
more lightweight than a full iolock) per each qbuf.

I would be grateful for your opinions on this topic. We'd like to
propose a patch if we come to an agreement on this as well.
Thank you!


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 - v0 2/2] DaVinci - vpfe capture - Make clocks configurable

2009-12-03 Thread Karicheri, Muralidharan
I was talking to Sekhar about this and actually he made some good points
about this implementation.

If we consider specific IP, then the required clocks would remain always be
the same. There might be some devices which may not be using some clocks
(so as that specific feature).

Actually we are trying to create one more wrapper for clock configuration.
Just to illustrate I am putting some other generic drivers examples -

Omap-hsmmc.c -

This driver requires 2 clocks, interface and functional. The devices which
would be using this driver have to define clock with names ick and fck.

VPFE-Capture (Considering only current implementation) -

Currently we have vpfe_capture.c file (master/bridge driver) which is
handling clk_get/put, and platform data is providing the details about it.
Ideally we should handle it in respective ccdc driver file, since he has
all the knowledge about required number of clocks and its name. This way we
don't have to maintain/pass clock information in platform data.

I would appreciate any comments/thoughts/pointers here.

Though I agree that this clock could be set by the ccdc driver, I am not sure 
if the same clock is used by an IP on different SOCs. For example take
the case of ccdc on DM6446 which is also used on OMAP 35xx SOC. Do they use
vpss master and slave clocks as is done on DM6446? If this is true, then we
could set the clock inside ccdc driver. 

Let me know so that I can re-work the patch and send it to the list.

Murali
Thanks,
Vaibhav

  };

  static struct platform_device *davinci_evm_devices[] __initdata = {
 diff --git a/arch/arm/mach-davinci/board-dm644x-evm.c
 b/arch/arm/mach-davinci/board-dm644x-evm.c
 index fd0398b..45beb99 100644
 --- a/arch/arm/mach-davinci/board-dm644x-evm.c
 +++ b/arch/arm/mach-davinci/board-dm644x-evm.c
 @@ -250,6 +250,8 @@ static struct vpfe_config vpfe_cfg = {
  .sub_devs = vpfe_sub_devs,
  .card_name = DM6446 EVM,
  .ccdc = DM6446 CCDC,
 +.num_clocks = 2,
 +.clocks = {vpss_master, vpss_slave},
  };

  static struct platform_device rtc_dev = {
 --
 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: [RFC v2] Another approach to IR

2009-12-03 Thread Ferenc Wagner
Mauro Carvalho Chehab mche...@redhat.com writes:

 Dmitry Torokhov wrote:

 On Dec 2, 2009, at 2:56 PM, Dmitry Torokhov wrote:

 Now I understand that if 2 remotes send completely identical
 signals we won't be able to separete them, but in cases when we
 can I think we should.

 They are the same key events (Lets's say KEY_PLAY) but one is
 supposed to affect CD player while another DVD player
 application. Evdev will not be able to distinguish them but if we had
 2 separate devices then applications could read from the one thet
 user assigned to them.

 This is clear, but the point is that the two distinguish scancodes can
 (and, in practice, will) be generated by the same IR. For example, my
 Satellite IR produces two different sets of codes. if you press SAT,
 all keys you press after that will have the sat address. If you
 press TV, they'll get a different address.

The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
by any remote (ok, I'm stretching it a bit).  Instead, a multifunction
remote (or two distinct remotes) would send different scan codes[1],
which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
Btw. the former is already defined, besides the generic KEY_PLAY.

Even if all this worked, user space would need integration with
hal/devicekit to open the new input devices appearing on the fly (if
it's initiated by the arrival of a scan code belonging to some new
protocol), and also be able to decide whether the new event source is
for it or not.

Given that commodity home appliances manage not to be confused by
multiple or multifunction remotes, decent software should be able to do
so as well.

[1] scan codes in the broadest possible sense, containing vendor,
address and whatever, and only treating the case which is possible to
handle in principle.
-- 
Regards,
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: [PATCH] V4L/DVB: pms: KERNEL_VERSION requires version.h

2009-12-03 Thread Randy Dunlap
On Thu,  3 Dec 2009 12:48:27 +0300 Alexander Beregalov wrote:

 Fix this build error:
 drivers/media/video/pms.c:682: error: implicit declaration of function 
 'KERNEL_VERSION'
 
 Signed-off-by: Alexander Beregalov a.berega...@gmail.com

I've already sent this patch, so I can also ack it...

Acked-by: Randy Dunlap randy.dun...@oracle.com


 ---
  drivers/media/video/pms.c |1 +
  1 files changed, 1 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/media/video/pms.c b/drivers/media/video/pms.c
 index 00228d5..a118bb1 100644
 --- a/drivers/media/video/pms.c
 +++ b/drivers/media/video/pms.c
 @@ -35,6 +35,7 @@
  #include media/v4l2-ioctl.h
  #include media/v4l2-device.h
  #include linux/mutex.h
 +#include linux/version.h
  
  #include asm/uaccess.h
  
 -- 


---
~Randy
--
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: [linux-dvb] ds3000.c driver question (Tevii S660 USB DVB-S/S2 tuner)

2009-12-03 Thread Matthias
Dear Michael,

We have update Linux driver released today; you can find it from the link
below
http://www.tevii.com/Support.asp

TeVii Support

-Original Message-
From: linux-dvb-boun...@linuxtv.org [mailto:linux-dvb-boun...@linuxtv.org]
On Behalf Of Michael Durket
Sent: Wednesday, December 02, 2009 10:39 PM
To: linux-...@linuxtv.org
Subject: [linux-dvb] ds3000.c driver question (Tevii S660 USB DVB-S/S2
tuner)

I have some questions about the ds3000.c driver. I (and also someone at
Tevii at my 
request) have attempted to contact the driver author to no avail. Is there
anyone here
familiar enough with that driver (and the firmware) that can answer some
detailed questions
about the device?


___
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


[PATCH - v1] V4L - Documentation:Adds EBUSY error code for S_STD and QUERYSTD ioctls

2009-12-03 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

During review of Video Timing API documentation, Hans Verkuil had a comment
on adding EBUSY error code for VIDIOC_S_STD and VIDIOC_QUERYSTD ioctls. This
patch updates the document for this.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
diff -uNr 
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-g-std.xml 
v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-g-std.xml
--- 
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-g-std.xml
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-g-std.xml 
2009-12-03 11:18:34.0 -0500
@@ -86,6 +86,12 @@
 constantVIDIOC_S_STD/constant parameter was unsuitable./para
/listitem
   /varlistentry
+  varlistentry
+   termerrorcodeEBUSY/errorcode/term
+   listitem
+ paraThe device is busy and therefore can not change the 
standard/para
+   /listitem
+  /varlistentry
 /variablelist
   /refsect1
 /refentry
diff -uNr 
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-querystd.xml 
v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-querystd.xml
--- 
v4l-dvb-e0cd9a337600_master/linux/Documentation/DocBook/v4l/vidioc-querystd.xml 
2009-12-01 17:02:04.0 -0500
+++ v4l-dvb_patch1/linux/Documentation/DocBook/v4l/vidioc-querystd.xml  
2009-12-03 11:18:44.0 -0500
@@ -70,6 +70,12 @@
  paraThis ioctl is not supported./para
/listitem
   /varlistentry
+  varlistentry
+   termerrorcodeEBUSY/errorcode/term
+   listitem
+ paraThe device is busy and therefore can not detect the 
standard/para
+   /listitem
+  /varlistentry
 /variablelist
   /refsect1
 /refentry
--
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 v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Ferenc Wagner wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 Dmitry Torokhov wrote:


 The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
 KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
 by any remote (ok, I'm stretching it a bit). 

Unfortunately, this is not true. Some IR's do send a keycode for TV/PC/SAT/CD, 
etc.

On those remotes, if you press TV and then press for example Channel UP
and press Radio, then press Channel UP, the channel UP code will be the same.

For example, on Hauppauge Grey IR, we have:

TV
[13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e1c 
keycode 0x179
[13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
down=1
[13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
down=0

CHANNEL UP
[13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 
keycode 0x192
[13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=1
[13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=0

Radio
[13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e0c 
keycode 0x181
[13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
down=1
[13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
down=0

CHANNEL UP
[13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 0x1e20 
keycode 0x192
[13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=1
[13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
down=0

In this IR, the address is bogus: it is always 0x1e. This scenario is very 
common with the
shipped IR's.

 Instead, a multifunction
 remote (or two distinct remotes) would send different scan codes[1],
 which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
 Btw. the former is already defined, besides the generic KEY_PLAY.
 
 Even if all this worked, user space would need integration with
 hal/devicekit to open the new input devices appearing on the fly (if
 it's initiated by the arrival of a scan code belonging to some new
 protocol), and also be able to decide whether the new event source is
 for it or not.
 
 Given that commodity home appliances manage not to be confused by
 multiple or multifunction remotes, decent software should be able to do
 so as well.
 
 [1] scan codes in the broadest possible sense, containing vendor,
 address and whatever, and only treating the case which is possible to
 handle in principle.

I see two alternatives for it:
1) to map a multifunction scancode Address=TV/command=channel up as two
separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to
handle it (lirc or other programs that knows IR keycodes);

2) to implement Jon's filter idea of splitting one evdev interface into
several evdevs interface, one for each address.

We should not forget that simple IR's don't have any key to select the address,
so the produced codes there will never have KEY_TV/KEY_DVD, etc.

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: [RFC v2] Another approach to IR

2009-12-03 Thread Jon Smirl
On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
 Ferenc Wagner wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:

 Dmitry Torokhov wrote:


 The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
 KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
 by any remote (ok, I'm stretching it a bit).

 Unfortunately, this is not true. Some IR's do send a keycode for 
 TV/PC/SAT/CD, etc.

 On those remotes, if you press TV and then press for example Channel UP
 and press Radio, then press Channel UP, the channel UP code will be the same.

 For example, on Hauppauge Grey IR, we have:

 TV
 [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e1c keycode 0x179
 [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
 down=1
 [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event code=377 
 down=0

 CHANNEL UP
 [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e20 keycode 0x192
 [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=1
 [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=0

 Radio
 [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e0c keycode 0x181
 [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
 down=1
 [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event code=385 
 down=0

 CHANNEL UP
 [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
 0x1e20 keycode 0x192
 [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=1
 [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event code=402 
 down=0

 In this IR, the address is bogus: it is always 0x1e. This scenario is very 
 common with the
 shipped IR's.

The remote is treating everything as a single integrated device which
is not inconsistent with what has been said. In this case there really
is only one multi-function device not two independent ones.

If you want to control two independent devices you need to buy a
different remote. Remotes are cheap so that's not a big deal.

If you really want to use this remote to control two independent
devices you need user space scripting to split the single device into
two devices and then inject new events into the input layer. This is a
complex case and not in the goal of getting 90% of users to just
work.


 Instead, a multifunction
 remote (or two distinct remotes) would send different scan codes[1],
 which should be mapped to KEY_PLAYCD and KEY_PLAYDVD for example.
 Btw. the former is already defined, besides the generic KEY_PLAY.

 Even if all this worked, user space would need integration with
 hal/devicekit to open the new input devices appearing on the fly (if
 it's initiated by the arrival of a scan code belonging to some new
 protocol), and also be able to decide whether the new event source is
 for it or not.

 Given that commodity home appliances manage not to be confused by
 multiple or multifunction remotes, decent software should be able to do
 so as well.

 [1] scan codes in the broadest possible sense, containing vendor,
 address and whatever, and only treating the case which is possible to
 handle in principle.

 I see two alternatives for it:
        1) to map a multifunction scancode Address=TV/command=channel up as two
 separate events: KEY_TV | KEY_CHANNELUP and let some userspace program to
 handle it (lirc or other programs that knows IR keycodes);

        2) to implement Jon's filter idea of splitting one evdev interface into
 several evdevs interface, one for each address.

 We should not forget that simple IR's don't have any key to select the 
 address,
 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

 Cheers,
 Mauro.




-- 
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] max2165 32bit build patch

2009-12-03 Thread Randy Dunlap
On Thu, 03 Dec 2009 21:54:25 +0800 David T. L. Wong wrote:

 Randy Dunlap wrote:
  On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:
  
  Stephen Rothwell wrote:
  Hi all,
 
  Changes since 20091127:
 
  The v4l-dvb tree lost its conflict.
 
  on i386 (X86_32):
 
  a 'double' variable is used, causing:
 
  ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
  ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
  ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!
  
  
  linux-next-20091202:
  
  still have this one (above) and similar with
  drivers/media/dvb/frontends/atbm8830.c:
  
  drivers/built-in.o: In function `atbm8830_init':
  atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
  atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
  atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
  atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
  atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
  atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
  atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'
  
  ---
 
 This patch drops usage of floating point variable for 32bit build
 
 Signed-off-by: David T. L. Wong davidtlw...@gmail.com

Acked-by: Randy Dunlap randy.dun...@oracle.com

Please generate patches so that they can be applied by using
$ patch -p1
at the top of the kernel source tree.

Thanks.
---
~Randy
--
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] atbm8830: replace 64-bit division and floating point usage

2009-12-03 Thread Randy Dunlap
On Thu, 03 Dec 2009 21:57:02 +0800 David T. L. Wong wrote:

 Randy Dunlap wrote:
  On Mon, 30 Nov 2009 10:07:21 -0800 Randy Dunlap wrote:
  
  Stephen Rothwell wrote:
  Hi all,
 
  Changes since 20091127:
 
  The v4l-dvb tree lost its conflict.
 
  on i386 (X86_32):
 
  a 'double' variable is used, causing:
 
  ERROR: __floatunsidf [drivers/media/common/tuners/max2165.ko] undefined!
  ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
  ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!
  
  
  linux-next-20091202:
  
  still have this one (above) and similar with
  drivers/media/dvb/frontends/atbm8830.c:
  
  drivers/built-in.o: In function `atbm8830_init':
  atbm8830.c:(.text+0x9012f9): undefined reference to `__udivdi3'
  atbm8830.c:(.text+0x901384): undefined reference to `__floatunsidf'
  atbm8830.c:(.text+0x901395): undefined reference to `__muldf3'
  atbm8830.c:(.text+0x9013a5): undefined reference to `__floatunsidf'
  atbm8830.c:(.text+0x9013b2): undefined reference to `__divdf3'
  atbm8830.c:(.text+0x9013c3): undefined reference to `__muldf3'
  atbm8830.c:(.text+0x9013cd): undefined reference to `__fixunsdfsi'
  
  ---
 This patch replace 64-bit division by do_div() macro and remove usage of 
 floating point variable
 
 Signed-off-by: David T. L. Wong davidtlw...@gmail.com

Acked-by: Randy Dunlap randy.dun...@oracle.com

---
~Randy
--
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 v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté

Jon Smirl wrote:
 On Wed, Dec 2, 2009 at 11:13 PM, Jarod Wilson ja...@wilsonet.com wrote:
 On Dec 2, 2009, at 9:48 PM, Trent Piepho wrote:
 ...
 Now I understand that if 2 remotes send completely identical signals we
 won't be able to separate them, but in cases when we can I think we
 should.
 I don't have a problem with that, if its a truly desired feature.  But
 for the most part, I don't see the point.  Generally, you go from
 having multiple remotes, one per device (where device is your TV,
 amplifier, set top box, htpc, etc), to having a single universal remote
 that controls all of those devices.  But for each device (IR receiver),
 *one* IR command set.  The desire to use multiple distinct remotes with
 a single IR receiver doesn't make sense to me.  Perhaps I'm just not
 creative enough in my use of IR.  :)
 Most universal remotes I'm familiar with emulate multiple remotes.  I.e.
 my tv remote generates one set of scancodes for the numeric keys.  The DVD
 remote generates a different set.  The amplifier remote in tv mode
 generates the same codes as the tv remote, and in dvd mode the same codes
 as the dvd remote.  From the perspective of the IR receiver there is no
 difference between having both the DVD and TV remotes, or using the
 aplifier remote to control both devices.
 Okay, in the above scenario, you've still got a single input device...

 Now, my aplifier remote has a number of modes.  Some control devices I
 have, like vcr mode, and there is nothing I can do about that.  Some,
 like md mode don't control devices I have.  That means they are free to
 do things on the computer.  Someone else with the same remote (or any
 number of remotes that use the same protocol and scancodes) might have
 different devices.

 So I want my computer to do stuff when I push JVC MD #xx keys, but ignore
 JVC VCR #yyy yets.  Someone with an MD player and not a VCR would want to
 opposite.  Rather than force everyone to create custom keymaps, it's much
 easier if we can use the standard keymaps from a database of common remotes
 and simply tell mythtv to only use remote #xxx or not to use remote #yyy.
 Sure, but the key is that this can't be done automagically. The IR driver has no way 
of knowing that user A wants JVC MD keys handled and JVC VCR keys ignored, and user B wants 
vice versa, while user C wants both ignored, etc. This is somewhat tangential to whether or not 
there's a separate input device per remote though. You can use multiple 
remotes/protocols with a single input device or lirc device already (if the hardware doesn't 
have to be put explicitly into a mode to listen for that proto, of course, but then its a 
hardware decoding device feeding a single input device anyway, so...).

 It sounds like you're thinking of a receiver that came bundled with a
 remote and that's it.  Not someone with a number of remotes that came with
 different pieces of AV gear that they want to use with their computer.
 No, I just pick *one* remote and use it for everything, not 
schizophrenically hopping from one remote to another, expecting them all the be able 
to control everything. :) Its a hell of a lot easier to find buttons w/o looking at 
the remote if you always use the same one for everything, for one.

 Anyway, I think I'm talking myself in circles. Supporting multiple remotes 
via multiple input devices (or even via a single input device) isn't at all 
interesting to me for my own use, but if there really is demand for such support (and 
it appears there is), then fine, lets do it.
 
 Simple use case:
 
 You have a multifunction remote. Press the CABLE key - it sends out

 commands that control the cable box, press the TV key - now the
 commands control the TV, press CD - now the CD player, etc.
 
 Now imagine a headless Linux box running a music server and a home

 automation app. Press the CD key - commands get routed to the music
 server, press the AUX key - commands get routed to the home automation
 app.
 
 This is accomplished by recognizing the device code part of the IR

 signal and figuring out that there are two different device codes in
 use. The commands of then routed to two evdev devices corresponding to
 the two different device codes.
 
 Using things like Alt-Tab to switch apps is impossible. There's no

 screen to look at.

This usecase makes sense to me.

With the risk of repeating myself, you don't have two physical remotes.
The needed feature is a way to split one source of input events (that
happens to be an infrared remote, but it could also be any other type of input
device, like a bluetooth remote) into several different evdev interfaces,
based on scancode groups. 


In real world you generally have two physical remote. In this particular case 
you simply have a sort of semi-universal remote, a two or tree in one remote.
More particularly, you have a remote which is aimed at talking to two or tree different 
real devices or in our case different applications. If the application 

Re: [RFC v2] Another approach to IR

2009-12-03 Thread Dmitry Torokhov
On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
 Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
 We should not forget that simple IR's don't have any key to select the 
 address,
 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
media inputs in a device/application. My receiver accepts codees like
that.

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

2009-12-03 Thread Krzysztof Halasa
l...@bartelmus.de (Christoph Bartelmus) writes:

 Currently I would tend to an approach like this:
 - raw interface to userspace using LIRC
 - fixed set of in-kernel decoders that can handle bundled remotes

I'd modify it a bit:
- raw interface to userspace using LIRC
- fixed set of in-kernel decoders

Longer term:

Removing the key assignment tables from the kernel. Plug-and-play can be
then achieved with udev. The only thing needed from the kernel is
indicating the tuner/sensor type, udev can guess the bundled remote type.

Porting the in-kernel drivers (such as ir-common) to LIRC interface
(while not removing the input layer mode).
-- 
Krzysztof Halasa
--
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?

2009-12-03 Thread Krzysztof Halasa
Gerd Hoffmann kra...@redhat.com writes:

 I'd pick a more descriptive name like 'bundled_remote'.
 Maybe an additional attribute could say which protocol the bundled
 remote speaks (rc5, ...), so userspace could do something sensible by
 default even if it has no data about the bundled remote.

This is problematic since there can be more that one remote bundled.
If we export the sensor (tuner etc) name, userspace can make some
decision (or ask the user etc).

The protocol alone won't help - the user will have to teach the system
about the remote anyway. This should be made trivial at least for common
protocols, though.

 Name them by the hardware they are bundled with should work reasonable
 well.

I guess udev can look at parent PCI vendor/device and subsystem
vendor/device for most PCI cases. Ditto with USB. For generic stuff like
TSOP* coupled with a resistor and connected to RS232 port, we can't
guess anyway.

 We also could also provide a list of possible remotes directly via
 sysfs

The kernel has no way to _know_ this information. The policy is better
handled in userland.

 Anyway, we shouldn't postpone lirc drivers addition due to that.

Actually merging lirc is a prerequisite for a number of changes.
-- 
Krzysztof Halasa
--
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?

2009-12-03 Thread Dmitry Torokhov
On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote:
 On 12/03/09 05:29, Jarod Wilson wrote:
 On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:

 Anyway, we shouldn't postpone lirc drivers addition due to that.
 There are still lots of work to do before we'll be able to split
 the tables from the kernel drivers.

 Indeed.  The sysfs bits are future work for both lirc and evdev
 drivers.  There is no reason to make the lirc merge wait for it.

 At this point, my plan is to try to finish cleaning up lirc_dev and
 lirc_mceusb at least over the weekend while at FUDCon up in Toronto,
 and resubmit them next week.

 Good plan IMHO.  Having lirc_dev merged quickly allows in-kernel drivers  
 start supporting lirc.

No, please, wait just a minute. I know it is tempting to just merge
lirc_dev and start working, but can we first agree on the overall
subsystem structure before doing so. It is still quite inclear to me.

The open questions (for me at least):

- do we create a new class infrastructure for all receivers or only for
  ones plugged into lirc_dev? Remember that classifying objects affects
  how udev and friemds see them and may either help or hurt writing PnP
  rules.

- do we intend to support in-kernel sotfware decoders? What is the
  structure? Do we organize them as a module to be used by driver
  directly or the driver streams the data to IR core and the core
  applies decoders (in the same fashion input events from drivers flow
  into input core and then distributed to all bound interfaces for
  processing/conversion/transmission to userspace)?

- how do we control which decoder should handle particular
  receiver/remote? Is it driver's decision, decoder's decision, user's
  or all of the above?

- do we allow to have several decorers active at once for a receiver?

- who decides that we want to utilize lirc_dev? Driver's themselves, IR
  core (looking at the driver/device capabilities), something else?

- do we recognize and create input devices on-fly or require user
  intervention? Semantics for splitting into several input/event
  devices?

Could anyone please draw me a picture, starting with a receiver
piece of hardware. I am not concerned much with how exactly receiver is
plugged into a particular subsystem (DVB/V4L etc) since it would be
_their_ implementation detail, but with the flow in/out of that
receiver device.

Now as far as input core goes I see very limited number of changes that
may be needed:

- Allow to extend size of scancode in EVIOC{S,G}KEYCODE if we are
  unable to limit ourselves to 32 bits (keeping compatibility of course)

- Maybe adding new ioctl to zap the keymap table

- Adding more key EV_KEY/KEY_* definitons, if needed

Thanks.

-- 
Dmitry
--
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 v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté


Em Thu, 3 Dec 2009 11:50:04 -0500
Jon Smirl jonsm...@gmail.com escreveu:

 On Thu, Dec 3, 2009 at 11:33 AM, Mauro Carvalho Chehab
 mche...@redhat.com wrote:
  Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
  Dmitry Torokhov wrote:
 
 
  The interesting thing is that input.h defines KEY_TV, KEY_PC, KEY_SAT,
  KEY_CD, KEY_TAPE etc., but no corresponding scan codes will ever be sent
  by any remote (ok, I'm stretching it a bit).
 
  Unfortunately, this is not true. Some IR's do send a keycode for 
TV/PC/SAT/CD, etc.
 
  On those remotes, if you press TV and then press for example Channel UP
  and press Radio, then press Channel UP, the channel UP code will be the 
same.
 
  For example, on Hauppauge Grey IR, we have:
 
  TV
  [13425.128525] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e1c keycode 0x179
  [13425.136733] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=377 down=1
  [13425.144170] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=377 down=0
 
  CHANNEL UP
  [13428.350223] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e20 keycode 0x192
  [13428.358434] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=1
  [13428.365871] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=0
 
  Radio
  [13430.672266] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e0c keycode 0x181
  [13430.680473] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=385 down=1
  [13430.687913] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=385 down=0
 
  CHANNEL UP
  [13433.697268] ir_g_keycode_from_table: em28xx IR (em28xx #0): scancode 
0x1e20 keycode 0x192
  [13433.705480] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=1
  [13433.712916] ir_input_key_event: em28xx IR (em28xx #0): key event 
code=402 down=0
 
  In this IR, the address is bogus: it is always 0x1e. This scenario is very 
common with the
  shipped IR's.
 
 The remote is treating everything as a single integrated device which

 is not inconsistent with what has been said. In this case there really
 is only one multi-function device not two independent ones.
 
 If you want to control two independent devices you need to buy a

 different remote. Remotes are cheap so that's not a big deal.
 
 If you really want to use this remote to control two independent

 devices you need user space scripting to split the single device into
 two devices and then inject new events into the input layer. This is a
 complex case and not in the goal of getting 90% of users to just
 work.

This remote is a typical example of the IR's that are provided together with 
media boards.
On all such IR's I know, it does generate one key event for TV, SAT, DVB, 
DVD... keys and
this event doesn't change the status of subsequent keys.

100% of the users of such boards will have the shipped IR. Some amount will be 
happy of
just using the provided IR to control different applications at their computer 
or embedded
hardware, and some amount will prefer to buy a multi-purpose IR that will allow 
him
to control not only his computer, but also, his TV, his Air conditioning, etc.

Both usages should be supported.

All I'm saying is that, in the case where people have only the shipped IR, if 
he wants to
see TV, the produced keycode will be KEY_TV, and then to change a channel, it 
will
receive KEY_CHANNELUP, to control his TV app. When the user decides to switch to DVB, 
he will press KEY_DVB and then KEY_PLAY to play his movie.


So, an application like MythTV should be able to work with those keys.
  

Eeeerrrkkk, what a .. device .
For such quirky device, we could imagine a special mapping support:
We could maps scancode 0x1e1c and 0x1e0c special keycode wich inform the 
input layer to surcharge the  vendor or device with a specific 
value/mask for following  keypresses of such remote. The mask could be 
choose to generate out of bound value in regards of the used protocol 
for the vendor or the device part to not overlap with another existing 
remote.
Generate a complete map and so a device for each special key and you're 
done. No special case on the application side.
In kernel states are a bit ugly, but this particular case is not too 
complicated and your dumb shitty remote is promoted to first class one.



Regards,
Emmanuel.


--
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 v2] Another approach to IR

2009-12-03 Thread Emmanuel Fusté


On Thu, Dec 03, 2009 at 02:33:56PM -0200, Mauro Carvalho Chehab wrote:
 Ferenc Wagner wrote:
  Mauro Carvalho Chehab mche...@redhat.com writes:
 
 We should not forget that simple IR's don't have any key to select the address,

 so the produced codes there will never have KEY_TV/KEY_DVD, etc.

Wait, wait, KEY_TV, KEY_DVD, KEY_TAPE - they should be used to select
media inputs in a device/application. My receiver accepts codees like
that.
  

Yes, it seem that there is confusion here.
Forget my proposition. It is a corner case that could be handled later 
if needed.



Cheers,
Emmanuel.
--
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 v2] Another approach to IR

2009-12-03 Thread Krzysztof Halasa
Jarod Wilson ja...@wilsonet.com writes:

 Perhaps we should clarify something here. Are we intending to
 auto-create a new input device for every IR command set we see arrive
 at the IR receiver?

We don't want this, and we aren't really able to do this, because we
never know if two different scan codes are part of the same or different
command set.

Sharing the protocol and e.g. group code doesn't mean it's the same
remote.

Different protocol doesn't mean it's a different remote and what's more
important, doesn't mean the user wants it to be a different logical
remote.
-- 
Krzysztof Halasa
--
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 v2] Another approach to IR

2009-12-03 Thread Krzysztof Halasa
Mauro Carvalho Chehab mche...@redhat.com writes:

 Btw, looking at that code, while it is not impossible to split the 
 IR pulse/space measures from the NEC decoder itself, and make it generic
 to support other protocols, it is not a trivial task, and may result on
 a less stable driver.

And it's not needed at all.
Protocol decoders can be easily run in parallel, I've done it on saa713x
and this is trivial at least there. Can do that when the lirc interface
is available.

 The advantage of the NEC decoding approach on saa7134 is that you know for
 sure how much time it is required to get the entire code. So, the code 
 can easily abort the reception of a bad code. The disadvantage is that 
 only one protocol can be decoded at the same time.

This isn't a hard thing to fix.

 The same problem also happens with almost all in-kernel drivers: the decoders
 for raw mode were constructed to work with just one pulse/space code at the
 same time. A conversion into a generic code can happen, but it will require
 several tests to be sure that they won't cause undesirable side-effects.

IOW any such receiver has to be tested, sure.

 The advantage of hardware decoders is that you don't need to be polling the
 IR serial port at a high rate, as you'll get directly the code. So, you'll
 free the CPU to do something else.

Which device requires polling the port?
Most are IRQ-driven, aren't they?
-- 
Krzysztof Halasa
--
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, RFC] Document the videobuf layer

2009-12-03 Thread Jonathan Corbet
I've taken the liberty of dropping this into my docs-next tree, and
will send it upward unless there are objections.  Hopefully it's
useful...

jon
---
V4L2: Add a document describing the videobuf layer

Videobuf is a moderately complex API which most V4L2 drivers should use,
but its documentation is...sparse.  This document attempts to improve the
situation.

Signed-off-by: Jonathan Corbet cor...@lwn.net

diff --git a/Documentation/video4linux/videobuf 
b/Documentation/video4linux/videobuf
new file mode 100644
index 000..4e21ea7
--- /dev/null
+++ b/Documentation/video4linux/videobuf
@@ -0,0 +1,341 @@
+An introduction to the videobuf layer
+Jonathan Corbet cor...@lwn.net
+Current as of 2.6.32
+
+The videobuf layer functions as a sort of glue layer between a V4L2 driver
+and user space.  It handles the allocation and management of buffers for
+the storage of video frames.  There is a set of functions which can be used
+to implement many of the standard POSIX I/O system calls, including read(),
+poll(), and, happily, mmap().  Another set of functions can be used to
+implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
+including buffer allocation, queueing and dequeueing, and streaming
+control.  Using videobuf imposes a few design decisions on the driver
+author, but the payback comes in the form of reduced code in the driver and
+a consistent implementation of the V4L2 user-space API.
+
+Buffer types
+
+Not all video devices use the same kind of buffers.  In fact, there are (at
+least) three common variations:
+
+ - Buffers which are scattered in both the physical and (kernel) virtual
+   address spaces.  All user-space buffers are like this, but it makes
+   great sense to allocate kernel-space buffers this way as well when it is
+   possible.  Unfortunately, it is not always possible; working with this
+   kind of buffer normally requires hardware which can do scatter/gather
+   DMA operations.
+
+ - Buffers which are physically scattered, but which are virtually
+   contiguous; buffers allocated with vmalloc(), in other words.  These
+   buffers are just as hard to use for DMA operations, but they can be
+   useful in situations where DMA is not available but virtually-contiguous
+   buffers are convenient.
+
+ - Buffers which are physically contiguous.  Allocation of this kind of
+   buffer can be unreliable on fragmented systems, but simpler DMA
+   controllers cannot deal with anything else.
+
+Videobuf can work with all three types of buffers, but the driver author
+must pick one at the outset and design the driver around that decision.
+
+Data structures, callbacks, and initialization
+
+Depending on which type of buffers are being used, the driver should
+include one of the following files:
+
+media/videobuf-dma-sg.h  /* Physically scattered */
+media/videobuf-vmalloc.h /* vmalloc() buffers*/
+media/videobuf-dma-contig.h  /* Physically contiguous */
+
+The driver's data structure describing a V4L2 device should include a
+struct videobuf_queue instance for the management of the buffer queue,
+along with a list_head for the queue of available buffers.  There will also
+need to be an interrupt-safe spinlock which is used to protect (at least)
+the queue.
+
+The next step is to write four simple callbacks to help videobuf deal with
+the management of buffers:
+
+struct videobuf_queue_ops {
+   int (*buf_setup)(struct videobuf_queue *q,
+unsigned int *count, unsigned int *size);
+   int (*buf_prepare)(struct videobuf_queue *q,
+  struct videobuf_buffer *vb,
+  enum v4l2_field field);
+   void (*buf_queue)(struct videobuf_queue *q,
+ struct videobuf_buffer *vb);
+   void (*buf_release)(struct videobuf_queue *q,
+   struct videobuf_buffer *vb);
+};
+
+buf_setup() is called early in the I/O process, when streaming is being
+initiated; its purpose is to tell videobuf about the I/O stream.  The count
+parameter will be a suggested number of buffers to use; the driver should
+check it for rationality and adjust it if need be.  As a practical rule, a
+minimum of two buffers are needed for proper streaming, and there is
+usually a maximum (which cannot exceed 32) which makes sense for each
+device.  The size parameter should be set to the expected (maximum) size
+for each frame of data.
+
+Each buffer (in the form of a struct videobuf_buffer pointer) will be
+passed to buf_prepare(), which should set the buffer's size, width, height,
+and field fields properly.  If the buffer's state field is
+VIDEOBUF_NEEDS_INIT, the driver should pass it to:
+
+int videobuf_iolock(struct videobuf_queue* q, struct videobuf_buffer *vb,
+   struct v4l2_framebuffer *fbuf);
+
+Among other things, this call will usually allocate memory for the buffer.
+Finally, the buf_setup() function should set the 

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

2009-12-03 Thread Mauro Carvalho Chehab
Let me draw my view:

Em Thu, 3 Dec 2009 09:55:31 -0800
Dmitry Torokhov dmitry.torok...@gmail.com escreveu:

 No, please, wait just a minute. I know it is tempting to just merge
 lirc_dev and start working, but can we first agree on the overall
 subsystem structure before doing so. It is still quite inclear to me.
 
 The open questions (for me at least):
 
 - do we create a new class infrastructure for all receivers or only for
   ones plugged into lirc_dev? Remember that classifying objects affects
   how udev and friemds see them and may either help or hurt writing PnP
   rules.

IMO, I would create it as /sys/class/input/IR (just like the /mice). I
don't see why do we need to different lirc than no-lirc drivers in the
case of sysfs class. As devices with raw input capabilities will have
another dev to communicate, this means that we'll need a /lirc node
there to point to lirc dev.

 
 - do we intend to support in-kernel sotfware decoders?

Yes.

 - What is the structure? Do we organize them as a module to be used by driver
   directly or the driver streams the data to IR core and the core
   applies decoders (in the same fashion input events from drivers flow
   into input core and then distributed to all bound interfaces for
   processing/conversion/transmission to userspace)?

My plan is to expand ir-common.ko module and rename it to ir-core, to be 
the IR core module for the evdev interface. I'm already working on it. 
My idea for an architecture is that the lirc-core module will use 
ir-common where the IR decoders will be, and the evdev interface.

IMO, we should move them from /drivers/media/common to /drivers/input/ir.
It makes sense to use kfifo to send the data to the in-kernel decoders.

 - how do we control which decoder should handle particular
   receiver/remote? Is it driver's decision, decoder's decision, user's
   or all of the above?

It should be all the above, since some hardware will only work with certain
decoders (hardware limitation) or they may have already a raw mode-scancode
legacy decoder. In the latter case, those decoders will be removed from
the existing drivers, but this action will take some time.

Some sysfs attributes are needed to specify a list of the supported protocols
and the currently used one. I'll prepare a proposed patch for it, after we
finish aligning the requirements.
 
 - do we allow to have several decorers active at once for a receiver?

Yes, as an optional requirement, since some hardware won't support it.

 - who decides that we want to utilize lirc_dev? Driver's themselves, IR
   core (looking at the driver/device capabilities), something else?

Drivers that support raw mode, should interface via lirc-core, that will,
in turn use ir-core.

Drivers that have in-hardware decode will directly use ir-core.

 - do we recognize and create input devices on-fly or require user
   intervention? Semantics for splitting into several input/event
   devices?

I don't have a strong opinion here. 

I don't see any way for doing it, except with very few protocols that
sends vendor IDs. I don't care if this feature can be used by the
drivers/decoders that could support it.

 Could anyone please draw me a picture, starting with a receiver
 piece of hardware. I am not concerned much with how exactly receiver is
 plugged into a particular subsystem (DVB/V4L etc) since it would be
 _their_ implementation detail, but with the flow in/out of that
 receiver device.

Not sure if I got your idea. Basically, what I see is:

For device drivers that work in raw mode:
[IR physical device] == [IR receiver driver]  == [lirc-core] == [decoder] 
== [ir-core] == [evdev]

(eventually, we can merge decoder and ir-core into one module at the beginning,
depending on the size of the decoders)

For device drivers that work only in evdev mode (those with hardware 
decoders):

[IR physical device] == [IR receiver driver]  == [ir-core] == [evdev]

 
 Now as far as input core goes I see very limited number of changes that
 may be needed:
 
 - Allow to extend size of scancode in EVIOC{S,G}KEYCODE if we are
   unable to limit ourselves to 32 bits (keeping compatibility of course)

Yes, but the way EVIOC{S,G}KEYCODE currently works, it performs poorly when you 
have a
table with 2^64 size. The table is very sparsed, but, as the key to get/set a 
code is
the scancode, it is very hard to enumberate what are the actual entries there. 
The
better is to use an index parameter for they, instead of using the scancode as 
such.

 - Maybe adding new ioctl to zap the keymap table

Yes, this is needed.

 - Adding more key EV_KEY/KEY_* definitons, if needed

Probably.

-- 

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

2009-12-03 Thread Jon Smirl
On Thu, Dec 3, 2009 at 12:55 PM, Dmitry Torokhov
dmitry.torok...@gmail.com wrote:
 On Thu, Dec 03, 2009 at 01:09:14PM +0100, Gerd Hoffmann wrote:
 On 12/03/09 05:29, Jarod Wilson wrote:
 On Dec 1, 2009, at 10:28 AM, Gerd Hoffmann wrote:

 Anyway, we shouldn't postpone lirc drivers addition due to that.
 There are still lots of work to do before we'll be able to split
 the tables from the kernel drivers.

 Indeed.  The sysfs bits are future work for both lirc and evdev
 drivers.  There is no reason to make the lirc merge wait for it.

 At this point, my plan is to try to finish cleaning up lirc_dev and
 lirc_mceusb at least over the weekend while at FUDCon up in Toronto,
 and resubmit them next week.

 Good plan IMHO.  Having lirc_dev merged quickly allows in-kernel drivers
 start supporting lirc.

 No, please, wait just a minute. I know it is tempting to just merge
 lirc_dev and start working, but can we first agree on the overall
 subsystem structure before doing so. It is still quite inclear to me.

 The open questions (for me at least):

Great list, good starting point for evaluating the design alternatives.

Have the various use cases all been enumerated?

 - do we create a new class infrastructure for all receivers or only for
  ones plugged into lirc_dev? Remember that classifying objects affects
  how udev and friemds see them and may either help or hurt writing PnP
  rules.

 - do we intend to support in-kernel sotfware decoders? What is the
  structure? Do we organize them as a module to be used by driver
  directly or the driver streams the data to IR core and the core
  applies decoders (in the same fashion input events from drivers flow
  into input core and then distributed to all bound interfaces for
  processing/conversion/transmission to userspace)?

 - how do we control which decoder should handle particular
  receiver/remote? Is it driver's decision, decoder's decision, user's
  or all of the above?

 - do we allow to have several decoders active at once for a receiver?

 - who decides that we want to utilize lirc_dev? Driver's themselves, IR
  core (looking at the driver/device capabilities), something else?

Is the lirc device protocol documented? The lirc device only allows a
single app to read from it, it that ok? What about the problem the
mouse driver had with reading partial messages in one read and by the
time you came back around to read the second half the first read was
overwritten? That led to the transactions in evdev.


 - do we recognize and create input devices on-fly or require user
  intervention? Semantics for splitting into several input/event
  devices?

Complete on-the-fly is not going to do what you want it to. For
example Sony TVs use three variations of the Sony protocol in a single
TV.

A slick solution would have unknown IR events trigger a mapping
definition app via udev. The mapping app would ask you to hit a few
more keys until it locates the corresponding device profile in the IR
database. Then it could write a script which will load create a new
evdev device for this device and load the keycode map for it at boot.

The big IR profile database from All-In-One is published. For this
application you'd need to add entries mapping each IR code to a Linux
keycode. This is the same problem you have with scancodes and various
languages on keyboards. I'll bet the guys at http://www.openremote.org
would help with this.


 Could anyone please draw me a picture, starting with a receiver
 piece of hardware. I am not concerned much with how exactly receiver is
 plugged into a particular subsystem (DVB/V4L etc) since it would be
 _their_ implementation detail, but with the flow in/out of that
 receiver device.

 Now as far as input core goes I see very limited number of changes that
 may be needed:

 - Allow to extend size of scancode in EVIOC{S,G}KEYCODE if we are
  unable to limit ourselves to 32 bits (keeping compatibility of course)

 - Maybe adding new ioctl to zap the keymap table

 - Adding more key EV_KEY/KEY_* definitons, if needed

Aren't EV_IR events needed so that an app for building keymaps can be written?
Normal apps would not use EV_IR events.

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


V4L1 compatibility broken for VIDIOCGTUNER with radio

2009-12-03 Thread Herton Ronaldo Krzesinski
Hi,

After commit 9bedc7f (V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM 
default handlers), radio software using V4L1 stopped to work on a saa7134 
card, a git bisect pointed to this commit introducing the regression. All 
VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this 
commit.

Investigating the issue, it turns out that v4l1_compat_get_tuner calls 
VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is 
returning -EINVAL to user space applications which are being confused about 
this.

May be VIDIOC_G_STD change in the commit above should be reverted, or 
v4l1_compat_get_tuner changed to not return error with G_STD, or not call 
G_STD ioctl for a radio device?

--
[]'s
Herton
--
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] Document the videobuf layer

2009-12-03 Thread Mauro Carvalho Chehab
Jonathan Corbet wrote:
 I've taken the liberty of dropping this into my docs-next tree, and
 will send it upward unless there are objections.  Hopefully it's
 useful...

Hi Jon,

Thanks for the doc!

I'll take a more detailed review, but I've added already some bits about
videobuf at:

Documentation/video4linux/v4l2-framework.txt

Your documentation seems more complete on a very quick view, but it also
seemed to have some duplicated info.

Cheers,
Mauro

 
 jon
 ---
 V4L2: Add a document describing the videobuf layer
 
 Videobuf is a moderately complex API which most V4L2 drivers should use,
 but its documentation is...sparse.  This document attempts to improve the
 situation.
 
 Signed-off-by: Jonathan Corbet cor...@lwn.net
 
 diff --git a/Documentation/video4linux/videobuf 
 b/Documentation/video4linux/videobuf
 new file mode 100644
 index 000..4e21ea7
 --- /dev/null
 +++ b/Documentation/video4linux/videobuf
 @@ -0,0 +1,341 @@
 +An introduction to the videobuf layer
 +Jonathan Corbet cor...@lwn.net
 +Current as of 2.6.32
 +
 +The videobuf layer functions as a sort of glue layer between a V4L2 driver
 +and user space.  It handles the allocation and management of buffers for
 +the storage of video frames.  There is a set of functions which can be used
 +to implement many of the standard POSIX I/O system calls, including read(),
 +poll(), and, happily, mmap().  Another set of functions can be used to
 +implement the bulk of the V4L2 ioctl() calls related to streaming I/O,
 +including buffer allocation, queueing and dequeueing, and streaming
 +control.  Using videobuf imposes a few design decisions on the driver
 +author, but the payback comes in the form of reduced code in the driver and
 +a consistent implementation of the V4L2 user-space API.
 +
 +Buffer types
 +
 +Not all video devices use the same kind of buffers.  In fact, there are (at
 +least) three common variations:
 +
 + - Buffers which are scattered in both the physical and (kernel) virtual
 +   address spaces.  All user-space buffers are like this, but it makes
 +   great sense to allocate kernel-space buffers this way as well when it is
 +   possible.  Unfortunately, it is not always possible; working with this
 +   kind of buffer normally requires hardware which can do scatter/gather
 +   DMA operations.
 +
 + - Buffers which are physically scattered, but which are virtually
 +   contiguous; buffers allocated with vmalloc(), in other words.  These
 +   buffers are just as hard to use for DMA operations, but they can be
 +   useful in situations where DMA is not available but virtually-contiguous
 +   buffers are convenient.
 +
 + - Buffers which are physically contiguous.  Allocation of this kind of
 +   buffer can be unreliable on fragmented systems, but simpler DMA
 +   controllers cannot deal with anything else.
 +
 +Videobuf can work with all three types of buffers, but the driver author
 +must pick one at the outset and design the driver around that decision.
 +
 +Data structures, callbacks, and initialization
 +
 +Depending on which type of buffers are being used, the driver should
 +include one of the following files:
 +
 +media/videobuf-dma-sg.h/* Physically scattered */
 +media/videobuf-vmalloc.h   /* vmalloc() buffers*/
 +media/videobuf-dma-contig.h/* Physically contiguous */
 +
 +The driver's data structure describing a V4L2 device should include a
 +struct videobuf_queue instance for the management of the buffer queue,
 +along with a list_head for the queue of available buffers.  There will also
 +need to be an interrupt-safe spinlock which is used to protect (at least)
 +the queue.
 +
 +The next step is to write four simple callbacks to help videobuf deal with
 +the management of buffers:
 +
 +struct videobuf_queue_ops {
 + int (*buf_setup)(struct videobuf_queue *q,
 +  unsigned int *count, unsigned int *size);
 + int (*buf_prepare)(struct videobuf_queue *q,
 +struct videobuf_buffer *vb,
 +enum v4l2_field field);
 + void (*buf_queue)(struct videobuf_queue *q,
 +   struct videobuf_buffer *vb);
 + void (*buf_release)(struct videobuf_queue *q,
 + struct videobuf_buffer *vb);
 +};
 +
 +buf_setup() is called early in the I/O process, when streaming is being
 +initiated; its purpose is to tell videobuf about the I/O stream.  The count
 +parameter will be a suggested number of buffers to use; the driver should
 +check it for rationality and adjust it if need be.  As a practical rule, a
 +minimum of two buffers are needed for proper streaming, and there is
 +usually a maximum (which cannot exceed 32) which makes sense for each
 +device.  The size parameter should be set to the expected (maximum) size
 +for each frame of data.
 +
 +Each buffer (in the form of a struct videobuf_buffer pointer) will be
 +passed to buf_prepare(), which should set the 

RE: [PATCH 2/2] DaVinci - vpfe capture - converting ccdc to platform driver

2009-12-03 Thread Karicheri, Muralidharan

 -/*
 - * setup Mux configuration for vpfe input and register
 - * vpfe capture platform device
 - */
 -davinci_cfg_reg(DM355_VIN_PCLK);
 -davinci_cfg_reg(DM355_VIN_CAM_WEN);
 -davinci_cfg_reg(DM355_VIN_CAM_VD);
 -davinci_cfg_reg(DM355_VIN_CAM_HD);
 -davinci_cfg_reg(DM355_VIN_YIN_EN);
 -davinci_cfg_reg(DM355_VIN_CINL_EN);
 -davinci_cfg_reg(DM355_VIN_CINH_EN);
[Hiremath, Vaibhav] Why have you removed mux configuration from here and
moved to CCDC driver? Any specific reason?

Good catch. I wanted to do this clean up, but missed it. Actually platform data 
should have a function setup_pinmux() to set up the pin mux for the
ccdc input. This function will be defined in the platform file and will be
called during probe()

Murali
 +platform_device_register(dm355_ccdc_dev);
  platform_device_register(vpfe_capture_dev);

  return 0;
 diff --git a/arch/arm/mach-davinci/dm644x.c b/arch/arm/mach-
 davinci/dm644x.c
 index 2cd0081..982be1f 100644
 --- a/arch/arm/mach-davinci/dm644x.c
 +++ b/arch/arm/mach-davinci/dm644x.c
 @@ -612,6 +612,11 @@ static struct resource vpfe_resources[] = {
  .end= IRQ_VDINT1,
  .flags  = IORESOURCE_IRQ,
  },
 +};
 +
 +static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct resource dm644x_ccdc_resource[] = {
 +/* CCDC Base address */
  {
  .start  = 0x01c70400,
  .end= 0x01c70400 + 0xff,
 @@ -619,7 +624,17 @@ static struct resource vpfe_resources[] = {
  },
  };

 -static u64 vpfe_capture_dma_mask = DMA_BIT_MASK(32);
 +static struct platform_device dm644x_ccdc_dev = {
 +.name   = dm644x_ccdc,
 +.id = -1,
 +.num_resources  = ARRAY_SIZE(dm644x_ccdc_resource),
 +.resource   = dm644x_ccdc_resource,
 +.dev = {
 +.dma_mask   = vpfe_capture_dma_mask,
 +.coherent_dma_mask  = DMA_BIT_MASK(32),
 +},
 +};
 +
  static struct platform_device vpfe_capture_dev = {
  .name   = CAPTURE_DRV_NAME,
  .id = -1,
 @@ -772,6 +787,7 @@ static int __init dm644x_init_devices(void)
  platform_device_register(dm644x_edma_device);
  platform_device_register(dm644x_emac_device);
  platform_device_register(dm644x_vpss_device);
 +platform_device_register(dm644x_ccdc_dev);
  platform_device_register(vpfe_capture_dev);

  return 0;
 --
 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: [RFC v2] Another approach to IR

2009-12-03 Thread alhaz

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


Now I understand that if 2 remotes send completely identical signals we
won't be able to separate them, but in cases when we can I think we
should.


I don't have a problem with that, if its a truly desired feature.   
But for the most part, I don't see the point. Generally, you go   
from having multiple remotes, one per device (where device is   
your TV, amplifier, set top box, htpc, etc), to having a single   
universal remote that controls all of those devices. But for each   
device (IR receiver), *one* IR command set. The desire to use   
multiple distinct remotes with a single IR receiver doesn't make   
sense to me. Perhaps I'm just not creative enough in my use of IR. :)


From a hobbiest's perspective there's likely rarely any reason to be  
able to do the same thing with two different remotes that send  
different signals, but i could see it come up - For example if you  
wanted to have both a feature-rich,  busy/complicated remote but also  
wanted to provide a simpler remote with a relatively small number of  
large buttons on it for basic functions, as for children or people  
with poor eyesight or poor motor control.


From a business perspective, I've worked for a company that sold  
turn-key video training systems, and depending on the whims of our  
so-called business partners and the desires of customers, there were  
as many as three distinct remotes that might get shipped with the  
training system, and they all sent different signals.


That was a less than ideal situation, and if we had been really on top  
of things we'd have just declined to use any of those remotes and  
bought custom remotes from any of the numerous vendors that sell them  
which would allow us to have one set of IR signals used by remotes  
with different features - but for whatever reason that wasn't how  
management decided to do things.

--
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: WARNINGS, 2.6.16-2.6.21: WARNINGS

2009-12-03 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:Thu Dec  3 19:00:03 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13538:e0cd9a337600
gcc version: gcc (GCC) 4.3.1
hardware:x86_64
host os: 2.6.26

linux-2.6.30-armv5: OK
linux-2.6.31-armv5: OK
linux-2.6.32-rc8-armv5: OK
linux-2.6.32-rc8-armv5-davinci: OK
linux-2.6.30-armv5-ixp: OK
linux-2.6.31-armv5-ixp: OK
linux-2.6.32-rc8-armv5-ixp: OK
linux-2.6.30-armv5-omap2: OK
linux-2.6.31-armv5-omap2: OK
linux-2.6.32-rc8-armv5-omap2: OK
linux-2.6.22.19-i686: OK
linux-2.6.23.12-i686: OK
linux-2.6.24.7-i686: OK
linux-2.6.25.11-i686: OK
linux-2.6.26-i686: OK
linux-2.6.27-i686: OK
linux-2.6.28-i686: OK
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: OK
linux-2.6.31-i686: OK
linux-2.6.32-rc8-i686: OK
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-rc8-m32r: OK
linux-2.6.30-mips: OK
linux-2.6.31-mips: OK
linux-2.6.32-rc8-mips: OK
linux-2.6.30-powerpc64: OK
linux-2.6.31-powerpc64: OK
linux-2.6.32-rc8-powerpc64: OK
linux-2.6.22.19-x86_64: OK
linux-2.6.23.12-x86_64: OK
linux-2.6.24.7-x86_64: OK
linux-2.6.25.11-x86_64: OK
linux-2.6.26-x86_64: OK
linux-2.6.27-x86_64: OK
linux-2.6.28-x86_64: OK
linux-2.6.29.1-x86_64: WARNINGS
linux-2.6.30-x86_64: OK
linux-2.6.31-x86_64: OK
linux-2.6.32-rc8-x86_64: OK
spec: OK
sparse (linux-2.6.31): ERRORS
sparse (linux-2.6.32-rc8): ERRORS
linux-2.6.16.61-i686: WARNINGS
linux-2.6.17.14-i686: WARNINGS
linux-2.6.18.8-i686: WARNINGS
linux-2.6.19.5-i686: WARNINGS
linux-2.6.20.21-i686: WARNINGS
linux-2.6.21.7-i686: WARNINGS
linux-2.6.16.61-x86_64: WARNINGS
linux-2.6.17.14-x86_64: WARNINGS
linux-2.6.18.8-x86_64: WARNINGS
linux-2.6.19.5-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/Thursday.log

Full logs are available here:

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


RE: [PATCH v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers

2009-12-03 Thread Karicheri, Muralidharan

 +#include mach/mux.h
[Hiremath, Vaibhav] This should not be here, this should get handled in
board file. The driver should be generic.

See my comments against the platform part of this patch.

  #include media/davinci/dm355_ccdc.h
  #include media/davinci/vpss.h
  #include dm355_ccdc_regs.h
 @@ -105,7 +106,6 @@ static struct ccdc_params_ycbcr
 ccdc_hw_params_ycbcr = {

  static enum vpfe_hw_if_type ccdc_if_type;
  static void *__iomem ccdc_base_addr;
 -static int ccdc_addr_size;

  /* Raw Bayer formats */
  static u32 ccdc_raw_bayer_pix_formats[] =
 @@ -126,12 +126,6 @@ static inline void regw(u32 val, u32 offset)
  __raw_writel(val, ccdc_base_addr + offset);
  }

 -static void ccdc_set_ccdc_base(void *addr, int size)
 -{
 -ccdc_base_addr = addr;
 -ccdc_addr_size = size;
 -}
 -
  static void ccdc_enable(int en)
  {
  unsigned int temp;
 @@ -938,7 +932,6 @@ static struct ccdc_hw_device ccdc_hw_dev = {
  .hw_ops = {
  .open = ccdc_open,
  .close = ccdc_close,
 -.set_ccdc_base = ccdc_set_ccdc_base,
  .enable = ccdc_enable,
  .enable_out_to_sdram = ccdc_enable_output_to_sdram,
  .set_hw_if_params = ccdc_set_hw_if_params,
 @@ -959,19 +952,89 @@ static struct ccdc_hw_device ccdc_hw_dev = {
  },
  };

 -static int __init dm355_ccdc_init(void)
 +static int __init dm355_ccdc_probe(struct platform_device *pdev)
  {
 -printk(KERN_NOTICE dm355_ccdc_init\n);
 -if (vpfe_register_ccdc_device(ccdc_hw_dev)  0)
 -return -1;
 +static resource_size_t  res_len;
 +struct resource *res;
 +int status = 0;
 +
 +/**
 + * first try to register with vpfe. If not correct platform,
 then we
 + * don't have to iomap
 + */
 +status = vpfe_register_ccdc_device(ccdc_hw_dev);
 +if (status  0)
 +return status;
 +
 +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +if (!res) {
 +status = -ENOENT;
[Hiremath, Vaibhav] I think right return value is -ENODEV.

Right. I will change it.

 +goto fail_nores;
 +}
 +res_len = res-end - res-start + 1;
 +
 +res = request_mem_region(res-start, res_len, res-name);
[Hiremath, Vaibhav] You should use resource_size here for res_len here.
Ok. I didn't know about such a function :(

Will change res_len - resource_size(res)


 +if (!res) {
 +status = -EBUSY;
 +goto fail_nores;
 +}
 +
 +ccdc_base_addr = ioremap_nocache(res-start, res_len);
 +if (!ccdc_base_addr) {
 +status = -EBUSY;
[Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be -
ENXIO or -ENOMEM.

I see -ENXIO  -ENOMEM being used by drivers. -ENXIO stands for No such device 
or address. ENOMEM stands for Out of memory . Since we are trying to map the 
address here, -ENXIO looks reasonable to me. Same if request_mem_region() fails.
 
 +goto fail;
 +}
 +/**
 + * setup Mux configuration for vpfe input and register
 + * vpfe capture platform device
 + */
 +davinci_cfg_reg(DM355_VIN_PCLK);
 +davinci_cfg_reg(DM355_VIN_CAM_WEN);
 +davinci_cfg_reg(DM355_VIN_CAM_VD);
 +davinci_cfg_reg(DM355_VIN_CAM_HD);
 +davinci_cfg_reg(DM355_VIN_YIN_EN);
 +davinci_cfg_reg(DM355_VIN_CINL_EN);
 +davinci_cfg_reg(DM355_VIN_CINH_EN);
 +
[Hiremath, Vaibhav] This should not be here, this code must be generic and
might get used in another SoC.
yes. See my suggestion against the architecture part. will be replaced
with a setup_pinmux() fuction from platform_data. 

  printk(KERN_NOTICE %s is registered with vpfe.\n,
  ccdc_hw_dev.name);
  return 0;
 +fail:
 +release_mem_region(res-start, res_len);
 +fail_nores:
 +vpfe_unregister_ccdc_device(ccdc_hw_dev);
 +return status;
  }

 -static void __exit dm355_ccdc_exit(void)
 +static int dm355_ccdc_remove(struct platform_device *pdev)
  {
 +struct resource *res;
 +
 +iounmap(ccdc_base_addr);
 +res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
 +if (res)
 +release_mem_region(res-start, res-end - res-start +
 1);
[Hiremath, Vaibhav] Please use resource_size here for size.
Ok.

  vpfe_unregister_ccdc_device(ccdc_hw_dev);
 +return 0;
 +}
 +
 +static struct platform_driver dm355_ccdc_driver = {
 +.driver = {
 +.name   = dm355_ccdc,
 +.owner = THIS_MODULE,
 +},
 +.remove = __devexit_p(dm355_ccdc_remove),
 +.probe = dm355_ccdc_probe,
 +};
 +
 +static int __init dm355_ccdc_init(void)
 +{
 +return platform_driver_register(dm355_ccdc_driver);
 +}
 +
 +static void __exit dm355_ccdc_exit(void)
 +{
 +platform_driver_unregister(dm355_ccdc_driver);
  }

  module_init(dm355_ccdc_init);
 diff --git a/drivers/media/video/davinci/dm644x_ccdc.c
 b/drivers/media/video/davinci/dm644x_ccdc.c
 index d5fa193..89ea6ae 100644
 --- a/drivers/media/video/davinci/dm644x_ccdc.c
 +++ 

[PATCH -v2] Adding helper function to get dv preset description

2009-12-03 Thread m-karicheri2
From: Muralidharan Karicheri m-kariche...@ti.com

Updated based on comments against v1 of the patch

This patch adds a helper function to get description of a digital
video preset added by the video timing API. This will be usefull for drivers
implementing the above API.

NOTE: depends on the patch that adds video timing API.

Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
Reviewed-by: Hans Verkuil hverk...@xs4all.nl
---
Applies to V4L-DVB linux-next branch
 drivers/media/video/v4l2-common.c |   47 +
 include/media/v4l2-common.h   |2 +-
 2 files changed, 48 insertions(+), 1 deletions(-)

diff --git a/drivers/media/video/v4l2-common.c 
b/drivers/media/video/v4l2-common.c
index e8e5aff..36b5cb8 100644
--- a/drivers/media/video/v4l2-common.c
+++ b/drivers/media/video/v4l2-common.c
@@ -1024,3 +1024,50 @@ void v4l_bound_align_image(u32 *w, unsigned int wmin, 
unsigned int wmax,
}
 }
 EXPORT_SYMBOL_GPL(v4l_bound_align_image);
+
+/**
+ * v4l_fill_dv_preset_info - fill description of a digital video preset
+ * @preset - preset value
+ * @info - pointer to struct v4l2_dv_enum_preset
+ *
+ * drivers can use this helper function to fill description of dv preset
+ * in info.
+ */
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset *info)
+{
+   static const struct v4l2_dv_preset_info {
+   u16 width;
+   u16 height;
+   const char *name;
+   } dv_presets[] = {
+   { 0, 0, Invalid },/* V4L2_DV_INVALID */
+   { 720,  480, 4...@59.94 },/* V4L2_DV_480P59_94 */
+   { 720,  576, 5...@50 },   /* V4L2_DV_576P50 */
+   { 1280, 720, 7...@24 },   /* V4L2_DV_720P24 */
+   { 1280, 720, 7...@25 },   /* V4L2_DV_720P25 */
+   { 1280, 720, 7...@30 },   /* V4L2_DV_720P30 */
+   { 1280, 720, 7...@50 },   /* V4L2_DV_720P50 */
+   { 1280, 720, 7...@59.94 },/* V4L2_DV_720P59_94 */
+   { 1280, 720, 7...@60 },   /* V4L2_DV_720P60 */
+   { 1920, 1080, 10...@29.97 },  /* V4L2_DV_1080I29_97 */
+   { 1920, 1080, 10...@30 }, /* V4L2_DV_1080I30 */
+   { 1920, 1080, 10...@25 }, /* V4L2_DV_1080I25 */
+   { 1920, 1080, 10...@50 }, /* V4L2_DV_1080I50 */
+   { 1920, 1080, 10...@60 }, /* V4L2_DV_1080I60 */
+   { 1920, 1080, 10...@24 }, /* V4L2_DV_1080P24 */
+   { 1920, 1080, 10...@25 }, /* V4L2_DV_1080P25 */
+   { 1920, 1080, 10...@30 }, /* V4L2_DV_1080P30 */
+   { 1920, 1080, 10...@50 }, /* V4L2_DV_1080P50 */
+   { 1920, 1080, 10...@60 }, /* V4L2_DV_1080P60 */
+   };
+
+   if (info == NULL || preset = ARRAY_SIZE(dv_presets))
+   return -EINVAL;
+
+   info-preset = preset;
+   info-width = dv_presets[preset].width;
+   info-height = dv_presets[preset].height;
+   strlcpy(info-name, dv_presets[preset].name, sizeof(info-name));
+   return 0;
+}
+EXPORT_SYMBOL_GPL(v4l_fill_dv_preset_info);
diff --git a/include/media/v4l2-common.h b/include/media/v4l2-common.h
index 1c25b10..1c7b259 100644
--- a/include/media/v4l2-common.h
+++ b/include/media/v4l2-common.h
@@ -212,5 +212,5 @@ void v4l_bound_align_image(unsigned int *w, unsigned int 
wmin,
   unsigned int *h, unsigned int hmin,
   unsigned int hmax, unsigned int halign,
   unsigned int salign);
-
+int v4l_fill_dv_preset_info(u32 preset, struct v4l2_dv_enum_preset *info);
 #endif /* V4L2_COMMON_H_ */
-- 
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: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable

2009-12-03 Thread Karicheri, Muralidharan
Hans,

Please hold on to this. I will send you an updated patch.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 12:22 PM
To: 'Hans Verkuil'
Cc: Hiremath, Vaibhav; linux-media@vger.kernel.org
Subject: FW: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable

Hans,

Could you please add this to your hg tree and send a pull
request to Mauro? This was reviewed by Vaibhav and tested on
DM355, DM6446, AM3517  DM365. I will request Kevin to pull
the Architecture part of this patch.

Thanks.

Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
phone: 301-407-9583
email: m-kariche...@ti.com

-Original Message-
From: Karicheri, Muralidharan
Sent: Tuesday, December 01, 2009 12:19 PM
To: linux-media@vger.kernel.org; hverk...@xs4all.nl;
khil...@deeprootsystems.com
Cc: davinci-linux-open-sou...@linux.davincidsp.com; Hiremath, Vaibhav;
Karicheri, Muralidharan
Subject: [PATCH - v1 1/2] V4L - vpfe capture - make clocks configurable

From: Muralidharan Karicheri m-kariche...@ti.com

v1  - updated based on comments from Vaibhav Hiremath.

On DM365 we use only vpss master clock, where as on DM355 and
DM6446, we use vpss master and slave clocks for vpfe capture and AM3517
we use internal clock and pixel clock. So this patch makes it configurable
on a per platform basis. This is needed for supporting DM365 for which
patches
will be available soon.

Tested-by: Vaibhav Hiremath hvaib...@ti.com, Muralidharan Karicheri m-
kariche...@ti.com
Acked-by: Vaibhav Hiremath hvaib...@ti.com
Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
---
 drivers/media/video/davinci/vpfe_capture.c |   98 +--
-
---
 include/media/davinci/vpfe_capture.h   |   11 ++-
 2 files changed, 70 insertions(+), 39 deletions(-)

diff --git a/drivers/media/video/davinci/vpfe_capture.c
b/drivers/media/video/davinci/vpfe_capture.c
index 12a1b3d..c3468ee 100644
--- a/drivers/media/video/davinci/vpfe_capture.c
+++ b/drivers/media/video/davinci/vpfe_capture.c
@@ -1787,61 +1787,87 @@ static struct vpfe_device *vpfe_initialize(void)
  return vpfe_dev;
 }

+/**
+ * vpfe_disable_clock() - Disable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Disables clocks defined in vpfe configuration.
+ */
 static void vpfe_disable_clock(struct vpfe_device *vpfe_dev)
 {
  struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
+ int i;

- clk_disable(vpfe_cfg-vpssclk);
- clk_put(vpfe_cfg-vpssclk);
- clk_disable(vpfe_cfg-slaveclk);
- clk_put(vpfe_cfg-slaveclk);
- v4l2_info(vpfe_dev-pdev-driver,
-  vpfe vpss master  slave clocks disabled\n);
+ for (i = 0; i  vpfe_cfg-num_clocks; i++) {
+ clk_disable(vpfe_dev-clks[i]);
+ clk_put(vpfe_dev-clks[i]);
+ }
+ kfree(vpfe_dev-clks);
+ v4l2_info(vpfe_dev-pdev-driver, vpfe capture clocks disabled\n);
 }

+/**
+ * vpfe_enable_clock() - Enable clocks for vpfe capture driver
+ * @vpfe_dev - ptr to vpfe capture device
+ *
+ * Enables clocks defined in vpfe configuration. The function
+ * assumes that at least one clock is to be defined which is
+ * true as of now. re-visit this if this assumption is not true
+ */
 static int vpfe_enable_clock(struct vpfe_device *vpfe_dev)
 {
  struct vpfe_config *vpfe_cfg = vpfe_dev-cfg;
- int ret = -ENOENT;
+ int i;

- vpfe_cfg-vpssclk = clk_get(vpfe_dev-pdev, vpss_master);
- if (NULL == vpfe_cfg-vpssclk) {
- v4l2_err(vpfe_dev-pdev-driver, No clock defined for
-  vpss_master\n);
- return ret;
- }
+ if (!vpfe_cfg-num_clocks)
+ return 0;

- if (clk_enable(vpfe_cfg-vpssclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
- vpfe vpss master clock not enabled\n);
- goto out;
- }
- v4l2_info(vpfe_dev-pdev-driver,
-  vpfe vpss master clock enabled\n);
+ vpfe_dev-clks = kzalloc(vpfe_cfg-num_clocks *
+sizeof(struct clock *), GFP_KERNEL);

- vpfe_cfg-slaveclk = clk_get(vpfe_dev-pdev, vpss_slave);
- if (NULL == vpfe_cfg-slaveclk) {
- v4l2_err(vpfe_dev-pdev-driver,
- No clock defined for vpss slave\n);
- goto out;
+ if (NULL == vpfe_dev-clks) {
+ v4l2_err(vpfe_dev-pdev-driver, Memory allocation failed\n);
+ return -ENOMEM;
  }

- if (clk_enable(vpfe_cfg-slaveclk)) {
- v4l2_err(vpfe_dev-pdev-driver,
-  vpfe vpss slave clock not enabled\n);
- goto out;
+ for (i = 0; i  vpfe_cfg-num_clocks; i++) {
+ if (NULL == vpfe_cfg-clocks[i]) {
+ v4l2_err(vpfe_dev-pdev-driver,
+ clock %s is not defined in vpfe 

How to help with RTL2832U based TV?

2009-12-03 Thread Peter Rasmussen

I looked around in the archives of:

http://dir.gmane.org/gmane.linux.drivers.video-input-infrastructure
http://www.spinics.net/lists/linux-media/

as mentioned in the welcome email of this list, but it isn't apparent to me 
what the status in Linux of using a device based on this chip is?


When inserting the USB dongle I get the following:

Dec  3 20:56:22 kultorvet kernel: usb 1-1: new high speed USB device 
using ehci_hcd and address 5
Dec  3 20:56:22 kultorvet kernel: usb 1-1: New USB device found, 
idVendor=1d19, idProduct=1102
Dec  3 20:56:22 kultorvet kernel: usb 1-1: New USB device strings: 
Mfr=1, Product=2, SerialNumber=3

Dec  3 20:56:22 kultorvet kernel: usb 1-1: Product: Rtl2832UDVB
Dec  3 20:56:22 kultorvet kernel: usb 1-1: Manufacturer: Realtek
Dec  3 20:56:22 kultorvet kernel: usb 1-1: SerialNumber: 1
Dec  3 20:56:22 kultorvet kernel: usb 1-1: configuration #1 chosen from 
1 choice


In Windows Vista it runs fine, showing TV using both MPEG2 and MPEG4 
encoded signals, but I would much rather run it with Linux.


I am also developing software for a living, but not this close to 
hardware, however I would like to help out the way I can.


Thanks,
Peter
--
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 v2] Another approach to IR

2009-12-03 Thread Mauro Carvalho Chehab
Krzysztof Halasa wrote:
 Mauro Carvalho Chehab mche...@redhat.com writes:
 
 Btw, looking at that code, while it is not impossible to split the 
 IR pulse/space measures from the NEC decoder itself, and make it generic
 to support other protocols, it is not a trivial task, and may result on
 a less stable driver.
 
 And it's not needed at all.
 Protocol decoders can be easily run in parallel, I've done it on saa713x
 and this is trivial at least there. Can do that when the lirc interface
 is available.

 The advantage of the NEC decoding approach on saa7134 is that you know for
 sure how much time it is required to get the entire code. So, the code 
 can easily abort the reception of a bad code. The disadvantage is that 
 only one protocol can be decoded at the same time.
 
 This isn't a hard thing to fix.

Good to know. We're open to patches to improve it. 

The point is that we've got in the past several complains about saa713x
machines hanging due to IRQ's generated by IR sensor port. We ended by adding
an option to disable IR and a code at the driver that disables IR IRQ if it 
happens too often.

 
 The same problem also happens with almost all in-kernel drivers: the decoders
 for raw mode were constructed to work with just one pulse/space code at the
 same time. A conversion into a generic code can happen, but it will require
 several tests to be sure that they won't cause undesirable side-effects.
 
 IOW any such receiver has to be tested, sure.
 
 The advantage of hardware decoders is that you don't need to be polling the
 IR serial port at a high rate, as you'll get directly the code. So, you'll
 free the CPU to do something else.
 
 Which device requires polling the port?
 Most are IRQ-driven, aren't they?

Most of the devices that have a hardware IR decodes needs polling. Most of they
simply outputs the scan code on some set of GPIO pins.

In general, the devices with the IR sensor connected to a GPIO pin are 
IRQ-driven.

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: [Bugme-new] [Bug 14564] New: capture-example sleeping function called from invalid context at arch/x86/mm/fault.c

2009-12-03 Thread Alan Stern
On Wed, 2 Dec 2009, Sean wrote:

 Is there anything I can do to help? This is a show stopping bug for me.

Here's a patch you can try.  It will add a _lot_ of debugging
information to the system log.  Maybe it will help pin down the source
of the problem.

Alan Stern



Index: 2.6.31/drivers/usb/host/ohci-hcd.c
===
--- 2.6.31.orig/drivers/usb/host/ohci-hcd.c
+++ 2.6.31/drivers/usb/host/ohci-hcd.c
@@ -197,7 +197,7 @@ static int ohci_urb_enqueue (
 
/* allocate the TDs (deferring hash chain updates) */
for (i = 0; i  size; i++) {
-   urb_priv-td [i] = td_alloc (ohci, mem_flags);
+   urb_priv-td [i] = td_alloc (ohci, mem_flags, urb-dev, 
urb-ep);
if (!urb_priv-td [i]) {
urb_priv-length = i;
urb_free_priv (ohci, urb_priv);
Index: 2.6.31/drivers/usb/host/ohci-mem.c
===
--- 2.6.31.orig/drivers/usb/host/ohci-mem.c
+++ 2.6.31/drivers/usb/host/ohci-mem.c
@@ -82,7 +82,8 @@ dma_to_td (struct ohci_hcd *hc, dma_addr
 
 /* TDs ... */
 static struct td *
-td_alloc (struct ohci_hcd *hc, gfp_t mem_flags)
+td_alloc (struct ohci_hcd *hc, gfp_t mem_flags, struct usb_device *udev,
+   struct usb_host_endpoint *ep)
 {
dma_addr_t  dma;
struct td   *td;
@@ -94,6 +95,8 @@ td_alloc (struct ohci_hcd *hc, gfp_t mem
td-hwNextTD = cpu_to_hc32 (hc, dma);
td-td_dma = dma;
/* hashed in td_fill */
+   ohci_info(hc, td alloc for %s ep%x: %p\n,
+   udev-devpath, ep-desc.bEndpointAddress, td);
}
return td;
 }
@@ -103,8 +106,14 @@ td_free (struct ohci_hcd *hc, struct td 
 {
struct td   **prev = hc-td_hash [TD_HASH_FUNC (td-td_dma)];
 
-   while (*prev  *prev != td)
+   ohci_info(hc, td free %p\n, td);
+   while (*prev  *prev != td) {
+   if ((unsigned long) *prev == 0xa7a7a7a7) {
+   ohci_info(hc, poisoned hash at %p\n, prev);
+   return;
+   }
prev = (*prev)-td_hash;
+   }
if (*prev)
*prev = td-td_hash;
else if ((td-hwINFO  cpu_to_hc32(hc, TD_DONE)) != 0)
Index: 2.6.31/drivers/usb/host/ohci-q.c
===
--- 2.6.31.orig/drivers/usb/host/ohci-q.c
+++ 2.6.31/drivers/usb/host/ohci-q.c
@@ -403,7 +403,7 @@ static struct ed *ed_get (
}
 
/* dummy td; end of td list for ed */
-   td = td_alloc (ohci, GFP_ATOMIC);
+   td = td_alloc (ohci, GFP_ATOMIC, udev, ep);
if (!td) {
/* out of memory */
ed_free (ohci, ed);

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

2009-12-03 Thread Mauro Carvalho Chehab
Gerd Hoffmann wrote:

 One final pass over the lirc interface would be good, taking the chance
 to fixup anything before the ABI is set in stone with the mainline
 merge.  Things to look at:
 
   (1) Make sure ioctl structs are 32/64 bit invariant.
   (2) Maybe add some reserved fields to allow extending later
   without breaking the ABI.
   (3) Someone suggested a 'commit' ioctl which would activate
   the parameters set in (multiple) previous ioctls.  Makes sense?

A better approach is to create an ioctl that can send a group of 
value/attribute pairs
at the same time. We used this estrategy for V4L extended controls to do things 
like
setting an mpeg encoder (were we need to adjust several parameters at the same 
time,
and adding all of them on one struct would be hard, since you can't specify all
of them sa the same time). The same strategy is also used by DVB API to allow it
to use any arbitrary protocol. It was conceived to support DVB-S2.

   (4) Add a ioctl to enable/disable evdev event submission for
   evdev/lirc hybrid drivers.

Yes, all above makes sense.
 
 I'm still on the fence over what to do about lirc_imon. The driver
 supports essentially 3 generations of devices. First-gen is very old
 imon parts that don't do onboard decoding. Second-gen is the devices
 that all got (insanely stupidly) tagged with the exact same usb
 device ID (0x15c2:0xffdc), some of which have an attached VFD, some
 with an attached LCD, some with neither, some that are actually RF
 parts, but all (I think) of which do onboard decoding. Third-gen is
 the latest stuff, which is all pretty sane, unique device IDs for
 unique devices, onboard decoding, etc.
 
 Do have second-gen and third-gen devices have a 'raw mode'?  If so, then
 there should be a lirc interface for raw data access.
 
 So the lirc_imon I submitted supports all device types, with the
 onboard decode devices defaulting to operating as pure input devices,
 but an option to pass hex values out via the lirc interface (which is
 how they've historically been used -- the pure input stuff I hacked
 together just a few weeks ago), to prevent functional setups from
 being broken for those who prefer the lirc way.
 
 Hmm.  I'd tend to limit the lirc interface to the 'raw samples' case.

 Historically it has also been used to pass decoded data (i.e. rc5) from
 devices with onboard decoding, but for that in-kernel mapping + input
 layer really fits better.

I agree.

 
 What I'm debating is whether this should be split into two drivers,
 one for the older devices that don't do onboard decoding (which would
 use the lirc_dev interface) called 'lirc_imon' or 'lirc_imon_legacy',
 and one that is a pure input driver, not unlike the ati_remote{,2}
 drivers, with no lirc_dev dependency at all, probably called simply
 'imon'.
 
 i.e. lirc_imon would support first+second gen, and imon third-gen
 devices, without overlap?
 
 But if I split it out, there may end up being a
 fair amount of code duplication,
 
 You could try to split common code into a third module used by the other
 two.  Or have one module for all devices which is a evdev/lirc hybrid.
 
Splitting it into a core driver and two different drivers for raw/non-raw
device makes sense to me.

An alternative would be to have just one module, but splitting the code into
3 parts. This allows an easier understanding, IMHO.

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: af9015: tuner id:179 not supported, please report!

2009-12-03 Thread Jan Sundman
Hi Bert and Mike,

The information that you have regarding the TDA18218, where can I get my
hands on that? It would be interesting to take a shot at writing the
driver, but I guess I would need some pointers in the right direction.

Would it be possible to get the information from you, or is such
information freely available on the internet? Where should I start
looking?

Best regards,

//Jan

On Wed, 2009-12-02 at 18:08 -0500, Michael Krufky wrote:
 On Wed, Dec 2, 2009 at 5:06 PM, Bert Massop bert.mas...@gmail.com wrote:
  Jan Sundman jan.sundman at aland.net writes:
 
 
  Hi,
 
  I just received a usb DVB-T card and have been trying to get it to work
  under Ubuntu 9.10, but to no avail. dmesg shows the following when
  plugging in the card:
 
  [   35.280024] usb 2-1: new high speed USB device using ehci_hcd and
  address 4
  [   35.435978] usb 2-1: configuration #1 chosen from 1 choice
  [   35.450176] af9015: tuner id:179 not supported, please report!
  [   35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval:
  10 - 7
  [   35.453097] input: Afatech DVB-T 2
  as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8
  [   35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID
  v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1
 
  lsusb shows:
  Bus 002 Device 005: ID 15a4:9016
 
  and finally lsmod | grep dvb
  dvb_usb_af9015 37152  0
  dvb_usb22892  1 dvb_usb_af9015
  dvb_core  109716  1 dvb_usb
 
  While googling for an answer to my troubles I came across
  http://ubuntuforums.org/showthread.php?t=606487page=5 which hints that
  the card may use the TDA18218HK tuner chip which does not seem to be
  supported currently.
 
  Does anyone have any experience regarding this chip and know what to do
  to get it working.
 
  Best regards,
 
  //Jan
 
 
 
  Hi Jan,
 
  As stated in the Ubuntuforums thread, there doesn't seem to be any support 
  for
  this chip at the moment. I don't know how hard it is to code support for a
  specific tuner, but I'm looking into that right now.
 
  Hopefully some more experienced coders will join in writing something 
  usable, as
  I don't think I will be able to do it myself.
 
  Please drop a message if anyone finds something useful.
 
  Best regards,
 
  Bert
 
 The TDA18218 is not currently supported under Linux.  I have the
 information needed to write a driver to support it, but I do not have
 any devices that use it, nor any interest (as of now) to write the
 driver on my own time.
 
 For me, it would not be very difficult to get this done, as I have
 done work to support a similar family of tuners -- TDA18271 /
 TDA18211.  The TDA18218 tuner is not supported by the current driver.
 
 In the past, I would have gone ahead and written a driver for the
 sheer enjoyment of doing so... but nowadays, I actually have other
 projects of a higher priority that need my attention instead.
 
 If, in the future, any commercial entity has interest in seeing this
 tuner silicon supported under Linux, they should contact me -- perhaps
 my desire to write this driver can be increased ;-)
 
 Regards,
 
 Mike Krufky
 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


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


test

2009-12-03 Thread desmono
test

--
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: Replace Mercurial with GIT as SCM

2009-12-03 Thread Guennadi Liakhovetski
On Thu, 3 Dec 2009, Hans Verkuil wrote:

 On Wednesday 02 December 2009 04:55:00 Andy Walls wrote:
  On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote:
   Hi all,
  
   I would like to start a discussion which ideally results in either
   changing the SCM of v4l-dvb to git _or_ leaving everything as it is today
   with mercurial.
  
  
   I'm waiting for comments.
 
  I only have one requirement: reduce bandwidth usage between the server
  and my home.
 
  The less I have to clone out 65 M of history to start a new series of
  patches the better.  I suppose that would include a rebase...
 
 Unfortunately, one reason for moving to git would be to finally be able to 
 make changes to the arch directory tree. The fact that that part is 
 unavailable in v4l-dvb is a big problem when working with SoCs. And these 
 will 
 become much more important in the near future.

FWIW, tomorrow (or a day or two later) I'll have to spend time again 
back-porting arch changes from git to hg, to be able to push my current 
patches...

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: af9015: tuner id:179 not supported, please report!

2009-12-03 Thread Bert Massop
Hi Jan,

The datasheet for the TDA18218 can be obtained from NXP:
http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf

That's all the information I have at the moment, maybe Mike has some
other information (like the Application Note mentioned in the
datasheet, that claims to contain information on writing drivers, but
cannot be found anywhere).

Best regards,

Bert

On Thu, Dec 3, 2009 at 22:15, Jan Sundman jan.sund...@aland.net wrote:

 Hi Bert and Mike,

 The information that you have regarding the TDA18218, where can I get my
 hands on that? It would be interesting to take a shot at writing the
 driver, but I guess I would need some pointers in the right direction.

 Would it be possible to get the information from you, or is such
 information freely available on the internet? Where should I start
 looking?

 Best regards,

 //Jan

 On Wed, 2009-12-02 at 18:08 -0500, Michael Krufky wrote:
  On Wed, Dec 2, 2009 at 5:06 PM, Bert Massop bert.mas...@gmail.com wrote:
   Jan Sundman jan.sundman at aland.net writes:
  
  
   Hi,
  
   I just received a usb DVB-T card and have been trying to get it to work
   under Ubuntu 9.10, but to no avail. dmesg shows the following when
   plugging in the card:
  
   [   35.280024] usb 2-1: new high speed USB device using ehci_hcd and
   address 4
   [   35.435978] usb 2-1: configuration #1 chosen from 1 choice
   [   35.450176] af9015: tuner id:179 not supported, please report!
   [   35.452891] Afatech DVB-T 2: Fixing fullspeed to highspeed interval:
   10 - 7
   [   35.453097] input: Afatech DVB-T 2
   as /devices/pci:00/:00:13.2/usb2/2-1/2-1:1.1/input/input8
   [   35.453141] generic-usb 0003:15A4:9016.0005: input,hidraw3: USB HID
   v1.01 Keyboard [Afatech DVB-T 2] on usb-:00:13.2-1/input1
  
   lsusb shows:
   Bus 002 Device 005: ID 15a4:9016
  
   and finally lsmod | grep dvb
   dvb_usb_af9015         37152  0
   dvb_usb                22892  1 dvb_usb_af9015
   dvb_core              109716  1 dvb_usb
  
   While googling for an answer to my troubles I came across
   http://ubuntuforums.org/showthread.php?t=606487page=5 which hints that
   the card may use the TDA18218HK tuner chip which does not seem to be
   supported currently.
  
   Does anyone have any experience regarding this chip and know what to do
   to get it working.
  
   Best regards,
  
   //Jan
  
  
  
   Hi Jan,
  
   As stated in the Ubuntuforums thread, there doesn't seem to be any 
   support for
   this chip at the moment. I don't know how hard it is to code support for a
   specific tuner, but I'm looking into that right now.
  
   Hopefully some more experienced coders will join in writing something 
   usable, as
   I don't think I will be able to do it myself.
  
   Please drop a message if anyone finds something useful.
  
   Best regards,
  
   Bert
 
  The TDA18218 is not currently supported under Linux.  I have the
  information needed to write a driver to support it, but I do not have
  any devices that use it, nor any interest (as of now) to write the
  driver on my own time.
 
  For me, it would not be very difficult to get this done, as I have
  done work to support a similar family of tuners -- TDA18271 /
  TDA18211.  The TDA18218 tuner is not supported by the current driver.
 
  In the past, I would have gone ahead and written a driver for the
  sheer enjoyment of doing so... but nowadays, I actually have other
  projects of a higher priority that need my attention instead.
 
  If, in the future, any commercial entity has interest in seeing this
  tuner silicon supported under Linux, they should contact me -- perhaps
  my desire to write this driver can be increased ;-)
 
  Regards,
 
  Mike Krufky
  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


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

2009-12-03 Thread Christoph Bartelmus
Hi Mauro,

on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote:
[...]
 So the lirc_imon I submitted supports all device types, with the
 onboard decode devices defaulting to operating as pure input devices,
 but an option to pass hex values out via the lirc interface (which is
 how they've historically been used -- the pure input stuff I hacked
 together just a few weeks ago), to prevent functional setups from
 being broken for those who prefer the lirc way.

 Hmm.  I'd tend to limit the lirc interface to the 'raw samples' case.

 Historically it has also been used to pass decoded data (i.e. rc5) from
 devices with onboard decoding, but for that in-kernel mapping + input
 layer really fits better.

 I agree.

Consider passing the decoded data through lirc_dev.
- there's a large user base already that uses this mode through lirc and  
would be forced to switch to input layer if it disappears.
- that way all IR drivers would consistently use lirc interface and all  
PnP hooks could be implemented there in one place.
- drivers like lirc_imon that have to support both raw and decoded mode,  
currently have to implement both the lirc and the input interface.  
Complexity could be reduced in such cases. But maybe this is necessary  
anyway for lirc_imon that also includes mouse functionality. Jarod?

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


Re: af9015: tuner id:179 not supported, please report!

2009-12-03 Thread Devin Heitmueller
On Thu, Dec 3, 2009 at 4:47 PM, Bert Massop bert.mas...@gmail.com wrote:
 Hi Jan,

 The datasheet for the TDA18218 can be obtained from NXP:
 http://www.nxp.com/documents/data_sheet/TDA18218HN.pdf

 That's all the information I have at the moment, maybe Mike has some
 other information (like the Application Note mentioned in the
 datasheet, that claims to contain information on writing drivers, but
 cannot be found anywhere).

 Best regards,

 Bert

Took a quick look at that datasheet.  I would guess between that
datasheet and a usbsnoop, there is probably enough there to write a
driver that basically works for your particular hardware if you know
what you are doing.  The register map is abbreviated, but probably
good enough...

Devin


-- 
Devin J. Heitmueller - 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


Re: V4L1 compatibility broken for VIDIOCGTUNER with radio

2009-12-03 Thread hermann pitton
Hi,

Am Donnerstag, den 03.12.2009, 16:56 -0200 schrieb Herton Ronaldo
Krzesinski:
 Hi,
 
 After commit 9bedc7f (V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM 
 default handlers), radio software using V4L1 stopped to work on a saa7134 
 card, a git bisect pointed to this commit introducing the regression. All 
 VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this 
 commit.
 
 Investigating the issue, it turns out that v4l1_compat_get_tuner calls 
 VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is 
 returning -EINVAL to user space applications which are being confused about 
 this.
 
 May be VIDIOC_G_STD change in the commit above should be reverted, or 
 v4l1_compat_get_tuner changed to not return error with G_STD, or not call 
 G_STD ioctl for a radio device?
 
 --
 []'s
 Herton

it was fixed here.

http://linuxtv.org/hg/v4l-dvb/rev/58ecda742a70

Maybe it was not ported to stable?

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


Endless loop with error messages

2009-12-03 Thread Ivo Steinmann
Hello all

After some uptime, I allways get an endless loop of these messages:

Dec  3 21:55:21 mediaserv kernel: [118604.764577] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.764580] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.764591] saa7146 (1):
unexpected i2c irq: isr e7fffbb7 psr  ssr 
Dec  3 21:55:21 mediaserv kernel: [118604.764594] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.764597] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.765299] saa7146 (1):
unexpected i2c irq: isr e7fffbb7 psr  ssr 
Dec  3 21:55:21 mediaserv kernel: [118604.765302] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.765305] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.767852] saa7146 (3):
unexpected i2c irq: isr e7fffbb7 psr  ssr 
Dec  3 21:55:21 mediaserv kernel: [118604.767855] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.767858] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.775192] saa7146 (1):
unexpected i2c irq: isr e7fffbb7 psr  ssr 
Dec  3 21:55:21 mediaserv kernel: [118604.775194] saa7146:
interrupt_hw(): warning: interrupt enabled, but not handled
properly.(0xe7fcfbb7)
Dec  3 21:55:21 mediaserv kernel: [118604.775197] saa7146:
interrupt_hw(): disabling interrupt source(s)!
Dec  3 21:55:21 mediaserv kernel: [118604.777377] saa7146 (3):
unexpected i2c irq: isr e7fffbb7 psr  ssr 


The CPU usage is 100% in both cores, and the machine is really locked.
Login in console takes about 5minutes. Each keystroke around 20sec.

I unloaded these modules
budget_av
budget_ci
budget_core
saa7146_vv
saa7146

The the machine is usable again.

Linux x 2.6.31.4 #3 SMP Mon Nov 16 12:29:18 CET 2009 x86_64 GNU/Linux

-Ivo Steinmann

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

2009-12-03 Thread Dmitry Torokhov
On Thu, Dec 03, 2009 at 10:51:00PM +0100, Christoph Bartelmus wrote:
 Hi Mauro,
 
 on 03 Dec 09 at 19:10, Mauro Carvalho Chehab wrote:
 [...]
  So the lirc_imon I submitted supports all device types, with the
  onboard decode devices defaulting to operating as pure input devices,
  but an option to pass hex values out via the lirc interface (which is
  how they've historically been used -- the pure input stuff I hacked
  together just a few weeks ago), to prevent functional setups from
  being broken for those who prefer the lirc way.
 
  Hmm.  I'd tend to limit the lirc interface to the 'raw samples' case.
 
  Historically it has also been used to pass decoded data (i.e. rc5) from
  devices with onboard decoding, but for that in-kernel mapping + input
  layer really fits better.
 
  I agree.
 
 Consider passing the decoded data through lirc_dev.
 - there's a large user base already that uses this mode through lirc and  
 would be forced to switch to input layer if it disappears.

I believe it was agreed that lirc-dev should be used mainly for decoding
protocols that are more conveniently decoded in userspace and the
results would be looped back into input layer through evdev which will
be the main interface for consumer applications to use.

-- 
Dmitry
--
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: acks needed for arch/sh parts of the patches

2009-12-03 Thread Paul Mundt
On Thu, Dec 03, 2009 at 10:58:08PM +0100, Guennadi Liakhovetski wrote:
 unfortunately 3 of my V4L patches for 2.6.33 have to touch arch/sh 
 simultaneously with drivers and headers. Therefore I need your acks to 
 them for arch parts. All those patches have already been posted to the 
 list at different times, here are links to them (perhaps, with some minor 
 differences):
 
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/13307
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11492
 http://article.gmane.org/gmane.linux.drivers.video-input-infrastructure/11504
 
 I will also send patches directly to you without cc-ing the list for 
 easier review. If you have no objections, you can just reply to this mail 
 confirming your 3 acks, if you have any comments, please reply to 
 respective mails, and then, please, add the v4l list back to cc.
 
Looks good to me.

Acked-by: Paul Mundt let...@linux-sh.org
--
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: Replace Mercurial with GIT as SCM

2009-12-03 Thread Mauro Carvalho Chehab
Em Thu, 3 Dec 2009 22:42:38 +0100 (CET)
Guennadi Liakhovetski g.liakhovet...@gmx.de escreveu:

 On Thu, 3 Dec 2009, Hans Verkuil wrote:
 
  On Wednesday 02 December 2009 04:55:00 Andy Walls wrote:
   On Tue, 2009-12-01 at 15:59 +0100, Patrick Boettcher wrote:
Hi all,
   
I would like to start a discussion which ideally results in either
changing the SCM of v4l-dvb to git _or_ leaving everything as it is 
today
with mercurial.
   
   
I'm waiting for comments.

GIT.

However, just using what we have in -hg at -git won't give much benefits. We
should really move forward and use a clone of Linus tree.

I intend to work on a way to allow us to move to -git, while preserving our
building system. My target is to do it at the beginning of the next year.

  
   I only have one requirement: reduce bandwidth usage between the server
   and my home.
  
   The less I have to clone out 65 M of history to start a new series of
   patches the better.  I suppose that would include a rebase...

The first clone of the Linus -git tree will be more painful than 65 Mb of 
downloads
Well, -git supports partial clone, were it discards the old history:

$git help clone
...
   --depth depth
  Create a shallow clone with a history truncated to the specified 
number of revisions. A shallow
  repository has a number of limitations (you cannot clone or fetch 
from it, nor push from nor into it),
  but is adequate if you are only interested in the recent history 
of a large project with a long history,
  and would want to send in fixes as patches.
...

I never used it, so I can't tell if this works properly.

However, the big advantage with -git is that, once you have one local clone,
you may do other clones that will use a shared repository of objects.

Here, I use one git full clone of the Linus tree, created with:
git clone --bare git repository master-git-repo.git

Being a bare tree, it will only contain the objects (we generally name bare 
repos with .git extension).

Then, my -git working dirs are created with:
git clone -s 
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git 
linux-2.6.git

This clone is very fast, since it is local and is sharing the bare objects.

I then add, at myclone/.git/config two remote repositories, like:

[remote linus]
URL = /home/myhome/tokernel/bare/linus.git/
fetch = +refs/tags/*:refs/remotes/linus/*
fetch = +refs/heads/master:refs/remotes/linus/upstream
tagopt = --no-tags
[remote origin]
URL = 
ssh://my.remote.site.org/pub/scm/linux/kernel/git/mchehab/linux-2.6.git
fetch = +refs/heads/*:refs/remotes/linux-2.6.git/*
Push = refs/heads/*:refs/heads/*

This way, every time I want to update from upstream or from my remote repo,
I run a script with something like:

$ (cd linux-2.6.git  git fetch)
$ (cd myclone  git remote update)

And, every time I want to push to my remote repo, i do:
$ git push origin

The advantage of having a bare directory is that I can have several other local 
git
trees, each completely independent from the bare, and all with all the files 
checked-out.

If you're doing lots of things at the same time, this is a way safer than using 
branches.

Btw, git branch work really really well. Also, as git revlog provides a 
changelog history,
you can do rollbacks if needed.

Ah, with respect to rebase, the better way, IMHO, to rebase your directory is 
to create
a new branch based on the latest upstream, pull the patches there, and then 
rebase.
The big advantage is that you'll keep your old work untouched, so, if you do 
something wrong,
you can simply delete the new branch an do it again.

  
  Unfortunately, one reason for moving to git would be to finally be able to 
  make changes to the arch directory tree. The fact that that part is 
  unavailable in v4l-dvb is a big problem when working with SoCs. And these 
  will 
  become much more important in the near future.
 
 FWIW, tomorrow (or a day or two later) I'll have to spend time again 
 back-porting arch changes from git to hg, to be able to push my current 
 patches...

My current maintainership live is to do ports/backports between hg and git. 
This is
very time demanding those days... Moving to git will be really great.




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: [PATCH] uvcvideo: add another YUYV format GUID

2009-12-03 Thread Laurent Pinchart
Hi Daniel,

On Wednesday 02 December 2009 00:48:44 Daniel Ritz wrote:
 For some unknown reason, on a MacBookPro5,3 the iSight

Could you please send me the output of lsusb -v both with the correct and 
wrong GUID ?

 _sometimes_ report a different video format GUID.

Sometimes only ? Now that's weird. Is that completely random ?

 This patch add the other (wrong) GUID to the format table, making the iSight
 work always w/o other problems.
 
 What it should report: 32595559--0010-8000-00aa00389b71
 What it often reports: 32595559--0010-8000-00389b71
 
 Signed-off-by: Daniel Ritz daniel.r...@gmx.ch

--
Regards,

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


Re: V4L1 compatibility broken for VIDIOCGTUNER with radio

2009-12-03 Thread hermann pitton

Am Donnerstag, den 03.12.2009, 21:04 -0200 schrieb Herton Ronaldo
Krzesinski:
 Em Qui 03 Dez 2009, às 19:54:29, hermann pitton escreveu:
  Hi,
  
  Am Donnerstag, den 03.12.2009, 16:56 -0200 schrieb Herton Ronaldo
  Krzesinski:
   Hi,
   
   After commit 9bedc7f (V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM 
   default handlers), radio software using V4L1 stopped to work on a 
   saa7134 
   card, a git bisect pointed to this commit introducing the regression. All 
   VIDIOCGTUNER calls on a v4l1 application are returning -EINVAL after this 
   commit.
   
   Investigating the issue, it turns out that v4l1_compat_get_tuner calls 
   VIDIOC_G_STD ioctl, but as it is a radio device (saa7134-radio) it now is 
   returning -EINVAL to user space applications which are being confused 
   about 
   this.
   
   May be VIDIOC_G_STD change in the commit above should be reverted, or 
   v4l1_compat_get_tuner changed to not return error with G_STD, or not call 
   G_STD ioctl for a radio device?
   
   --
   []'s
   Herton
  
  it was fixed here.
  
  http://linuxtv.org/hg/v4l-dvb/rev/58ecda742a70
 
 Indeed, thanks for the pointer. I forgot to check latest v4l1-compat.c /o\
 
  
  Maybe it was not ported to stable?
 
 Not on latest stable (2.6.31.6), perhaps it should be forwarded.
 

Yes, for sure. It's our fault.

Seems we had an internal server error :(

I came across it by accident.

 The only other issue I'm aware of is that radio is broken since guessed
 8 weeks on my tuners, only realized when testing on enabling external
 active antenna voltage for DVB-T on a/some 310i.

I did the bisect with some delay and Hans marked the fix with priority
high, but we missed to point Mike at it for stable explicitly.

Mike, please review and forward.

Sorry,
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: [PATCH 1/2 v4] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats

2009-12-03 Thread Hans Verkuil
On Thursday 03 December 2009 15:16:56 Guennadi Liakhovetski wrote:
 Video subdevices, like cameras, decoders, connect to video bridges over
 specialised busses. Data is being transferred over these busses in various
 formats, which only loosely correspond to fourcc codes, describing how video
 data is stored in RAM. This is not a one-to-one correspondence, therefore we
 cannot use fourcc codes to configure subdevice output data formats. This patch
 adds codes for several such on-the-bus formats and an API, similar to the
 familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
 codes. After all users of the old API in struct v4l2_subdev_video_ops are
 converted, it will be removed. Also add helper routines to support generic
 pass-through mode for the soc-camera framework.
 
 Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
 ---
 
 v3 - v4: more comments addressed - thanks! Now based on the current 
 linux-next. Hans, as for _nXk suffixes, I preferred to preserve them to 
 keep all notation explicit. Without them a format like 
 V4L2_MBUS_FMT_SBGGR10 would be ambiguous, whether one of 
 V4L2_MBUS_FMT_SBGGR10_2X8_PAD*_?E or the V4L2_MBUS_FMT_SBGGR10_1X10 is 
 meant. I also removed struct soc_mbus_datafmt and soc_mbus_find_datafmt() 
 upon your request, although I'm not happy having to open-code it in about 
 4 drivers. But we can extract that code in a generic routine later. One of 
 the important advantages of that struct and function was, that they 
 allowed to keep supported formats in drivers centrally at just one 
 location, thus being able to add new or remove deprecated formats easily, 
 and to avoid long switch-case blocks by just calling one function to 
 search in the array.
 
 Thanks
 Guennadi
 
  drivers/media/video/Makefile   |2 +-
  drivers/media/video/soc_mediabus.c |  157 
 
  include/media/soc_mediabus.h   |   65 +++
  include/media/v4l2-mediabus.h  |   61 ++
  include/media/v4l2-subdev.h|   19 -
  5 files changed, 302 insertions(+), 2 deletions(-)
  create mode 100644 drivers/media/video/soc_mediabus.c
  create mode 100644 include/media/soc_mediabus.h
  create mode 100644 include/media/v4l2-mediabus.h
 
 diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
 index 7a2dcc3..e7bc8da 100644
 --- a/drivers/media/video/Makefile
 +++ b/drivers/media/video/Makefile
 @@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
  obj-$(CONFIG_VIDEO_CX23885) += cx23885/
  
  obj-$(CONFIG_VIDEO_OMAP2)+= omap2cam.o
 -obj-$(CONFIG_SOC_CAMERA) += soc_camera.o
 +obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
  obj-$(CONFIG_SOC_CAMERA_PLATFORM)+= soc_camera_platform.o
  # soc-camera host drivers have to be linked after camera drivers
  obj-$(CONFIG_VIDEO_MX1)  += mx1_camera.o
 diff --git a/drivers/media/video/soc_mediabus.c 
 b/drivers/media/video/soc_mediabus.c
 new file mode 100644
 index 000..c54cae7
 --- /dev/null
 +++ b/drivers/media/video/soc_mediabus.c
 @@ -0,0 +1,157 @@
 +/*
 + * soc-camera media bus helper routines
 + *
 + * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@gmx.de
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License version 2 as
 + * published by the Free Software Foundation.
 + */
 +
 +#include linux/kernel.h
 +#include linux/module.h
 +
 +#include media/v4l2-device.h
 +#include media/v4l2-mediabus.h
 +#include media/soc_mediabus.h
 +
 +#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1)
 +
 +static const struct soc_mbus_pixelfmt mbus_fmt[] = {
 + [MBUS_IDX(YUYV8_2X8)] = {
 + .fourcc = V4L2_PIX_FMT_YUYV,
 + .name   = YUYV,
 + .bits_per_sample= 8,
 + .packing= SOC_MBUS_PACKING_2X8_PADHI,
 + .order  = SOC_MBUS_ORDER_LE,
 + }, [MBUS_IDX(YVYU8_2X8)] = {
 + .fourcc = V4L2_PIX_FMT_YVYU,
 + .name   = YVYU,
 + .bits_per_sample= 8,
 + .packing= SOC_MBUS_PACKING_2X8_PADHI,
 + .order  = SOC_MBUS_ORDER_LE,
 + }, [MBUS_IDX(UYVY8_2X8)] = {
 + .fourcc = V4L2_PIX_FMT_UYVY,
 + .name   = UYVY,
 + .bits_per_sample= 8,
 + .packing= SOC_MBUS_PACKING_2X8_PADHI,
 + .order  = SOC_MBUS_ORDER_LE,
 + }, [MBUS_IDX(VYUY8_2X8)] = {
 + .fourcc = V4L2_PIX_FMT_VYUY,
 + .name   = VYUY,
 + .bits_per_sample= 8,
 + .packing= SOC_MBUS_PACKING_2X8_PADHI,
 + .order  = 

Re: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video

2009-12-03 Thread Devin Heitmueller
On Thu, Dec 3, 2009 at 11:00 PM, John S Gruber johnsgru...@gmail.com wrote:
 I have problems with my audio that I've tracked down to the transfer
 of audio from the au0828
 in my hvr-950Q. I spotted the following comment about green screen
 detection and I wonder
 if it might be related.

 drivers/media/video/au0828/au0828-video.c:

        /* Workaround for a bug in the au0828 hardware design that sometimes
           results in the colorspace being inverted */

 The problem is that sound/usb/usbaudio.c assumes that each urb data
 field contains an integer
 number of audio frames (aka audio slots), in this case a integer
 number of left channel-right
 channel pairs. About 12 times a second for my device a urb doesn't.
 This causes a flutter noise
 with non-quiet audio that contains a difference between the channels.

 I found this by using audacity to look at wave forms and a usb trace
 to see the problematic urb's.
 I've confirmed by relaxing the constraint in sound/usb/usbaudio.c with
 a patch and can confirm that
 it clears up the audio.


 Is the code comment at the top related to my problem?

 More importantly, is there the possibility of setting up the transfer
 differently so that
 audio slots aren't split between urbs?


 From what I have read in the spec I believe the split of the audio
 slots between urb's is non-
 conformant. Therefore I think it would be a mistake to change the
 default behaviour of
 usbaudio.c since, as it is now,usbaudio.c won't swap channels in the
 case of dropped urbs.
 It would be optimal if the hvr-950q could be set up to conform by not
 splitting audio slots.

 I think the problem also occurs for video when blue will turn to pink
 for a flash until the top
 of frame resyncs things up--because of the corresponding swap of UY
 with VY. This seems
 to be related to how busy my system is and what usb slot I'm using on
 my laptop. Again
 I could see in a usb trace the urb's with data_lengths such that UY
 would be split from the
 corresponding VY. The video transfer is a straight byte copy so
 ordinarily this isn't a
 problem but would be if an abnormally sized urb were dropped and the
 device and host
 were to get out of sync regarding V and U.

 I also have caught an occasional odd number of bytes transferred in
 traces, which requires
 the drop of incomplete samples in usbaudio.c. I wonder if this is
 related to the green screen
 problem on video from the top comment.

 The easiest way to reproduce the audio problem is to use the composite
 video input but only
 hook up either the left or the right audio. With earphonesyou can hear
 the audio rapidly
 go from ear to ear.

 Thanks for those on the list for their hard work on getting devices
 such as this to work. I'd
 appreciate any answers, comments, corrections, or information.

Hi John,

I have actually actively debugging the au0828 audio this evening.  The
comment you referred to (which I wrote) has to do with the delivery of
the UYVY data from the demodulator to the au0828 bridge, which can
cause the start of the stream to be off-by-one (the pink/green you see
is the colorspace inverted when the decoder loses sync).

It is unrelated to audio.

I'm working an issue now where the audio keeps dropping out.  If you
want to show me the code change you did to usbaudio.c, it might give
me a better understand the issue.

Cheers,

Devin

-- 
Devin J. Heitmueller - 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


Re: [PATCH] uvcvideo: add another YUYV format GUID

2009-12-03 Thread Justin P. Mattock

On 12/03/09 18:05, Daniel Ritz wrote:

Hi Laurent

On Thu, 2009-12-03 at 21:15 +0100, Laurent Pinchart wrote:

Hi Daniel,

On Wednesday 02 December 2009 00:48:44 Daniel Ritz wrote:

For some unknown reason, on a MacBookPro5,3 the iSight


Could you please send me the output of lsusb -v both with the correct and
wrong GUID ?


sure. i attached three files:
   isight-good.txt, isight-bad.txt, isight-good2.txt

this is three reboots in a row from like 10 minutes ago. the first
boot into linux was actually rebooting from OSX...first cold boot
today directly into linux had the right GUID.




_sometimes_ report a different video format GUID.


Sometimes only ? Now that's weird. Is that completely random ?


yes, sometimes only. it seems to be related to reboots, but i don't
know what exactly triggers it. rmmod/modprobe doesn't trigger it.
also, when the wrong GUID is reported, the only way of fixing it is
to reboot. it really is just the GUID. even when the wrong one is
reported, the device works just fine.

i started with a plain ubuntu 9.10, kernel 2.6.31 which was supposed
to fail, so i upgraded to a 2.6.32-rc8 to fix the iSight and some other
things, just to see it fail again. a reboot later and it worked, some
time and reboot later it failed again...

rgds
-daniel


This patch add the other (wrong) GUID to the format table, making the iSight
work always w/o other problems.

What it should report: 32595559--0010-8000-00aa00389b71
What it often reports: 32595559--0010-8000-00389b71

Signed-off-by: Daniel Ritzdaniel.r...@gmx.ch


--
Regards,

Laurent Pinchart




I get weiredness whenever
I shutdown the machine and then boot.
If I boot, then reboot things work.

Justin P. Mattock
--
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


drivers/media/video/gspca/ov534.c warning

2009-12-03 Thread Andrew Morton
drivers/media/video/gspca/ov534.c: In function 'setsharpness_96':
drivers/media/video/gspca/ov534.c:1539: warning: comparison is always false due 
to limited range of data type

this code can't ever have worked.
--
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: Hauppage hvr-950q au0828 transfer problem affecting audio and perhaps video

2009-12-03 Thread Devin Heitmueller
On Thu, Dec 3, 2009 at 11:21 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
 On Thu, Dec 3, 2009 at 11:00 PM, John S Gruber johnsgru...@gmail.com wrote:
 I have problems with my audio that I've tracked down to the transfer
 of audio from the au0828
 in my hvr-950Q. I spotted the following comment about green screen
 detection and I wonder
 if it might be related.

 drivers/media/video/au0828/au0828-video.c:

        /* Workaround for a bug in the au0828 hardware design that sometimes
           results in the colorspace being inverted */

 The problem is that sound/usb/usbaudio.c assumes that each urb data
 field contains an integer
 number of audio frames (aka audio slots), in this case a integer
 number of left channel-right
 channel pairs. About 12 times a second for my device a urb doesn't.
 This causes a flutter noise
 with non-quiet audio that contains a difference between the channels.

 I found this by using audacity to look at wave forms and a usb trace
 to see the problematic urb's.
 I've confirmed by relaxing the constraint in sound/usb/usbaudio.c with
 a patch and can confirm that
 it clears up the audio.


 Is the code comment at the top related to my problem?

 More importantly, is there the possibility of setting up the transfer
 differently so that
 audio slots aren't split between urbs?


 From what I have read in the spec I believe the split of the audio
 slots between urb's is non-
 conformant. Therefore I think it would be a mistake to change the
 default behaviour of
 usbaudio.c since, as it is now,usbaudio.c won't swap channels in the
 case of dropped urbs.
 It would be optimal if the hvr-950q could be set up to conform by not
 splitting audio slots.

 I think the problem also occurs for video when blue will turn to pink
 for a flash until the top
 of frame resyncs things up--because of the corresponding swap of UY
 with VY. This seems
 to be related to how busy my system is and what usb slot I'm using on
 my laptop. Again
 I could see in a usb trace the urb's with data_lengths such that UY
 would be split from the
 corresponding VY. The video transfer is a straight byte copy so
 ordinarily this isn't a
 problem but would be if an abnormally sized urb were dropped and the
 device and host
 were to get out of sync regarding V and U.

 I also have caught an occasional odd number of bytes transferred in
 traces, which requires
 the drop of incomplete samples in usbaudio.c. I wonder if this is
 related to the green screen
 problem on video from the top comment.

 The easiest way to reproduce the audio problem is to use the composite
 video input but only
 hook up either the left or the right audio. With earphonesyou can hear
 the audio rapidly
 go from ear to ear.

 Thanks for those on the list for their hard work on getting devices
 such as this to work. I'd
 appreciate any answers, comments, corrections, or information.

 Hi John,

 I have actually actively debugging the au0828 audio this evening.  The
 comment you referred to (which I wrote) has to do with the delivery of
 the UYVY data from the demodulator to the au0828 bridge, which can
 cause the start of the stream to be off-by-one (the pink/green you see
 is the colorspace inverted when the decoder loses sync).

 It is unrelated to audio.

 I'm working an issue now where the audio keeps dropping out.  If you
 want to show me the code change you did to usbaudio.c, it might give
 me a better understand the issue.

I am definitely seeing what you are saying with regards to the channel
flipping back and forth.  Do you know what size URBs are being
delivered?  If you've got a hacked up version of usbaudio.c, how about
adding a printk() line which dumps out the URB size and send me a
dump?

Devin

-- 
Devin J. Heitmueller - 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


Re: saa7134 (not very) new board 5168:0307

2009-12-03 Thread tomloh...@gmail.com

Hi hermann,

we are this results :

with

tda827x_cfg_0, tda827x_cfg_1 or tda827x_cfg_2

we have a perfect image without sound on the analogic part (test with mplayer),
a partial result with dvb-t : we need to initialize first with analogic (with 
cold boot, the card doesn't work on dvb)
but only for few seconds(sound and image are ok) 
then re-initialize with analogic, work for few seconds on dvb and then nothing

maybe i am wrong but, the sound part for analogic is a problem of redirection, 
isn't it  ?

here are our configuration for this card :

in saa7134-dvb.c

static struct tda1004x_config tda827x_flydvbtduo_medion_config = {
.demod_address = 0x08,
.invert= 1,
.invert_oclk   = 0,
.xtal_freq = TDA10046_XTAL_16M,
.agc_config= TDA10046_AGC_TDA827X,
.gpio_config   = TDA10046_GP01_I,
.if_freq   = TDA10046_FREQ_045,
.i2c_gate  = 0x4b,
.tuner_address = 0x61,
.antenna_switch = 2,
.request_firmware = philips_tda1004x_request_firmware
};

case SAA7134_BOARD_FLYDVBTDUO_MEDION:
if (configure_tda827x_fe(dev, tda827x_flydvbtduo_medion_config,
 tda827x_cfg_2)  0)
goto dettach_frontend;
break;
default:
wprintk(Huh? unknown DVB card?\n);
break;


in saa7134-cards.c

   [SAA7134_BOARD_FLYDVBTDUO_MEDION] = {
   .name   = LifeView FlyDVB-T DUO Medion,
   .audio_clock= 0x00187de7,
   .tuner_type = TUNER_PHILIPS_TDA8290,
   .radio_type = UNSET,
   .tuner_addr= ADDR_UNSET,
   .radio_addr= ADDR_UNSET,
   .gpiomask= 0x0020,
   .mpeg   = SAA7134_MPEG_DVB,
   .inputs = {{
   .name = name_tv,
   .vmux = 1,
   .amux = TV,
   .gpio = 0x20, /* GPIO21=High for TV input */
   .tv   = 1,
   },{
   .name = name_comp1,/* Composite signal on S-Video input */
   .vmux = 3,
   .amux = LINE1,
   },{
   .name = name_svideo,/* S-Video signal on S-Video input */
   .vmux = 8,
   .amux = LINE1,
   }},
   .radio = {
   .name = name_radio,
   .amux = TV,
   .gpio = 0x00,/* GPIO21=Low for FM radio antenna */
   },


.vendor   = PCI_VENDOR_ID_PHILIPS,
   .device   = PCI_DEVICE_ID_PHILIPS_SAA7133,
   .subvendor= 0x5168,
   .subdevice= 0x0307,  /* LR307-N */  
   .driver_data  = SAA7134_BOARD_FLYDVBTDUO_MEDION,


case SAA7134_BOARD_FLYDVBTDUO_MEDION:
   {
   /* this is a hybrid board, initialize to analog mode
* and configure firmware eeprom address
*/
   u8 data[] = { 0x3c, 0x33, 0x60};
   struct i2c_msg msg = {.addr=0x08, .flags=0, .buf=data, .len = 
sizeof(data)};

   i2c_transfer(dev-i2c_adap, msg, 1);
   break;




What can we do to have dvb fully supported ?

thanks in advance,

Cheers,

Thomas

--
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 v0 1/2] V4L - vpfe capture - convert ccdc drivers to platform drivers

2009-12-03 Thread Nori, Sekhar
On Fri, Dec 04, 2009 at 01:21:43, Karicheri, Muralidharan wrote:


[...]

 
  +  if (!res) {
  +  status = -EBUSY;
  +  goto fail_nores;
  +  }
  +
  +  ccdc_base_addr = ioremap_nocache(res-start, res_len);
  +  if (!ccdc_base_addr) {
  +  status = -EBUSY;
 [Hiremath, Vaibhav] Is -EBUSY right return value, I think it should be -
 ENXIO or -ENOMEM.
 
 I see -ENXIO  -ENOMEM being used by drivers. -ENXIO stands for No such 
 device or address. ENOMEM stands for Out of memory . Since we are trying 
 to map the address here, -ENXIO looks reasonable to me. Same if 
 request_mem_region() fails.


Sergei had posted on this earlier[1]. Quoting him here:


 What are the proper error codes when platform_get_resource,

-ENODEV.

 request_mem_region

-EBUSY.

 and ioremap functions fail?.

-ENOMEM.


Not sure if ioremap failure can relate to absence of a device.

Thanks,
Sekhar

[1] 
http://www.mail-archive.com/davinci-linux-open-sou...@linux.davincidsp.com/msg14973.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


linux-next i386 allmodconfig

2009-12-03 Thread Andrew Morton
ERROR: __divdf3 [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __adddf3 [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __fixunsdfsi [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __udivdi3 [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __floatsidf [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __muldf3 [drivers/media/dvb/frontends/atbm8830.ko] undefined!
ERROR: __adddf3 [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __fixunsdfsi [drivers/media/common/tuners/max2165.ko] undefined!
ERROR: __floatsidf [drivers/media/common/tuners/max2165.ko] undefined!

would be nice to get that fixed up before merging.
--
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: DVB-APPS patch for uk-WinterHill

2009-12-03 Thread BOUWSMA Barry
On Thu, 3 Dec 2009, Justin Hornsby wrote:

 Since 02 Dec 2009 the UK WinterHill transmitter site has been
 broadcasting on different frequencies  in a different mode with
 different modulation.  Channels have been re-arranged to occupy five
 multiplexes and the original BBC 'B' mux is now broadcasting DVB-T2
 for high definition services (which of course cannot yet be tuned by
 mere mortals). The 'WinterHill B' transmitter stopped broadcasting on
 02 Dec.
 
 The attached file is a patch to reflect these changes.

 +T 74600 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 +T 77000 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 +T 77800 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 +T 79400 8MHz 2/3 NONE QAM64 8k 1/32 NONE
 +T 801833000 8MHz 2/3 NONE QAM64 8k 1/32 NONE

While the DVB-T2 multiplex (MUX B) cannot be tuned by existing
DVB-T-only devices, and I don't know if the dvb-apps are being
prepared for DVB-T2 (there don't appear to be any of the
known DVB-S2 transponders listed in a couple positions), the
modulation parameters, for future reference, are probably
something like

+# T2 73800 8MHz 2/3 NONE QAM256 32k 1/128 NONE #E54 DVB-T2 HD MUX B

There may need to be additional details specified, I'm no expert.
These values are, of course, unconfirmed.

The same would be true for Crystal Palace at 10kW, but on channel
E31, or 55400, no offset.


barry bouwsma
--
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?

2009-12-03 Thread Christoph Bartelmus
Hi Dmitry,

on 03 Dec 09 at 14:12, Dmitry Torokhov wrote:
[...]
 Consider passing the decoded data through lirc_dev.
[...]
 I believe it was agreed that lirc-dev should be used mainly for decoding
 protocols that are more conveniently decoded in userspace and the
 results would be looped back into input layer through evdev which will
 be the main interface for consumer applications to use.

Quoting myself:
 Currently I would tend to an approach like this:
 - raw interface to userspace using LIRC

For me this includes both the pulse/space data and also the scan codes  
when hardware does the decoding.
Consider cases like this:
http://lirc.sourceforge.net/remotes/lg/6711A20015N

This is an air-conditioner remote.
The entries that you see in this config file are not really separate  
buttons. Instead the remote just sends the current settings for e.g.  
temperature encoded in the protocol when you press some up/down key. You  
really don't want to map all possible temperature settings to KEY_*  
events. For such cases it would be nice to have access at the raw scan  
codes from user space to do interpretation of the data.
The default would still be to pass the data to the input layer, but it  
won't hurt to have the possibility to access the raw data somehow.

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