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

2009-12-14 Thread Jean-Francois Moine
On Sun, 13 Dec 2009 21:46:28 +0100
Németh Márton nm...@freemail.hu wrote:

 It seems that kernels before 2.6.24 (inclusively) do not have
 __devinitconst, so  conex.c and etoms.c can only build with 2.6.25
 and later. Should USB_GSPCA_CONEX and USB_GSPCA_ETOMS be added to
 v4l/versions.txt?

The fix is not the right one. Some other gspca subdrivers use
__devinitconst (pac7302, pac7311, sonixb and spca506). The fix is to
define the macro for kernels  2.6.25:

diff -r 174ad3097f17 linux/drivers/media/video/gspca/gspca.h
--- a/linux/drivers/media/video/gspca/gspca.h   Sun Dec 13 18:11:07
2009 +0100
+++ b/linux/drivers/media/video/gspca/gspca.h   Mon Dec 14 09:28:51
2009 +0100 @@ -11,6 +11,10 @@ /* compilation option */
 #define GSPCA_DEBUG 1
 
+#if LINUX_VERSION_CODE  KERNEL_VERSION(2, 6, 25)
+#define __devinitconst __section(.devinit.rodata)
+#endif
+
 #ifdef GSPCA_DEBUG
 /* GSPCA our debug messages */
 extern int gspca_debug;

I will ask to upload the changeset (actually in my test repository) as
soon as it is validated (i.e. if it works with hal).

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


Dvico FusionHDTV Dual Express PCIe tuner issues

2009-12-14 Thread James Turnbull
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all

I've got a Dvico FusionHDTV Dual Express PCIe tuner, which returns
the following lspci output:

lspci output:

03:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885
PCI Video and Audio Decoder (rev 02)
Subsystem: DViCO Corporation Device db78
Flags: fast devsel, IRQ 16
Memory at fb80 (64-bit, non-prefetchable) [size=2M]
Capabilities: [40] Express Endpoint, MSI 00
Capabilities: [80] Power Management version 2
Capabilities: [90] Vital Product Data ?
Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+
Count=1/1 Enable-
Capabilities: [100] Advanced Error Reporting
UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSVoil-
UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSVoil-
UESvrt: DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSVoil-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [200] Virtual Channel ?
Kernel modules: cx23885

I understood the digital side of the card was supported but I can't
get it to work.  I've tried the cx23885 module in v4l-dvb HEAD but
get the following error ( on kernel 2.6.27.41-170.2.117.fc10.i686):

# modprobe cx23885
FATAL: Error inserting cx23885
(/lib/modules/2.6.27.41-170.2.117.fc10.i686/kernel/drivers/media/video/cx23885/cx23885.ko):
Unknown symbol in module, or unknown parameter (see dmesg)

dmesg output:

cx23885: Unknown symbol v4l2_i2c_new_probed_subdev
cx23885: Unknown symbol videobuf_dvb_alloc_frontend
cx23885: Unknown symbol v4l2_i2c_subdev_addr
cx23885: Unknown symbol videobuf_dvb_get_frontend
cx23885: Unknown symbol v4l2_device_register
cx23885: Unknown symbol videobuf_dvb_unregister_bus
cx23885: Unknown symbol videobuf_dvb_register_bus
cx23885: Unknown symbol v4l2_i2c_tuner_addrs
cx23885: Unknown symbol v4l2_device_unregister
cx23885: Unknown symbol v4l2_i2c_new_subdev
cx23885: Unknown symbol v4l2_i2c_new_probed_subdev
cx23885: Unknown symbol videobuf_dvb_alloc_frontend
cx23885: Unknown symbol v4l2_i2c_subdev_addr
cx23885: Unknown symbol videobuf_dvb_get_frontend
cx23885: Unknown symbol v4l2_device_register
cx23885: Unknown symbol videobuf_dvb_unregister_bus
cx23885: Unknown symbol videobuf_dvb_register_bus
cx23885: Unknown symbol v4l2_i2c_tuner_addrs
cx23885: Unknown symbol v4l2_device_unregister
cx23885: Unknown symbol v4l2_i2c_new_subdev
cx23885: Unknown symbol v4l2_i2c_new_subdev_cfg
cx23885: Unknown symbol videobuf_dvb_alloc_frontend
cx23885: Unknown symbol v4l2_i2c_subdev_addr
cx23885: Unknown symbol ir_codes_hauppauge_new_table
cx23885: Unknown symbol v4l2_device_register_subdev
cx23885: Unknown symbol v4l_bound_align_image
cx23885: Unknown symbol ir_rc5_timer_keyup
cx23885: Unknown symbol v4l2_device_unregister_subdev
cx23885: Unknown symbol videobuf_dvb_get_frontend
cx23885: Unknown symbol ir_input_init
cx23885: Unknown symbol v4l2_device_register
cx23885: Unknown symbol videobuf_dvb_unregister_bus
cx23885: Unknown symbol ir_input_nokey
cx23885: Unknown symbol ir_rc5_decode
cx23885: Unknown symbol ir_input_unregister
cx23885: Unknown symbol videobuf_dvb_register_bus
cx23885: Unknown symbol v4l2_i2c_tuner_addrs
cx23885: Unknown symbol v4l2_device_unregister
cx23885: Unknown symbol ir_input_keydown
cx23885: Unknown symbol ir_input_register
cx23885: Unknown symbol v4l2_i2c_new_subdev_cfg
cx23885: Unknown symbol videobuf_dvb_alloc_frontend
cx23885: Unknown symbol v4l2_i2c_subdev_addr
cx23885: Unknown symbol ir_codes_hauppauge_new_table
cx23885: Unknown symbol v4l2_device_register_subdev
cx23885: Unknown symbol v4l_bound_align_image
cx23885: Unknown symbol ir_rc5_timer_keyup
cx23885: Unknown symbol v4l2_device_unregister_subdev
cx23885: Unknown symbol videobuf_dvb_get_frontend
cx23885: Unknown symbol ir_input_init
cx23885: Unknown symbol v4l2_device_register
cx23885: Unknown symbol videobuf_dvb_unregister_bus
cx23885: Unknown symbol ir_input_nokey
cx23885: Unknown symbol ir_rc5_decode
cx23885: Unknown symbol ir_input_unregister
cx23885: Unknown symbol videobuf_dvb_register_bus
cx23885: Unknown symbol v4l2_i2c_tuner_addrs
cx23885: Unknown symbol v4l2_device_unregister
cx23885: Unknown symbol ir_input_keydown
cx23885: Unknown symbol ir_input_register

Anyone have any ideas/a fix for this?

Regards

James Turnbull

- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG 

Re: Compile Error - ir-keytable

2009-12-14 Thread Mauro Carvalho Chehab
Jeremy Simmons wrote:
 I'm having the same problem.  Any solution?

The new IR keycode is not compatible with any kernel older than 2.6.22. Also, 
newer
versions may even require latter codes, due to the sysfs code.

The fix is simple: 
- Don't compile any code from ir-sysfs.c with older kernels;
- Don't implement EVIO[G|S]KEYCODE ioctls;
- Replace the new code to get a key by an old code at ir-keytable.c,
  if kernels = 2.6.22.

There's nothing reasonable that we can do to support keycode replacements
with older kernels, as the scancode tables were expanded to 16 bits (and 
will probably be expanded to 32 or 64 bits), and, with the legacy kernels,
the scancode/keycode table needs to be an array of the size of the scancode 
space.
So, a keycode table for 32 bits would waste 4Gb of ram (while we're still using
16 bits, the table won't be that big, but as we expect to soon support
RC6 protocols, it is not worth to port a code for 16 bits that will just
be dropped in a month or two).

Due to that, the support for  2.6.22 kernels will provide a limited IR
code, after the backport: just the bundled IR will work.

I asked Douglas to do this backport after I finish the main changes at the 
module.

He'll likely start looking on it soon, as I've merged late yesterday the 
changes.

 
 -Jeremy
 
 
 
 
 
 * Subject: Compile Error - ir-keytable 
 * From: David Carlo dca...@ 
 * Date: Wed, 2 Dec 2009 11:56:22 -0500 
 
 Hello.  I'm compiling the v4l kernel drivers in an attempt to use my hdpvr
 with CentOS 5.4.  When I compile v4l, I'm getting this error:
 
 =
 snip
   CC [M]  /usr/local/src/v4l-dvb/v4l/ir-functions.o
   CC [M]  /usr/local/src/v4l-dvb/v4l/ir-keymaps.o
   CC [M]  /usr/local/src/v4l-dvb/v4l/ir-keytable.o
 /usr/local/src/v4l-dvb/v4l/ir-keytable.c: In function
 'ir_g_keycode_from_table':
 /usr/local/src/v4l-dvb/v4l/ir-keytable.c:181: error: implicit declaration of
 function 'input_get_drvdata'
 /usr/local/src/v4l-dvb/v4l/ir-keytable.c:181: warning: initialization makes
 pointer from integer without a cast
 /usr/local/src/v4l-dvb/v4l/ir-keytable.c: In function 'ir_input_free':
 /usr/local/src/v4l-dvb/v4l/ir-keytable.c:236: warning: initialization makes
 pointer from integer without a cast
 make[3]: *** [/usr/local/src/v4l-dvb/v4l/ir-keytable.o] Error 1
 make[2]: *** [_module_/usr/local/src/v4l-dvb/v4l] Error 2
 make[2]: Leaving directory `/usr/src/kernels/2.6.18-164.6.1.el5-x86_64'
 make[1]: *** [default] Error 2
 make[1]: Leaving directory `/usr/local/src/v4l-dvb/v4l'
 make: *** [all] Error 2
 =
 
 Here are the stats on my box:
   CentOS 5.4 x86_64
   kernel 2.6.18-164.6.1.el5-x86_64
   gcc 4.1.2
 
 Has anyone else seen this?
 
 --Dave
 
 --
 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: no locking on dvb-s2 22000 2/3 8PSK transponder on Astra 19.2E with tt s2-3200

2009-12-14 Thread Oleg Roitburd
2009/12/9 Newsy Paper newspaperman_germ...@yahoo.com:
 Hi,

 no matter if I use Igors or Manus driver, there's no lock on 11303 h 22000 
 2/3 8psk. Other users at vdr-portal report same problem.

 The strange thing is that all other transponders that use 22000 2/3 8psk do 
 work but this transponder doesn't. It worked fine until december 3rd when 
 uplink moved to Vienna. I think they changed a parameter like rolloff or 
 inversion and the dvb-s2 part of stb6100 is buggy.

It works again. Very strange.

$ sudo ./scan-s2 -x -2 -O S19.2E ORF.ini
API major 5, minor 0
scanning ORF.ini
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder DVB-S2 11303000 H 2200 2/3 35 8PSK
-- Using DVB-S2
 tune to: 11303:hC23M5O35S1:S19.2E:22000:
DVB-S IF freq is 1553000
 parse_section, section number 0 out of 0...!
service_id = 0x0
service_id = 0x132F
pmt_pid = 0x6B
service_id = 0x1330
pmt_pid = 0x6C
service_id = 0x1331
pmt_pid = 0x6D
 parse_section, section number 0 out of 0...!
  VIDEO : PID 0x0DFF
  AUDIO : PID 0x0E00
  AUDIO : PID 0x0E01
  AC3   : PID 0x0E03
  TELETEXT  : PID 0x0E04
 parse_section, section number 0 out of 0...!
  CA ID : PID 0x0D05
  CA ID : PID 0x1702
  CA ID : PID 0x1833
  CA ID : PID 0x0648
  CA ID : PID 0x0D95
  CA ID : PID 0x09C4
  VIDEO : PID 0x0B68
  AUDIO : PID 0x0B69
  AC3   : PID 0x0B6B
  AUDIO : PID 0x0B6A
  TELETEXT  : PID 0x0B6D
 parse_section, section number 0 out of 0...!
  CA ID : PID 0x0D05
  CA ID : PID 0x1702
  CA ID : PID 0x1833
  CA ID : PID 0x0648
  CA ID : PID 0x0D95
  CA ID : PID 0x09C4
  VIDEO : PID 0x0780
  AUDIO : PID 0x0781
  AC3   : PID 0x0783
  AUDIO : PID 0x0782
  TELETEXT  : PID 0x0785
 parse_section, section number 0 out of 0...!
0x03EF 0x132F: pmt_pid 0x006B ORF -- ORF1 HD (running, scrambled)
0x03EF 0x1330: pmt_pid 0x006C ORF -- ORF2 HD (running, scrambled)
0x03EF 0x1331: pmt_pid 0x006D ServusTV -- Servus TV HD (running)
 parse_section, section number 0 out of 0...!
dumping lists (3 services)
ORF1 
HD;ORF:11303:hC23M5O35S1:S19.2E:22000:1920:1921=ger,1922=ENG;1923=ger:1925:D05,1702,1833,648,D95,9C4:4911:1:1007:0
ORF2 
HD;ORF:11303:hC23M5O35S1:S19.2E:22000:2920:2921=ger,2922=ENG;2923=ger:2925:D05,1702,1833,648,D95,9C4:4912:1:1007:0
Servus TV 
HD;ServusTV:11303:hC23M5O35S1:S19.2E:22000:3583:3584=ger,3585=eng;3587=ger:3588:0:4913:1:1007:0

Regards

Oleg Roitburd
--
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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS

2009-12-14 Thread Mauro Carvalho Chehab
Jean-Francois Moine wrote:
 On Sun, 13 Dec 2009 21:46:28 +0100
 Németh Márton nm...@freemail.hu wrote:
 
 It seems that kernels before 2.6.24 (inclusively) do not have
 __devinitconst, so  conex.c and etoms.c can only build with 2.6.25
 and later. Should USB_GSPCA_CONEX and USB_GSPCA_ETOMS be added to
 v4l/versions.txt?
 
 The fix is not the right one. Some other gspca subdrivers use
 __devinitconst (pac7302, pac7311, sonixb and spca506). The fix is to
 define the macro for kernels  2.6.25:
 
 diff -r 174ad3097f17 linux/drivers/media/video/gspca/gspca.h
 --- a/linux/drivers/media/video/gspca/gspca.h   Sun Dec 13 18:11:07
 2009 +0100
 +++ b/linux/drivers/media/video/gspca/gspca.h   Mon Dec 14 09:28:51
 2009 +0100 @@ -11,6 +11,10 @@ /* compilation option */
  #define GSPCA_DEBUG 1
  
 +#if LINUX_VERSION_CODE  KERNEL_VERSION(2, 6, 25)
 +#define __devinitconst __section(.devinit.rodata)
 +#endif
 +

Better to add it at v4l/compat.h, to avoid polluting the drivers with
compat code.

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: New ASUS P3-100 DVB-T/DVB-S device (1043:48cd)

2009-12-14 Thread hermann pitton
Hi,

Am Montag, den 14.12.2009, 08:26 +0100 schrieb dvblinux:
 The complete name of the board is:
 
 ASUS My Cinema PS3-100/PTS/FM/AV/RC ouch :-)
 
 You're right:
 
 It features the same features than the ASUS My Cinema P7131 Hybrid
 that is: S-Video in, Composite and audio in with a special splitter
 cord, an FM tuner and IR remote control. All connectors are the same for
 both cards, but the additionnal DVB-S.
 
 The remote control seems to behave exactely the same as P7131, i.e new
 entries in /dev/input/ as a regular keyboard.
 
 I'll post additionnal stuff later, thanks for your answer.
 
 Regards.

the card is a little different than the OEM 3in1 it seems.

Just some hints for your further testing.

On card=147 the DVB-T demod is at 0x0b, but on P7131 Hybrid LNA on 0x08.
You might want to change it in saa7134-dvb.c in the 3in1_config and in
saa7134-cards.c for analog initialization.

To test on DVB-S you need to pass use_frontend=1 to the saa7134-dvb
module. That tuner is at 0x60, might be different for you.

On later P7131 type of cards, like Dual and Hybrid LNA, there is a
female antenna input connector _also_ for radio on the board. The DVB-T
RF input is switched to that shared radio/DVB-T input with
antenna_switch = 2 and gpio 0x020 for analog radio. Analog TV
remains on the other RF input.

The 3in1 OEM version has a male radio antenna input on the card, so with
antenna_switch = 1 analog TV and DVB-T are on the same single female
connector on that one, only for radio we switch to the other.

Good luck,
Hermann

 
 Le lundi 14 décembre 2009 à 02:36 +0100, hermann pitton a écrit :
  Hi,
  
  sorry for delay, no time for the list during the last days.
  
  Am Freitag, den 11.12.2009, 16:02 +0100 schrieb dvbli...@free.fr:
   Hi all, I'm new on this list.
   
   I modified on my own the SAA driver to manage an ASUS PS3-100 combo card 
   not
   supported yet in current version.
   
   It features two DVB-S and DVB-T receivers packed on the same PCI card.
  
  I'm not aware of such an Asus PCI card with two DVB-S and DVB-T
  receivers. We might hang in wording ...
  
  Maybe one DVB-S, one DVB-T/analog hybrid tuner/demod and also support
  for analog radio and external S-Video/Composite and analog audio in?
  
   The DVB-T part is identical to ASUS P7131 Hybrid and therefore is managed 
   thru
   the existing driver after a light patch in the driver source (and card.c):
   copying relevant stuff from (1043:4876) to (1043:48cd).
   
   I'm not a developper, how to share my successfull experiments ?
  
  We have support for the Asus Tiger 3in1 since last summer.
  This board was OEM only and also does not come with a remote, but your
  stuff is very likely based on that one.
  
  Please try all functions and inputs and post related dmesg output
  loading the saa7134 driver with card=147 i2c_scan=1.
  
  It has the same LNA config like the ASUS P7131 Hybrid LNA too.
  
  I can't tell anything about a possible remote, but last on Asus was a
  transmitter labeled PC-39 that far and that one we do support.
  
  Cheers,
  Hermann
  
  
  
 

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


Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Mauro Carvalho Chehab
Guennadi Liakhovetski wrote:
 Hi Mauro,
 
 At last soc-camera and mediabus lot for 2.6.33. Note, that one of this 
 patches adds new fourcc codes. A patch for their documentation will be 
 submitted immediately.
 
 Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb
 
 for the following 30 changesets:
 
 01/30: tw9910: The driver can also handle revision 1 of the chip
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734
 
 02/30: soc-camera: remove no longer needed struct members
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c
 
 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in 
 soc-camera
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19
 
 04/30: soc-camera: fix multi-line comment coding style
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109
 
 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a client 
 fails
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb
 
 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc 
 codes
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59
 
 07/30: soc-camera: add a private field to struct soc_camera_link
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132
 
 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c
 
 09/30: soc-camera: switch drivers and platforms to use .priv in struct 
 soc_camera_link
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633
 
 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3
 
 11/30: tw9910: Add revision control
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3
 
 12/30: tw9910: simplify chip ID calculation
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84
 
 13/30: tw9910: Tri-state pins when idle
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0
 
 14/30: tw9910: Add power control
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f
 
 15/30: tw9910: tw9910_set_hsync clean up
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121
 
 16/30: tw9910: Add revision control to tw9910_set_hsync
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679
 
 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame 
 formats
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a
 
 18/30: soc-camera: convert to the new mediabus API
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b
 
 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0
 
 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add 
 platform data
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c
 
 21/30: mt9t031: make the use of the soc-camera client API optional
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8
 
 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1
 
 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490
 
 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b
 
 25/30: tw9910: modify V/H outpit pin setting to use VALID
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942
 
 26/30: tw9910: modify output format
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1
 
 27/30: tw9910: remove cropping
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a
 
 28/30: tw9910: Add sync polarity support
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0
 
 29/30: soc-camera: Add mt9t112 camera driver
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937
 
 30/30: sh_mobile_ceu_camera: Remove frame size page alignment
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f
 
 
  a/linux/arch/sh/boards/board-ap325rxa.c|  606 --
  b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt |  157 +
  b/linux/arch/sh/boards/mach-ap325rxa/setup.c   |  657 +++
  b/linux/arch/sh/boards/mach-kfr2r09/setup.c|  622 ++
  b/linux/drivers/media/video/mt9t112.c  | 1177 
 +
  b/linux/drivers/media/video/soc_mediabus.c |  157 +
  

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Guennadi Liakhovetski
On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:

 Guennadi Liakhovetski wrote:
  Hi Mauro,
  
  At last soc-camera and mediabus lot for 2.6.33. Note, that one of this 
  patches adds new fourcc codes. A patch for their documentation will be 
  submitted immediately.
  
  Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb
  
  for the following 30 changesets:
  
  01/30: tw9910: The driver can also handle revision 1 of the chip
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734
  
  02/30: soc-camera: remove no longer needed struct members
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c
  
  03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in 
  soc-camera
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19
  
  04/30: soc-camera: fix multi-line comment coding style
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109
  
  05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a 
  client fails
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb
  
  06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc 
  codes
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59
  
  07/30: soc-camera: add a private field to struct soc_camera_link
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132
  
  08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c
  
  09/30: soc-camera: switch drivers and platforms to use .priv in struct 
  soc_camera_link
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633
  
  10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3
  
  11/30: tw9910: Add revision control
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3
  
  12/30: tw9910: simplify chip ID calculation
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84
  
  13/30: tw9910: Tri-state pins when idle
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0
  
  14/30: tw9910: Add power control
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f
  
  15/30: tw9910: tw9910_set_hsync clean up
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121
  
  16/30: tw9910: Add revision control to tw9910_set_hsync
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679
  
  17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame 
  formats
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a
  
  18/30: soc-camera: convert to the new mediabus API
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b
  
  19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0
  
  20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add 
  platform data
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c
  
  21/30: mt9t031: make the use of the soc-camera client API optional
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8
  
  22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1
  
  23/30: tw9910: use V4L2_FIELD_INTERLACED_BT
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490
  
  24/30: sh_mobile_ceu_camera: Add support for sync polarity selection
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b
  
  25/30: tw9910: modify V/H outpit pin setting to use VALID
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942
  
  26/30: tw9910: modify output format
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1
  
  27/30: tw9910: remove cropping
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a
  
  28/30: tw9910: Add sync polarity support
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0
  
  29/30: soc-camera: Add mt9t112 camera driver
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937
  
  30/30: sh_mobile_ceu_camera: Remove frame size page alignment
  http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f
  
  
   a/linux/arch/sh/boards/board-ap325rxa.c|  606 --
   b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt |  157 +
   b/linux/arch/sh/boards/mach-ap325rxa/setup.c   |  657 +++
   b/linux/arch/sh/boards/mach-kfr2r09/setup.c|  622 ++
   

RE: Latest stack that can be merged on top of linux-next tree

2009-12-14 Thread Karicheri, Muralidharan
Guennadi,

I marged relevant files from the latest of your v4l tree after seeing your pull 
request. I worked fine for VGA capture. But I need to enable SOC_CAMERA to get 
the MT9T031 enabled which looks improper to me. Can we remove this restriction 
from KConfig? I plan to send a vpfe capture patch to support capture using this 
driver this week.

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

-Original Message-
From: Guennadi Liakhovetski [mailto:g.liakhovet...@gmx.de]
Sent: Friday, December 11, 2009 7:47 PM
To: Karicheri, Muralidharan
Cc: linux-media@vger.kernel.org
Subject: Re: Latest stack that can be merged on top of linux-next tree

Hi Muralidharan

On Thu, 10 Dec 2009, Karicheri, Muralidharan wrote:

 Guennadi,

 I am not sure if your MT9T031 changes are part of linux-next tree at
 v4l-dvb. If not, can you point me to the latest stack that I can apply
 on top of linux-next tree to get your latest changes for MT9T031 sensor
 driver?

As you probably have seen, I posted a pull request a couple of hours ago,
which also contains the change to mt9t031, that you're asking about.

 I plan to do integrate sensor driver with vpfe capture driver this week.

 BTW, Is there a driver for the PCA9543 i2c switch that is part of
 MT9T031 headboard?

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: Latest stack that can be merged on top of linux-next tree

2009-12-14 Thread Guennadi Liakhovetski
On Mon, 14 Dec 2009, Karicheri, Muralidharan wrote:

 Guennadi,
 
 I marged relevant files from the latest of your v4l tree after seeing 
 your pull request. I worked fine for VGA capture.

Good.

 But I need to enable 
 SOC_CAMERA to get the MT9T031 enabled which looks improper to me. Can we 
 remove this restriction from KConfig?

Sure, as long as we have a valid case where the driver can and does work 
without soc-camera, which we now do, we shall remove this dependency.

 I plan to send a vpfe capture 
 patch to support capture using this driver this week.

Good, looking forward to it.

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: Latest stack that can be merged on top of linux-next tree

2009-12-14 Thread Karicheri, Muralidharan
Guennadi,

 I plan to send a vpfe capture
 patch to support capture using this driver this week.

Good, looking forward to it.

I will copy you on the request for reviewing the patch.
It will be great if you can review the same. 
-Murali

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: [PULL] soc-camera and mediabus

2009-12-14 Thread Jonathan Cameron
Hi All,

 3) it would be interesting to patch the other sensor drivers to be compatible
with soc_camera (mt9v011/ov7670);
 
 Well, this could be done, yes, but does it make sense to do this blindly 
 without any hardware to test? I would rather add such conversions on a 
 one-by-one basis as need arises.
 
I'm working on the ov7670. I've added the media bus stuff to what I've
previously posted but I haven't tested as yet.  For reference, a quick and dirty
cut of the patch is below.  Some thought is needed on how to deal with the 
sections
that currently need to be different for the soc-camera and non soc camera uses.
(mainly the registration code in probe).

On another note, does anyone have an objection to making the set_bus_param
function optional?   At the moment we are adding null functions for those
devices that can't actually change anything which seems a little pointless.

Jonathan


diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
index 0e2184e..e57c3b5 100644
--- a/drivers/media/video/ov7670.c
+++ b/drivers/media/video/ov7670.c
@@ -18,6 +18,7 @@
 #include media/v4l2-device.h
 #include media/v4l2-chip-ident.h
 #include media/v4l2-i2c-drv.h
+#include media/soc_camera.h
 
 
 MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
@@ -545,7 +546,7 @@ static struct ov7670_format_struct {
.bpp= 1
},
 };
-#define N_OV7670_FMTS ARRAY_SIZE(ov7670_formats)
+
 
 
 /*
@@ -668,52 +669,37 @@ static int ov7670_set_hw(struct v4l2_subdev *sd, int 
hstart, int hstop,
return ret;
 }
 
+static enum v4l2_mbus_pixelcode ov7670_codes[] = {
+   V4L2_MBUS_FMT_YUYV8_2X8,
+   V4L2_MBUS_FMT_RGB565_2X8_LE,
+};
 
-static int ov7670_enum_fmt(struct v4l2_subdev *sd, struct v4l2_fmtdesc *fmt)
+static int ov7670_enum_fmt(struct v4l2_subdev *sd, int index, enum 
v4l2_mbus_pixelcode *code)
 {
-   struct ov7670_format_struct *ofmt;
-
-   if (fmt-index = N_OV7670_FMTS)
+   if (index = ARRAY_SIZE(ov7670_codes))
return -EINVAL;
 
-   ofmt = ov7670_formats + fmt-index;
-   fmt-flags = 0;
-   strcpy(fmt-description, ofmt-desc);
-   fmt-pixelformat = ofmt-pixelformat;
+   *code = ov7670_codes[index];
return 0;
 }
 
 
 static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
-   struct v4l2_format *fmt,
-   struct ov7670_format_struct **ret_fmt,
-   struct ov7670_win_size **ret_wsize)
+  struct v4l2_mbus_framefmt *mf,
+  struct ov7670_format_struct **ret_fmt,
+  struct ov7670_win_size **ret_wsize)
 {
int index;
struct ov7670_win_size *wsize;
-   struct v4l2_pix_format *pix = fmt-fmt.pix;
 
-   for (index = 0; index  N_OV7670_FMTS; index++)
-   if (ov7670_formats[index].pixelformat == pix-pixelformat)
-   break;
-   if (index = N_OV7670_FMTS) {
-   /* default to first format */
-   index = 0;
-   pix-pixelformat = ov7670_formats[0].pixelformat;
-   }
-   if (ret_fmt != NULL)
-   *ret_fmt = ov7670_formats + index;
-   /*
-* Fields: the OV devices claim to be progressive.
-*/
-   pix-field = V4L2_FIELD_NONE;
+   mf-field = V4L2_FIELD_NONE;
/*
 * Round requested image size down to the nearest
 * we support, but not below the smallest.
 */
for (wsize = ov7670_win_sizes; wsize  ov7670_win_sizes + N_WIN_SIZES;
 wsize++)
-   if (pix-width = wsize-width  pix-height = wsize-height)
+   if ( mf-width = wsize-width  mf-height = wsize-height)
break;
if (wsize = ov7670_win_sizes + N_WIN_SIZES)
wsize--;   /* Take the smallest one */
@@ -722,22 +708,34 @@ static int ov7670_try_fmt_internal(struct v4l2_subdev *sd,
/*
 * Note the size we'll actually handle.
 */
-   pix-width = wsize-width;
-   pix-height = wsize-height;
-   pix-bytesperline = pix-width*ov7670_formats[index].bpp;
-   pix-sizeimage = pix-height*pix-bytesperline;
+   mf-width = wsize-width;
+   mf-height = wsize-height;
+   switch (mf-code) {
+   case V4L2_MBUS_FMT_RGB565_2X8_LE:
+   mf-colorspace = V4L2_COLORSPACE_SRGB;
+   if (ret_fmt != NULL)
+   *ret_fmt = ov7670_formats + 2;
+   break;
+   default:
+   mf-code = V4L2_MBUS_FMT_YUYV8_2X8;
+   case V4L2_MBUS_FMT_YUYV8_2X8:
+   mf-colorspace = V4L2_COLORSPACE_JPEG;
+   if (ret_fmt != NULL)
+   *ret_fmt = ov7670_formats;
+   break;
+   }
return 0;
 }
 
-static int ov7670_try_fmt(struct v4l2_subdev *sd, struct v4l2_format *fmt)
+static int ov7670_try_fmt(struct v4l2_subdev *sd, struct v4l2_mbus_framefmt 
*mf)
 {
-   return 

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Mauro Carvalho Chehab
Guennadi Liakhovetski wrote:
 On Mon, 14 Dec 2009, Mauro Carvalho Chehab wrote:
 
 Guennadi Liakhovetski wrote:
 Hi Mauro,

 At last soc-camera and mediabus lot for 2.6.33. Note, that one of this 
 patches adds new fourcc codes. A patch for their documentation will be 
 submitted immediately.

 Please pull from http://linuxtv.org/hg/~gliakhovetski/v4l-dvb

 for the following 30 changesets:

 01/30: tw9910: The driver can also handle revision 1 of the chip
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f1e67c4ca734

 02/30: soc-camera: remove no longer needed struct members
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ac42a43c9d3c

 03/30: v4l: add new v4l2-subdev sensor operations, use g_skip_top_lines in 
 soc-camera
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f3ce29815a19

 04/30: soc-camera: fix multi-line comment coding style
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=e893641bb109

 05/30: sh_mobile_ceu_camera: do not mark host occupied, when adding a 
 client fails
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=9505453960fb

 06/30: v4l: Add a 10-bit monochrome and missing 8- and 10-bit Bayer fourcc 
 codes
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=fc70aabadc59

 07/30: soc-camera: add a private field to struct soc_camera_link
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8144ecd97132

 08/30: Subject: kernel-sync for arch/sh/boards/mach-ap325rxa/setup.c
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=ea27f790755c

 09/30: soc-camera: switch drivers and platforms to use .priv in struct 
 soc_camera_link
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=54707961f633

 10/30: sh_mobile_ceu_camera: document the scaling and cropping algorithm
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=f490679b43c3

 11/30: tw9910: Add revision control
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4d27f0bec0f3

 12/30: tw9910: simplify chip ID calculation
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=b919641bdf84

 13/30: tw9910: Tri-state pins when idle
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=bb97c53db3c0

 14/30: tw9910: Add power control
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2d8774ea617f

 15/30: tw9910: tw9910_set_hsync clean up
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=669d0a9ca121

 16/30: tw9910: Add revision control to tw9910_set_hsync
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=d3619f5f5679

 17/30: v4l: add a media-bus API for configuring v4l2 subdev pixel and frame 
 formats
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2c60bd900a7a

 18/30: soc-camera: convert to the new mediabus API
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=2a8289e3de7b

 19/30: Subject: kernel-sync for arch/sh/boards/mach-kfr2r09/setup.c
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=4e1dcff622e0

 20/30: rj54n1cb0c: Add cropping, auto white balance, restrict sizes, add 
 platform data
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c2ede215a03c

 21/30: mt9t031: make the use of the soc-camera client API optional
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be8b7a9252d8

 22/30: sh_mobile_ceu: Add V4L2_FIELD_INTERLACED_BT/TB support
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=1a36ae75bdb1

 23/30: tw9910: use V4L2_FIELD_INTERLACED_BT
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=be43ab8c8490

 24/30: sh_mobile_ceu_camera: Add support for sync polarity selection
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=596e9b685f9b

 25/30: tw9910: modify V/H outpit pin setting to use VALID
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8e7ca505b942

 26/30: tw9910: modify output format
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=a42544f649b1

 27/30: tw9910: remove cropping
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=c141cc75045a

 28/30: tw9910: Add sync polarity support
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=750376b279e0

 29/30: soc-camera: Add mt9t112 camera driver
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=37cdd4e97937

 30/30: sh_mobile_ceu_camera: Remove frame size page alignment
 http://linuxtv.org/hg/~gliakhovetski/v4l-dvb?cmd=changeset;node=8da6f7deee9f


  a/linux/arch/sh/boards/board-ap325rxa.c|  606 --
  b/linux/Documentation/video4linux/sh_mobile_ceu_camera.txt |  157 +
  b/linux/arch/sh/boards/mach-ap325rxa/setup.c   |  657 +++
  b/linux/arch/sh/boards/mach-kfr2r09/setup.c|  622 ++
  b/linux/drivers/media/video/mt9t112.c  | 1177 
 +
  

Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Mauro Carvalho Chehab
Jonathan Cameron wrote:
 Hi All,
 
 3) it would be interesting to patch the other sensor drivers to be 
 compatible
with soc_camera (mt9v011/ov7670);
 Well, this could be done, yes, but does it make sense to do this blindly 
 without any hardware to test? I would rather add such conversions on a 
 one-by-one basis as need arises.

 I'm working on the ov7670. I've added the media bus stuff to what I've
 previously posted but I haven't tested as yet.  For reference, a quick and 
 dirty
 cut of the patch is below.  Some thought is needed on how to deal with the 
 sections
 that currently need to be different for the soc-camera and non soc camera 
 uses.
 (mainly the registration code in probe).

True. Couldn't this be a library that handles the code difference between
soc-camera platform-data bits and normal subdev?

Even better: couldn't this code be handled by soc_camera core and just use
subdev interface for both cases?

After finishing the patch, please ping me. I have here an OLPC with ov7670 where
I can test if the new code doesn't break the cafe_ccic driver. You'll probably
need to touch on it, as it will need to use the new mediabus API to talk with 
ov7670.

 On another note, does anyone have an objection to making the set_bus_param
 function optional?   At the moment we are adding null functions for those
 devices that can't actually change anything which seems a little pointless.

Agreed.

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


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

2009-12-14 Thread Igor M. Liplianin
Mauro,

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

for the following changeset:

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


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

Thanks,
Igor

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


Re: [linux-dvb] siano firmware and behaviour after resuming power

2009-12-14 Thread Mauro Carvalho Chehab
Em Thu, 03 Dec 2009 09:53:21 +0100
Luca Olivetti l...@ventoso.org escreveu:

 Ah, ok, I got my sources from linuxtv and there's no firmware there.
 In fact, one of the search results for siano firmware was a message 
 from Mauro asking Uri (who doesn't work for siano any more) for 
 permission to distribute the firmware, with no follow-ups.

Yes. I also tried with Udi, without success so far. It would be really
wonderful if Siano could get binary distribution rights for the firmware.

Cheers,
Mauro.



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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-14 Thread Mauro Carvalho Chehab
Em Sat, 12 Dec 2009 16:00:27 -0500
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:

 Hello Mauro,
 
 Please pull from
 http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the
 following:
 
 cx18-alsa: fix memory leak in error condition
 cx18-alsa: remove a couple of warnings
 cx18-alsa: name alsa device after the actual card
 cx18: cleanup cx18-alsa debug logging
 cx18: rework cx18-alsa module loading to support automatic loading
 cx18-alsa: remove unneeded debug line
 cx18: export more symbols required by cx18-alsa
 cx18: add cx18-alsa module to Makefile
 cx18: overhaul ALSA PCM device handling so it works
 cx18: export a couple of symbols so they can be shared with cx18-alsa
 cx18: make it so cx18-alsa-main.c compiles
 cx18: rename cx18-alsa.c
 cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss
 cx18-alsa: Initial non-working cx18-alsa files
 
 I would also like to take this opportunity to thank ONELAN Limited for
 their sponsoring of this work, as well as to Andy Walls for providing
 some initial code and guidance on how to best integrate the ALSA
 support with the rest of the cx18 driver.

$ ./hgimport http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
Pushing from remote site 
http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: 
hvr-1600-alsa-2
rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado
abort: error: Temporary failure in name resolution

I can't pull. Your site is not responding. 




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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-14 Thread Mauro Carvalho Chehab
Em Mon, 14 Dec 2009 14:07:42 -0200
Mauro Carvalho Chehab mche...@infradead.org escreveu:

 Em Sat, 12 Dec 2009 16:00:27 -0500
 Devin Heitmueller dheitmuel...@kernellabs.com escreveu:
 
  Hello Mauro,
  
  Please pull from
  http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2 for the
  following:
  
  cx18-alsa: fix memory leak in error condition
  cx18-alsa: remove a couple of warnings
  cx18-alsa: name alsa device after the actual card
  cx18: cleanup cx18-alsa debug logging
  cx18: rework cx18-alsa module loading to support automatic loading
  cx18-alsa: remove unneeded debug line
  cx18: export more symbols required by cx18-alsa
  cx18: add cx18-alsa module to Makefile
  cx18: overhaul ALSA PCM device handling so it works
  cx18: export a couple of symbols so they can be shared with cx18-alsa
  cx18: make it so cx18-alsa-main.c compiles
  cx18: rename cx18-alsa.c
  cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss
  cx18-alsa: Initial non-working cx18-alsa files
  
  I would also like to take this opportunity to thank ONELAN Limited for
  their sponsoring of this work, as well as to Andy Walls for providing
  some initial code and guidance on how to best integrate the ALSA
  support with the rest of the cx18 driver.
 
 $ ./hgimport http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2
 Pushing from remote site 
 http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: 
 hvr-1600-alsa-2
 rm: imposível remover `/tmp/newpatches/*': Arquivo ou diretório não encontrado
 abort: error: Temporary failure in name resolution
 
 I can't pull. Your site is not responding. 

Hmm... it seems a temporary failure. It is working now.
 
 
 
 
 Cheers,
 Mauro




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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-14 Thread Devin Heitmueller
On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 I can't pull. Your site is not responding.

 Hmm... it seems a temporary failure. It is working now.

That is strange (works fine from here).  You reported a similar issue
trying to pull one of Michael Krufky's trees last week.  I will have
to keep an eye on it.

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: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-14 Thread Mauro Carvalho Chehab
Em Mon, 14 Dec 2009 11:10:50 -0500
Devin Heitmueller dheitmuel...@kernellabs.com escreveu:

 On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
  I can't pull. Your site is not responding.
 
  Hmm... it seems a temporary failure. It is working now.
 
 That is strange (works fine from here).  You reported a similar issue
 trying to pull one of Michael Krufky's trees last week.  I will have
 to keep an eye on it.

Yep.

Btw, there are a few CodingStyle issues. Please send later a patch fixing it.

I'll be reviewing the patch series.

Cheers,
Mauro


Pushing from remote site 
http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2, tree: 
hvr-1600-alsa-2
Number of patches: 14
/tmp/newpatches/hg_hvr-1600-alsa-2_01.patch with cs=878a34e7beac First patch.
Patch against an older patch:
changeset:   13370:7477df192a59
user:Mauro Carvalho Chehab mche...@redhat.com
date:Wed Nov 18 05:12:04 2009 -0200
summary: Add a list of known issues to v4l2-apps

/tmp/newpatches/hg_hvr-1600-alsa-2_02.patch with cs=a631e089c9d6 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_03.patch with cs=a20a6f8ebf42 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_04.patch with cs=f576485071d3 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_05.patch with cs=605c1f7fed3c Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_06.patch with cs=cb267593943f Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_07.patch with cs=749aa3ccbb84 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_08.patch with cs=4ea6a2a3b501 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_09.patch with cs=58c37088f6a6 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_10.patch with cs=7b6e737ddb79 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_11.patch with cs=6bc4dc4993f7 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_12.patch with cs=e47b8ea0c818 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_13.patch with cs=95df6a4cce66 Ok.
/tmp/newpatches/hg_hvr-1600-alsa-2_14.patch with cs=355c08546c21 Ok.
Diffstat of the imported series:
 linux/drivers/media/video/cx18/Kconfig   |   11 
 linux/drivers/media/video/cx18/Makefile  |2 
 linux/drivers/media/video/cx18/cx18-alsa-main.c  |  370 -
 linux/drivers/media/video/cx18/cx18-alsa-mixer.c |  191 
 linux/drivers/media/video/cx18/cx18-alsa-mixer.h |   23 
 linux/drivers/media/video/cx18/cx18-alsa-pcm.c   |  407 +-
 linux/drivers/media/video/cx18/cx18-alsa-pcm.h   |   27 
 linux/drivers/media/video/cx18/cx18-alsa.c   |  606 +++
 linux/drivers/media/video/cx18/cx18-alsa.h   |   59 +
 linux/drivers/media/video/cx18/cx18-driver.c |   44 +
 linux/drivers/media/video/cx18/cx18-driver.h |   10 
 linux/drivers/media/video/cx18/cx18-fileops.c|6 
 linux/drivers/media/video/cx18/cx18-fileops.h|3 
 linux/drivers/media/video/cx18/cx18-mailbox.c|   16 
 linux/drivers/media/video/cx18/cx18-streams.c|2 
 15 files changed, 1429 insertions(+), 348 deletions(-)
/tmp/newpatches/hg_hvr-1600-alsa-2_01.patch:
cx18-alsa: Initial non-working cx18-alsa files
ERROR: need consistent spacing around '+' (ctx:WxV)
#124: FILE: linux/drivers/media/video/cx18/cx18-alsa-mixer.c:95:
+   uinfo-value.integer.max  =  +8;
 ^

total: 1 errors, 0 warnings, 579 lines checked

/tmp/newpatches/hg_hvr-1600-alsa-2_02.patch:
cx18-alsa: Add non-working cx18-alsa-pcm.[ch] files to avoid data loss

/tmp/newpatches/hg_hvr-1600-alsa-2_04.patch:
cx18: make it so cx18-alsa-main.c compiles
WARNING: line over 80 characters
#44: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:44:
+#define CX18_DEBUG_ALSA_INFO(fmt, arg...) printk(KERN_INFO %s:  fmt, 
cx18-alsa, ## arg)

WARNING: printk() should include KERN_ facility level
#89: FILE: linux/drivers/media/video/cx18/cx18-alsa-main.c:254:
+   printk(cx18-alsa: drv was null\n);

total: 0 errors, 2 warnings, 74 lines checked

/tmp/newpatches/hg_hvr-1600-alsa-2_06.patch:
cx18: overhaul ALSA PCM device handling so it works
WARNING: externs should be avoided in .c files
#41: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:40:
+extern int cx18_alsa_debug;

WARNING: externs should be avoided in .c files
#50: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:49:
+void cx18_alsa_announce_pcm_data(struct snd_cx18_card *cxsc, u8 *pcm_data,

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#53: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:52:
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#162: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:164:
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the version 
to which it is merged
#169: FILE: linux/drivers/media/video/cx18/cx18-alsa-pcm.c:171:
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 16)

WARNING: LINUX_VERSION_CODE should be avoided, code should be for the 

[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

2009-12-14 Thread Jean-Francois Moine
Hi Mauro,

Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb

for the following changeset:

01/01: gspca - include: Fix compile errors with kernels  2.6.25.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=7f4a47d55f36


 linux/drivers/media/video/gspca/gspca.h   |1 +
 linux/drivers/media/video/gspca/sn9c20x.c |1 -
 linux/drivers/media/video/gspca/stv06xx/stv06xx.h |1 -
 v4l/compat.h  |4 
 4 files changed, 5 insertions(+), 2 deletions(-)

Thanks.

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


Re: [PULL] http://www.kernellabs.com/hg/~dheitmueller/hvr-1600-alsa-2

2009-12-14 Thread Devin Heitmueller
On Mon, Dec 14, 2009 at 11:19 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
 Em Mon, 14 Dec 2009 11:10:50 -0500
 Devin Heitmueller dheitmuel...@kernellabs.com escreveu:

 On Mon, Dec 14, 2009 at 11:09 AM, Mauro Carvalho Chehab
 mche...@infradead.org wrote:
  I can't pull. Your site is not responding.
 
  Hmm... it seems a temporary failure. It is working now.

 That is strange (works fine from here).  You reported a similar issue
 trying to pull one of Michael Krufky's trees last week.  I will have
 to keep an eye on it.

 Yep.

 Btw, there are a few CodingStyle issues. Please send later a patch fixing it.

No problem.  I will take care of these tonight (some of them are
unrelated to my changes but happened to appear in the diff so they got
flagged).

Also, I am tempted to set the cx18 alsa driver to only work for
kernels  2.6.25, so that I don't need any of the PCM lock changes,
which are totally unvalidated and not needed by the customer.

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


[PATCH -next] radio/si470x: #include sched.h

2009-12-14 Thread Randy Dunlap
From: Randy Dunlap randy.dun...@oracle.com

Driver needs to #include sched.h:

drivers/media/radio/si470x/radio-si470x-common.c:452: error: 
'TASK_INTERRUPTIBLE' undeclared (first use in this function)
drivers/media/radio/si470x/radio-si470x-common.c:452: error: implicit 
declaration of function 'signal_pending'
drivers/media/radio/si470x/radio-si470x-common.c:452: error: implicit 
declaration of function 'schedule'

Signed-off-by: Randy Dunlap randy.dun...@oracle.com
---
 drivers/media/radio/si470x/radio-si470x.h |1 +
 1 file changed, 1 insertion(+)

--- linux-next-20091214.orig/drivers/media/radio/si470x/radio-si470x.h
+++ linux-next-20091214/drivers/media/radio/si470x/radio-si470x.h
@@ -29,6 +29,7 @@
 #include linux/kernel.h
 #include linux/module.h
 #include linux/init.h
+#include linux/sched.h
 #include linux/slab.h
 #include linux/smp_lock.h
 #include linux/input.h
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


problems compiling webcam driver

2009-12-14 Thread Nicolau Werneck
Hello. I have modified the t613 driver to support a new sensor (code
0x0802), and I am now trying to prepare a patch to submit.

The problem is that now that I started to work with the driver again,
I started to get this error message... Does anybody know what is this
about? I already tried to switch from the 2.6.31 kernel to the 2.6.32,
but the same happened.


[ 1524.864013] usb 6-2: new full speed USB device using uhci_hcd and address 3
[ 1525.026046] usb 6-2: New USB device found, idVendor=17a1, idProduct=0128
[ 1525.026049] usb 6-2: New USB device strings: Mfr=32, Product=38, 
SerialNumber=0
[ 1525.026052] usb 6-2: Product: USB2.0 JPEG WebCam
[ 1525.026054] usb 6-2: Manufacturer: TASCORP
[ 1525.026131] usb 6-2: configuration #1 chosen from 1 choice
[ 1525.072916] gspca_main: disagrees about version of symbol video_devdata
[ 1525.072918] gspca_main: Unknown symbol video_devdata
[ 1525.073060] gspca_main: disagrees about version of symbol 
video_unregister_device
[ 1525.073062] gspca_main: Unknown symbol video_unregister_device
[ 1525.073118] gspca_main: disagrees about version of symbol 
video_register_device
[ 1525.073119] gspca_main: Unknown symbol video_register_device
[ 1525.073649] gspca_t613: Unknown symbol gspca_frame_add
[ 1525.073731] gspca_t613: Unknown symbol gspca_debug
[ 1525.073878] gspca_t613: Unknown symbol gspca_disconnect
[ 1525.073931] gspca_t613: Unknown symbol gspca_resume
[ 1525.073985] gspca_t613: Unknown symbol gspca_dev_probe
[ 1525.074038] gspca_t613: Unknown symbol gspca_suspend


see you,
  ++nicolau

-- 
Nicolau Werneck nwern...@gmail.com  1AAB 4050 1999 BDFF 4862
http://www.lti.pcs.usp.br/~nwerneck   4A33 D2B5 648B 4789 0327
Linux user #460716

--
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-14 Thread Mauro Carvalho Chehab
Hi Jon,

You probably lost my feedback.

I've added some time ago a videobuf description at 
Documentation/video4linux/v4l2-framework.txt.

It is probably better to have it as a separate document like what you've 
proposed,
so, could you please drop the duplicated information that is there and move any
missing info that might not be on your new doc?

Thanks,
Mauro.

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

Re: problems compiling webcam driver

2009-12-14 Thread Paulo Assis
Hi,
You have to unload the all the old modules before loading the new ones:
http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers#First_Use:_Out_with_the_Old.2C_In_with_the_New

otherwise you will get that type of errors.

Regards,
Paulo

2009/12/14 Nicolau Werneck nwern...@gmail.com:
 Hello. I have modified the t613 driver to support a new sensor (code
 0x0802), and I am now trying to prepare a patch to submit.

 The problem is that now that I started to work with the driver again,
 I started to get this error message... Does anybody know what is this
 about? I already tried to switch from the 2.6.31 kernel to the 2.6.32,
 but the same happened.


 [ 1524.864013] usb 6-2: new full speed USB device using uhci_hcd and address 3
 [ 1525.026046] usb 6-2: New USB device found, idVendor=17a1, idProduct=0128
 [ 1525.026049] usb 6-2: New USB device strings: Mfr=32, Product=38, 
 SerialNumber=0
 [ 1525.026052] usb 6-2: Product: USB2.0 JPEG WebCam
 [ 1525.026054] usb 6-2: Manufacturer: TASCORP
 [ 1525.026131] usb 6-2: configuration #1 chosen from 1 choice
 [ 1525.072916] gspca_main: disagrees about version of symbol video_devdata
 [ 1525.072918] gspca_main: Unknown symbol video_devdata
 [ 1525.073060] gspca_main: disagrees about version of symbol 
 video_unregister_device
 [ 1525.073062] gspca_main: Unknown symbol video_unregister_device
 [ 1525.073118] gspca_main: disagrees about version of symbol 
 video_register_device
 [ 1525.073119] gspca_main: Unknown symbol video_register_device
 [ 1525.073649] gspca_t613: Unknown symbol gspca_frame_add
 [ 1525.073731] gspca_t613: Unknown symbol gspca_debug
 [ 1525.073878] gspca_t613: Unknown symbol gspca_disconnect
 [ 1525.073931] gspca_t613: Unknown symbol gspca_resume
 [ 1525.073985] gspca_t613: Unknown symbol gspca_dev_probe
 [ 1525.074038] gspca_t613: Unknown symbol gspca_suspend


 see you,
  ++nicolau

 --
 Nicolau Werneck nwern...@gmail.com          1AAB 4050 1999 BDFF 4862
 http://www.lti.pcs.usp.br/~nwerneck           4A33 D2B5 648B 4789 0327
 Linux user #460716

 --
 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: problems compiling webcam driver

2009-12-14 Thread leandro Costantino
Check that videodev.ko is the last one.
Are you compiling vanilla gspca drivers from the kernel? or the
mercuarial version?

On Mon, Dec 14, 2009 at 2:17 PM, Nicolau Werneck nwern...@gmail.com wrote:
 Hello. I have modified the t613 driver to support a new sensor (code
 0x0802), and I am now trying to prepare a patch to submit.

 The problem is that now that I started to work with the driver again,
 I started to get this error message... Does anybody know what is this
 about? I already tried to switch from the 2.6.31 kernel to the 2.6.32,
 but the same happened.


 [ 1524.864013] usb 6-2: new full speed USB device using uhci_hcd and address 3
 [ 1525.026046] usb 6-2: New USB device found, idVendor=17a1, idProduct=0128
 [ 1525.026049] usb 6-2: New USB device strings: Mfr=32, Product=38, 
 SerialNumber=0
 [ 1525.026052] usb 6-2: Product: USB2.0 JPEG WebCam
 [ 1525.026054] usb 6-2: Manufacturer: TASCORP
 [ 1525.026131] usb 6-2: configuration #1 chosen from 1 choice
 [ 1525.072916] gspca_main: disagrees about version of symbol video_devdata
 [ 1525.072918] gspca_main: Unknown symbol video_devdata
 [ 1525.073060] gspca_main: disagrees about version of symbol 
 video_unregister_device
 [ 1525.073062] gspca_main: Unknown symbol video_unregister_device
 [ 1525.073118] gspca_main: disagrees about version of symbol 
 video_register_device
 [ 1525.073119] gspca_main: Unknown symbol video_register_device
 [ 1525.073649] gspca_t613: Unknown symbol gspca_frame_add
 [ 1525.073731] gspca_t613: Unknown symbol gspca_debug
 [ 1525.073878] gspca_t613: Unknown symbol gspca_disconnect
 [ 1525.073931] gspca_t613: Unknown symbol gspca_resume
 [ 1525.073985] gspca_t613: Unknown symbol gspca_dev_probe
 [ 1525.074038] gspca_t613: Unknown symbol gspca_suspend


 see you,
  ++nicolau

 --
 Nicolau Werneck nwern...@gmail.com          1AAB 4050 1999 BDFF 4862
 http://www.lti.pcs.usp.br/~nwerneck           4A33 D2B5 648B 4789 0327
 Linux user #460716

 --
 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: [PATCH, RFC] Document the videobuf layer

2009-12-14 Thread Jonathan Corbet
On Mon, 14 Dec 2009 15:36:08 -0200
Mauro Carvalho Chehab mche...@infradead.org wrote:

 It is probably better to have it as a separate document like what you've 
 proposed,
 so, could you please drop the duplicated information that is there and move 
 any
 missing info that might not be on your new doc?

Yes, I can certainly do that.  Will prepare a new patch, but it might
take a day or two.

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


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

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

Results of the daily build of v4l-dvb:

date:Mon Dec 14 19:00:07 CET 2009
path:http://www.linuxtv.org/hg/v4l-dvb
changeset:   13690:2dfce98fc6dc
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-armv5: OK
linux-2.6.32-armv5-davinci: WARNINGS
linux-2.6.30-armv5-ixp: WARNINGS
linux-2.6.31-armv5-ixp: WARNINGS
linux-2.6.32-armv5-ixp: WARNINGS
linux-2.6.30-armv5-omap2: WARNINGS
linux-2.6.31-armv5-omap2: WARNINGS
linux-2.6.32-armv5-omap2: WARNINGS
linux-2.6.22.19-i686: ERRORS
linux-2.6.23.12-i686: ERRORS
linux-2.6.24.7-i686: ERRORS
linux-2.6.25.11-i686: WARNINGS
linux-2.6.26-i686: WARNINGS
linux-2.6.27-i686: WARNINGS
linux-2.6.28-i686: WARNINGS
linux-2.6.29.1-i686: WARNINGS
linux-2.6.30-i686: WARNINGS
linux-2.6.31-i686: WARNINGS
linux-2.6.32-i686: WARNINGS
linux-2.6.30-m32r: OK
linux-2.6.31-m32r: OK
linux-2.6.32-m32r: OK
linux-2.6.30-mips: WARNINGS
linux-2.6.31-mips: WARNINGS
linux-2.6.32-mips: WARNINGS
linux-2.6.30-powerpc64: WARNINGS
linux-2.6.31-powerpc64: OK
linux-2.6.32-powerpc64: WARNINGS
linux-2.6.22.19-x86_64: ERRORS
linux-2.6.23.12-x86_64: ERRORS
linux-2.6.24.7-x86_64: ERRORS
linux-2.6.25.11-x86_64: WARNINGS
linux-2.6.26-x86_64: WARNINGS
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: WARNINGS
linux-2.6.32-x86_64: WARNINGS
spec: OK
sparse (linux-2.6.32): ERRORS
linux-2.6.16.61-i686: ERRORS
linux-2.6.17.14-i686: ERRORS
linux-2.6.18.8-i686: ERRORS
linux-2.6.19.5-i686: ERRORS
linux-2.6.20.21-i686: ERRORS
linux-2.6.21.7-i686: ERRORS
linux-2.6.16.61-x86_64: ERRORS
linux-2.6.17.14-x86_64: ERRORS
linux-2.6.18.8-x86_64: ERRORS
linux-2.6.19.5-x86_64: ERRORS
linux-2.6.20.21-x86_64: ERRORS
linux-2.6.21.7-x86_64: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

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

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


[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/

2009-12-14 Thread Jean-Francois Moine
Hi Mauro,

Forgive about the previous pull request and 

please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb

for the following 3 changesets:

01/03: gspca - include: Fix compile errors with kernels  2.6.25.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=696f668232b3

02/03: gspca - sunplus: Add webcam 052b:1507.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=40f9ad7c1cec

03/03: gspca - main: Set the current frame pointer when first qbuf.
http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=bdc9ee6ae5f2


 Documentation/video4linux/gspca.txt |1 +
 drivers/media/video/gspca/gspca.c   |2 ++
 drivers/media/video/gspca/gspca.h   |1 +
 drivers/media/video/gspca/sn9c20x.c |1 -
 drivers/media/video/gspca/stv06xx/stv06xx.h |1 -
 drivers/media/video/gspca/sunplus.c |1 +
 6 files changed, 5 insertions(+), 2 deletions(-)

Thanks.

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


scan/scan-s2 doesn't tune, but dvbtune does?

2009-12-14 Thread Michael Akey
I can't get the scan/scan-s2 utilities to lock any transponders 
(DVB-S).  My test satellite is AMC1 103W, the Pentagon Channel tp. This 
is probably some simple user error on my part, but I can't figure it 
out.  I have a Corotor II with polarity changed via serial command to an 
external IRD.  C/Ku is switched by 22KHz tone, voltage is always 18V.  
Ku is with tone off, C with tone on.  Speaking of which, is there a way 
to manually set the tone from the arguments on the scan utilities?


Here's what I've tried and the results:

$ ./scan-s2 -a 0 -v -o zap -l 10750 INIT
API major 5, minor 0
scanning INIT
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
initial transponder DVB-S  1210 H 2000 AUTO AUTO AUTO
initial transponder DVB-S2 1210 H 2000 AUTO AUTO AUTO
-- Using DVB-S
 tune to: 12100:h:0:2
DVB-S IF freq is 135
 tuning status == 0x03
 tuning status == 0x01
 tuning status == 0x03
 tuning status == 0x01
 tuning status == 0x03
 tuning status == 0x00
 tuning status == 0x01
 tuning status == 0x03
 tuning status == 0x00
 tuning status == 0x00
WARNING:  tuning failed!!!
 tune to: 12100:h:0:2 (tuning failed)
DVB-S IF freq is 135
 tuning status == 0x03
 tuning status == 0x01
 tuning status == 0x00
 tuning status == 0x00
...snip...

Same thing happens if I use just 'scan' and not 'scan-s2.'

If I use dvbtune, it works though..

$ dvbtune -f 135 -p H -s 2 -c 0 -tone 0 -m
Using DVB card Conexant CX24116/CX24118
tuning DVB-S to L-Band:0, Pol:H Srate=2000, 22kHz=off
polling
Getting frontend event
FE_STATUS:
polling
Getting frontend event
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI 
FE_HAS_SYNC

Bit error rate: 0
Signal strength: 51648
SNR: 26215
FE_STATUS: FE_HAS_SIGNAL FE_HAS_LOCK FE_HAS_CARRIER FE_HAS_VITERBI 
FE_HAS_SYNC

Signal=51648, Verror=0, SNR=26215dB, BlockErrors=0, (S|L|C|V|SY|)
Signal=51776, Verror=0, SNR=26624dB, BlockErrors=0, (S|L|C|V|SY|)

The tuning file 'INIT' contains only the following line:
S 1210 H 2000 AUTO

I'm using v4l-dvb drivers from the main repo as of about a week ago.  I 
am running kernel 2.6.32 on Debian testing.  Any help is appreciated 
..and hopefully it's just a simple flub on my part!


--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] soc-camera and mediabus

2009-12-14 Thread Guennadi Liakhovetski
On Mon, 14 Dec 2009, Jonathan Cameron wrote:

 Hi All,
 
  3) it would be interesting to patch the other sensor drivers to be 
  compatible
 with soc_camera (mt9v011/ov7670);
  
  Well, this could be done, yes, but does it make sense to do this blindly 
  without any hardware to test? I would rather add such conversions on a 
  one-by-one basis as need arises.
  
 I'm working on the ov7670. I've added the media bus stuff to what I've
 previously posted but I haven't tested as yet.  For reference, a quick and 
 dirty
 cut of the patch is below.  Some thought is needed on how to deal with the 
 sections
 that currently need to be different for the soc-camera and non soc camera 
 uses.
 (mainly the registration code in probe).

Look at my patch for mt9t031. First you do not have to fail if 
client-dev.platform_data == NULL. You have to look at the bridge driver, 
that's currently working with ov7670. If it is not setting platform_data, 
you can use it to detect whether you're in soc-camera environment or not. 
Otherwise, if the bridge driver were also using that pointer, we would 
have to come up with a ov7670-specific struct to be linked from that 
pointer. I was actually thinking about a way to pass soc-camera data to 
client drivers in a way, that would not imped non soc-camera use. So, how 
about:


I soc-camera environment

1. platform defines a

static struct ov7670_platform_data ov7670 = {
.link = ov7670_link,
};

2. and a

static struct soc_camera_link ov7670_link = {
.client_data = ov7670,
};

3. soc-camera core gets ov7670_link in its probe, same as this is done 
now, then it does

icl-icd = icd;
icl-board_info-platform_data = icl-client_data;

subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap,
icl-module_name, icl-board_info, NULL);

4. ov7670 probe is called with client platform data pointing to its own 
data:

static int ov7670_probe(struct i2c_client *client,
const struct i2c_device_id *did)
{
struct ov7670_platform_data *pdata = client-dev.platform_data;
struct soc_camera_link *icl = pdata-link;
struct soc_camera_device *icd;

if (icl)
icd = icl-icd;


II Non soc-camera environment

1. the bridge driver fills in sensor data and does

struct ov7670_platform_data *ov7670_pdata = kzalloc(sizeof(*pdata));

ov7670_pdata-... = ...;
board_info-platform_data = ov7670_pdata;

subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adap,
module_name, board_info, NULL);

2. ov7670_probe() gets called and finds its data as above, but without an 
soc-camera link this time.


The advantage of the above is, that each client driver is free to define 
its own platform data struct, and for soc-camera it only has to provide 
one pointer in it. The ugly side is the cross-referencing between I.1. and 
I.2. above.

Alternatively we could agree, that all client drivers get in their i2c 
client platform data a standard struct with only pointers in it to client 
data and to various bridging models:

struct v4l2_client {
void *client;
struct soc_camera_link *icl;
struct int_device_link *int;
...
};

or a bit more hidden

struct v4l2_client {
void *client;
void *bridge_data;
enum V4L2_BRIDGE_TYPE bridge_type;
};

 On another note, does anyone have an objection to making the set_bus_param
 function optional?   At the moment we are adding null functions for those
 devices that can't actually change anything which seems a little pointless.

Yes, it can.

 
 Jonathan
 
 
 diff --git a/drivers/media/video/ov7670.c b/drivers/media/video/ov7670.c
 index 0e2184e..e57c3b5 100644
 --- a/drivers/media/video/ov7670.c
 +++ b/drivers/media/video/ov7670.c
 @@ -18,6 +18,7 @@
  #include media/v4l2-device.h
  #include media/v4l2-chip-ident.h
  #include media/v4l2-i2c-drv.h
 +#include media/soc_camera.h
  
  
  MODULE_AUTHOR(Jonathan Corbet cor...@lwn.net);
 @@ -545,7 +546,7 @@ static struct ov7670_format_struct {
   .bpp= 1
   },
  };
 -#define N_OV7670_FMTS ARRAY_SIZE(ov7670_formats)
 +
  
  
  /*
 @@ -668,52 +669,37 @@ static int ov7670_set_hw(struct v4l2_subdev *sd, int 
 hstart, int hstop,
   return ret;
  }
  
 +static enum v4l2_mbus_pixelcode ov7670_codes[] = {
 + V4L2_MBUS_FMT_YUYV8_2X8,
 + V4L2_MBUS_FMT_RGB565_2X8_LE,
 +};
  
 -static int ov7670_enum_fmt(struct v4l2_subdev *sd, struct v4l2_fmtdesc *fmt)
 +static int ov7670_enum_fmt(struct v4l2_subdev *sd, int index, enum 
 v4l2_mbus_pixelcode *code)
  {
 - struct ov7670_format_struct *ofmt;
 -
 - if (fmt-index = N_OV7670_FMTS)
 + if (index = ARRAY_SIZE(ov7670_codes))
   return -EINVAL;
  
 - ofmt = ov7670_formats + fmt-index;
 - fmt-flags = 0;
 - strcpy(fmt-description, ofmt-desc);
 - fmt-pixelformat = ofmt-pixelformat;
 + 

budget_ci: BUG: unable to handle kernel paging request

2009-12-14 Thread Oliver Wagner
Hi,

a current build of http://mercurial.intuxication.org/hg/s2-liplianin
(changeset 13860:1944670e9fbe) yields a kernel paging error when
inserting budget_ci on a Ubuntu 9.10 system (2.6.31-16) with three
S2-3200 and one Tevii 470 cards:

Dec 14 23:35:54 tvserver kernel: [0.00] Initializing cgroup subsys 
cpuset
Dec 14 23:35:54 tvserver kernel: [0.00] Initializing cgroup subsys cpu
Dec 14 23:35:54 tvserver kernel: [0.00] Linux version 2.6.31-16-generic 
(bui...@vernadsky) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #52-Ubuntu SMP 
Thu Dec 3 22:00:22 UTC 2009 (Ubuntu 2.6.31-16.52-generic)
Dec 14 23:35:54 tvserver kernel: [0.00] KERNEL supported cpus:
Dec 14 23:35:54 tvserver kernel: [0.00]   Intel GenuineIntel
Dec 14 23:35:54 tvserver kernel: [0.00]   AMD AuthenticAMD
Dec 14 23:35:54 tvserver kernel: [0.00]   NSC Geode by NSC
Dec 14 23:35:54 tvserver kernel: [0.00]   Cyrix CyrixInstead
Dec 14 23:35:54 tvserver kernel: [0.00]   Centaur CentaurHauls
Dec 14 23:35:54 tvserver kernel: [0.00]   Transmeta GenuineTMx86
Dec 14 23:35:54 tvserver kernel: [0.00]   Transmeta TransmetaCPU
Dec 14 23:35:54 tvserver kernel: [0.00]   UMC UMC UMC UMC
Dec 14 23:35:54 tvserver kernel: [0.00] BIOS-provided physical RAM map:
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820:  - 
0009fc00 (usable)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: 0009fc00 - 
000a (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: 000e7000 - 
0010 (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: 0010 - 
7ffb (usable)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: 7ffb - 
7ffc (ACPI data)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: 7ffc - 
7fff (ACPI NVS)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: 7fff - 
8000 (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: fec0 - 
fec01000 (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: fee0 - 
fef0 (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  BIOS-e820: fff8 - 
0001 (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00] DMI present.
Dec 14 23:35:54 tvserver kernel: [0.00] AMI BIOS detected: BIOS may 
corrupt low RAM, working around it.
Dec 14 23:35:54 tvserver kernel: [0.00] e820 update range: 
 - 0001 (usable) == (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00] last_pfn = 0x7ffb0 max_arch_pfn 
= 0x10
Dec 14 23:35:54 tvserver kernel: [0.00] MTRR default type: uncachable
Dec 14 23:35:54 tvserver kernel: [0.00] MTRR fixed ranges enabled:
Dec 14 23:35:54 tvserver kernel: [0.00]   0-9 write-back
Dec 14 23:35:54 tvserver kernel: [0.00]   A-E uncachable
Dec 14 23:35:54 tvserver kernel: [0.00]   F-F write-protect
Dec 14 23:35:54 tvserver kernel: [0.00] MTRR variable ranges enabled:
Dec 14 23:35:54 tvserver kernel: [0.00]   0 base 00 mask 
FF8000 write-back
Dec 14 23:35:54 tvserver kernel: [0.00]   1 disabled
Dec 14 23:35:54 tvserver kernel: [0.00]   2 disabled
Dec 14 23:35:54 tvserver kernel: [0.00]   3 disabled
Dec 14 23:35:54 tvserver kernel: [0.00]   4 disabled
Dec 14 23:35:54 tvserver kernel: [0.00]   5 disabled
Dec 14 23:35:54 tvserver kernel: [0.00]   6 disabled
Dec 14 23:35:54 tvserver kernel: [0.00]   7 disabled
Dec 14 23:35:54 tvserver kernel: [0.00] x86 PAT enabled: cpu 0, old 
0x7040600070406, new 0x7010600070106
Dec 14 23:35:54 tvserver kernel: [0.00] Scanning 0 areas for low memory 
corruption
Dec 14 23:35:54 tvserver kernel: [0.00] modified physical RAM map:
Dec 14 23:35:54 tvserver kernel: [0.00]  modified:  - 
0001 (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  modified: 0001 - 
0009fc00 (usable)
Dec 14 23:35:54 tvserver kernel: [0.00]  modified: 0009fc00 - 
000a (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  modified: 000e7000 - 
0010 (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  modified: 0010 - 
7ffb (usable)
Dec 14 23:35:54 tvserver kernel: [0.00]  modified: 7ffb - 
7ffc (ACPI data)
Dec 14 23:35:54 tvserver kernel: [0.00]  modified: 7ffc - 
7fff (ACPI NVS)
Dec 14 23:35:54 tvserver kernel: [0.00]  modified: 7fff - 
8000 (reserved)
Dec 14 23:35:54 tvserver kernel: [0.00]  modified: fec0 - 

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

2009-12-14 Thread Igor M. Liplianin
Mauro,

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

for the following changeset:

01/01: Add Prof 7500 DVB-S2 USB card
http://mercurial.intuxication.org/hg/v4l-dvb-commits?cmd=changeset;node=a05b1d723aac


 dvb-usb/dw2102.c |   94 ++-
 frontends/stv0900.h  |2 +
 frontends/stv0900_core.c |   87 +++
 frontends/stv0900_priv.h |   11 +
 frontends/stv0900_reg.h  |6 +++
 frontends/stv0900_sw.c   |   44 ++
 6 files changed, 226 insertions(+), 18 deletions(-)

Thanks,
Igor


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


PATCH- gspca: added chipset revision sensor

2009-12-14 Thread Luis Maia

Hello,

Added extra chipset revision (sensor) to fix camera zc0301 with  ID: 
0ac8:301b .

Since i own one of this cameras fixed and tested it.

Best Regards,
Luis Maia

-

diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c 
linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
--- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c2009-12-14 
17:47:25.0 +
+++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c2009-12-15 
02:42:13.0 +

@@ -6868,6 +6868,7 @@
{0x8001, 0x13},
{0x8000, 0x14},/* CS2102K */
{0x8400, 0x15},/* TAS5130K */
+{0xe400, 0x15},
};

static int vga_3wr_probe(struct gspca_dev *gspca_dev)
@@ -7634,7 +7635,7 @@
{USB_DEVICE(0x0698, 0x2003)},
{USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
{USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
-{USB_DEVICE(0x0ac8, 0x301b)},
+{USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
{USB_DEVICE(0x0ac8, 0x303b)},
{USB_DEVICE(0x0ac8, 0x305b), .driver_info = SENSOR_TAS5130C_VF0250},
{USB_DEVICE(0x0ac8, 0x307b)},

diff -uNr linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c 
linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c
--- linux-2.6.32.1/drivers/media/video/gspca/zc3xx.c2009-12-14 
17:47:25.0 +
+++ linux-2.6.32.1-patch/drivers/media/video/gspca/zc3xx.c  2009-12-15 
02:42:13.0 +
@@ -6868,6 +6868,7 @@
{0x8001, 0x13},
{0x8000, 0x14}, /* CS2102K */
{0x8400, 0x15}, /* TAS5130K */
+   {0xe400, 0x15},
 };
 
 static int vga_3wr_probe(struct gspca_dev *gspca_dev)
@@ -7634,7 +7635,7 @@
{USB_DEVICE(0x0698, 0x2003)},
{USB_DEVICE(0x0ac8, 0x0301), .driver_info = SENSOR_PAS106},
{USB_DEVICE(0x0ac8, 0x0302), .driver_info = SENSOR_PAS106},
-   {USB_DEVICE(0x0ac8, 0x301b)},
+   {USB_DEVICE(0x0ac8, 0x301b), .driver_info = SENSOR_PB0330},
{USB_DEVICE(0x0ac8, 0x303b)},
{USB_DEVICE(0x0ac8, 0x305b), .driver_info = SENSOR_TAS5130C_VF0250},
{USB_DEVICE(0x0ac8, 0x307b)},



Re: [PULL] soc-camera and mediabus

2009-12-14 Thread Hans Verkuil
On Monday 14 December 2009 21:41:20 Guennadi Liakhovetski wrote:
 On Mon, 14 Dec 2009, Jonathan Cameron wrote:
 
  Hi All,
  
   3) it would be interesting to patch the other sensor drivers to be 
   compatible
  with soc_camera (mt9v011/ov7670);
   
   Well, this could be done, yes, but does it make sense to do this blindly 
   without any hardware to test? I would rather add such conversions on a 
   one-by-one basis as need arises.
   
  I'm working on the ov7670. I've added the media bus stuff to what I've
  previously posted but I haven't tested as yet.  For reference, a quick and 
  dirty
  cut of the patch is below.  Some thought is needed on how to deal with the 
  sections
  that currently need to be different for the soc-camera and non soc camera 
  uses.
  (mainly the registration code in probe).
 
 Look at my patch for mt9t031. First you do not have to fail if 
 client-dev.platform_data == NULL. You have to look at the bridge driver, 
 that's currently working with ov7670. If it is not setting platform_data, 
 you can use it to detect whether you're in soc-camera environment or not. 
 Otherwise, if the bridge driver were also using that pointer, we would 
 have to come up with a ov7670-specific struct to be linked from that 
 pointer. I was actually thinking about a way to pass soc-camera data to 
 client drivers in a way, that would not imped non soc-camera use. So, how 
 about:
 
 
   I soc-camera environment
 
 1. platform defines a
 
 static struct ov7670_platform_data ov7670 = {
   .link = ov7670_link,
 };
 
 2. and a
 
 static struct soc_camera_link ov7670_link = {
   .client_data = ov7670,
 };
 
 3. soc-camera core gets ov7670_link in its probe, same as this is done 
 now, then it does
 
   icl-icd = icd;
   icl-board_info-platform_data = icl-client_data;
 
   subdev = v4l2_i2c_new_subdev_board(ici-v4l2_dev, adap,
   icl-module_name, icl-board_info, NULL);
 
 4. ov7670 probe is called with client platform data pointing to its own 
 data:
 
 static int ov7670_probe(struct i2c_client *client,
   const struct i2c_device_id *did)
 {
   struct ov7670_platform_data *pdata = client-dev.platform_data;
   struct soc_camera_link *icl = pdata-link;
   struct soc_camera_device *icd;
 
   if (icl)
   icd = icl-icd;
 
 
   II Non soc-camera environment
 
 1. the bridge driver fills in sensor data and does
 
   struct ov7670_platform_data *ov7670_pdata = kzalloc(sizeof(*pdata));
 
   ov7670_pdata-... = ...;
   board_info-platform_data = ov7670_pdata;
 
   subdev = v4l2_i2c_new_subdev_board(v4l2_dev, adap,
   module_name, board_info, NULL);
 
 2. ov7670_probe() gets called and finds its data as above, but without an 
 soc-camera link this time.
 
 
 The advantage of the above is, that each client driver is free to define 
 its own platform data struct, and for soc-camera it only has to provide 
 one pointer in it. The ugly side is the cross-referencing between I.1. and 
 I.2. above.
 
 Alternatively we could agree, that all client drivers get in their i2c 
 client platform data a standard struct with only pointers in it to client 
 data and to various bridging models:
 
 struct v4l2_client {
   void *client;
   struct soc_camera_link *icl;
   struct int_device_link *int;
   ...
 };
 
 or a bit more hidden
 
 struct v4l2_client {
   void *client;
   void *bridge_data;
   enum V4L2_BRIDGE_TYPE bridge_type;
 };

Before this goes too far let me just say that I will NAK any attempt in this
direction. Subdevice drivers must eventually be completely independent from
bridge driver. The same driver should work out of the box for soc-camera,
gspca, omap3, davinci, saa7134 and whatever other bridge driver is out there.

Having bridge-specific code in a sub-device driver will be a disaster in the
long run. Well, we've seen what happens when you do it that way.

As far as I know the only soc-dependency left now is for bus configuration.
Proposals were made some time ago and we should pick that up again and remove
that last dependency.

Regards,

Hans

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


Re: [PATCH - v1 2/6] V4L - vpfe capture - Adding DM365 ISIF driver - header files

2009-12-14 Thread Hans Verkuil
Hi Murali,

Here is the first review. I'll try to review all the patches from this patch 
series
this week. FYI, patch 1/6 is fine.

On Thursday 10 December 2009 18:00:25 m-kariche...@ti.com wrote:
 From: Muralidharan Karicheri m-kariche...@ti.com
 
 This is the header file for ISIF driver on DM365. This has comments 
 incorporated from
 initial version.
 
 ISIF driver is equivalent to CCDC driver on DM355 and DM644x. This driver is 
 tested for
 YUV capture from TVP514x driver. This patch contains the header files 
 required for
 this driver. The name of the file is changed to reflect the name of IP.
 
 Reviewed-by: Nori, Sekhar nsek...@ti.com
 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
 Applies to linux-next tree of v4l-dvb 
  drivers/media/video/davinci/isif_regs.h |  290 
  include/media/davinci/isif.h|  554 
 +++
  2 files changed, 844 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/davinci/isif_regs.h
  create mode 100644 include/media/davinci/isif.h
 

cut

 diff --git a/include/media/davinci/isif.h b/include/media/davinci/isif.h
 new file mode 100644
 index 000..b75fea7
 --- /dev/null
 +++ b/include/media/davinci/isif.h
 @@ -0,0 +1,554 @@
 +/*
 + * Copyright (C) 2008-2009 Texas Instruments Inc
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 + *
 + * isif header file
 + */
 +#ifndef _ISIF_H
 +#define _ISIF_H

Please add an empty line.

 +#include media/davinci/ccdc_types.h
 +#include media/davinci/vpfe_types.h

Ditto.

 +/* isif float type S8Q8/U8Q8 */
 +struct isif_float_8 {
 + /* 8 bit integer part */
 + __u8 integer;
 + /* 8 bit decimal part */
 + __u8 decimal;

Why __u8 instead of u8? This is a kernel-internal file, so it does not need
to use the '__' variants.

If this needs to be publicly available, then it should be in include/linux.

 +};
 +
 +/* isif float type U16Q16/S16Q16 */
 +struct isif_float_16 {
 + /* 16 bit integer part */
 + __u16 integer;
 + /* 16 bit decimal part */
 + __u16 decimal;
 +};
 +
 +/
 + *   Vertical Defect Correction parameters
 + ***/
 +/* Defect Correction (DFC) table entry */
 +struct isif_vdfc_entry {
 + /* vertical position of defect */
 + __u16 pos_vert;
 + /* horizontal position of defect */
 + __u16 pos_horz;
 + /*
 +  * Defect level of Vertical line defect position. This is subtracted
 +  * from the data at the defect position
 +  */
 + __u8 level_at_pos;
 + /*
 +  * Defect level of the pixels upper than the vertical line defect.
 +  * This is subtracted from the data
 +  */
 + __u8 level_up_pixels;
 + /*
 +  * Defect level of the pixels lower than the vertical line defect.
 +  * This is subtracted from the data
 +  */
 + __u8 level_low_pixels;
 +};
 +
 +#define ISIF_VDFC_TABLE_SIZE 8
 +struct isif_dfc {
 + /* enable vertical defect correction */
 + __u8 en;
 + /* Defect level subtraction. Just fed through if saturating */
 +#define  ISIF_VDFC_NORMAL0
 + /*
 +  * Defect level subtraction. Horizontal interpolation ((i-2)+(i+2))/2
 +  * if data saturating
 +  */
 +#define ISIF_VDFC_HORZ_INTERPOL_IF_SAT   1
 + /* Horizontal interpolation (((i-2)+(i+2))/2) */
 +#define  ISIF_VDFC_HORZ_INTERPOL 2
 + /* one of the vertical defect correction modes above */
 + __u8 corr_mode;
 + /* 0 - whole line corrected, 1 - not pixels upper than the defect */
 + __u8 corr_whole_line;
 +#define ISIF_VDFC_NO_SHIFT   0
 +#define ISIF_VDFC_SHIFT_11
 +#define ISIF_VDFC_SHIFT_22
 +#define ISIF_VDFC_SHIFT_33
 +#define ISIF_VDFC_SHIFT_44
 + /*
 +  * defect level shift value. level_at_pos, level_upper_pos,
 +  * and level_lower_pos can be shifted up by this value. Choose
 +  * one of the values above
 +  */
 + __u8 def_level_shift;
 + /* defect saturation level */
 + __u16 def_sat_level;
 + /* number of vertical defects. Max is ISIF_VDFC_TABLE_SIZE */
 + __u16 num_vdefects;
 

Re: [PATCH - v1 3/6] V4L-vpfe-capture-Adding ISIF driver for DM365 - source

2009-12-14 Thread Hans Verkuil
On Thursday 10 December 2009 18:00:26 m-kariche...@ti.com wrote:
 From: Muralidharan Karicheri m-kariche...@ti.com
 
 This is the source file for ISIF driver for DM365. This has comments 
 incorporated from
 initial version.
 
 ISIF driver is equivalent to CCDC driver on DM355 and DM644x. This driver is 
 tested for
 YUV capture from TVP514x driver. This patch contains the header files 
 required for
 this driver. The name of the file is changed to reflect the name of IP.
 
 Reviewed-by: Nori, Sekhar nsek...@ti.com
 Signed-off-by: Muralidharan Karicheri m-kariche...@ti.com
 ---
 Applies to linux-next tree of v4l-dvb 
  drivers/media/video/davinci/isif.c | 1498 
 
  1 files changed, 1498 insertions(+), 0 deletions(-)
  create mode 100644 drivers/media/video/davinci/isif.c
 
 diff --git a/drivers/media/video/davinci/isif.c 
 b/drivers/media/video/davinci/isif.c
 new file mode 100644
 index 000..916afab
 --- /dev/null
 +++ b/drivers/media/video/davinci/isif.c
 @@ -0,0 +1,1498 @@
 +/*
 + * Copyright (C) 2008-2009 Texas Instruments Inc
 + *
 + * This program is free software; you can redistribute it and/or modify
 + * it under the terms of the GNU General Public License as published by
 + * the Free Software Foundation; either version 2 of the License, or
 + * (at your option) any later version.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
 + * GNU General Public License for more details.
 + *
 + * You should have received a copy of the GNU General Public License
 + * along with this program; if not, write to the Free Software
 + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
 + *
 + * This is the isif hardware module.
 + * TODO: 1) Raw bayer parameter settings and bayer capture
 + *2) Add support for control ioctl
 + */
 +#include linux/delay.h
 +#include linux/platform_device.h
 +#include linux/uaccess.h
 +#include linux/io.h
 +#include linux/videodev2.h
 +#include linux/clk.h
 +
 +#include mach/mux.h
 +
 +#include media/davinci/isif.h
 +#include media/davinci/vpss.h
 +
 +#include isif_regs.h
 +#include ccdc_hw_device.h
 +
 +/* Defauts for module configuation paramaters */

Typos: 'Defaults', 'configuration' and 'parameters'.

BTW: Please comment somewhere what 'ISIF' stands for!

 +static struct isif_config_params_raw isif_config_defaults = {
 + .linearize = {
 + .en = 0,
 + .corr_shft = ISIF_NO_SHIFT,
 + .scale_fact = {1, 0},
 + },
 + .df_csc = {
 + .df_or_csc = 0,
 + .csc = {
 + .en = 0,
 + },
 + },
 + .dfc = {
 + .en = 0,
 + },
 + .bclamp = {
 + .en = 0,
 + },
 + .gain_offset = {
 + .gain = {
 + .r_ye = {1, 0},
 + .gr_cy = {1, 0},
 + .gb_g = {1, 0},
 + .b_mg = {1, 0},
 + },
 + },
 + .culling = {
 + .hcpat_odd = 0xff,
 + .hcpat_even = 0xff,
 + .vcpat = 0xff,
 + },
 + .compress = {
 + .alg = ISIF_ALAW,
 + },
 +};
 +
 +/* ISIF operation configuration */
 +static struct isif_oper_config {
 + struct device *dev;
 + enum vpfe_hw_if_type if_type;
 + struct isif_ycbcr_config ycbcr;
 + struct isif_params_raw bayer;
 + enum isif_data_pack data_pack;
 + /* Master clock */
 + struct clk *mclk;
 + /* ISIF base address */
 + void __iomem *base_addr;
 + /* ISIF Linear Table 0 */
 + void __iomem *linear_tbl0_addr;
 + /* ISIF Linear Table 1 */
 + void __iomem *linear_tbl1_addr;
 +} isif_cfg = {
 + .ycbcr = {
 + .pix_fmt = CCDC_PIXFMT_YCBCR_8BIT,
 + .frm_fmt = CCDC_FRMFMT_INTERLACED,
 + .win = ISIF_WIN_NTSC,
 + .fid_pol = VPFE_PINPOL_POSITIVE,
 + .vd_pol = VPFE_PINPOL_POSITIVE,
 + .hd_pol = VPFE_PINPOL_POSITIVE,
 + .pix_order = CCDC_PIXORDER_CBYCRY,
 + .buf_type = CCDC_BUFTYPE_FLD_INTERLEAVED,
 + },
 + .bayer = {
 + .pix_fmt = CCDC_PIXFMT_RAW,
 + .frm_fmt = CCDC_FRMFMT_PROGRESSIVE,
 + .win = ISIF_WIN_VGA,
 + .fid_pol = VPFE_PINPOL_POSITIVE,
 + .vd_pol = VPFE_PINPOL_POSITIVE,
 + .hd_pol = VPFE_PINPOL_POSITIVE,
 + .gain = {
 + .r_ye = {1, 0},
 + .gr_cy = {1, 0},
 + .gb_g = {1, 0},
 + .b_mg = {1, 0},
 + },
 + .cfa_pat = ISIF_CFA_PAT_MOSAIC,
 + .data_msb = ISIF_BIT_MSB_11,
 + .config_params = {
 + .data_shift = ISIF_NO_SHIFT,
 + .col_pat_field0 = {
 +