summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2009-08-18iop: downgrade maintenance statusDan Williams
iop support is in maintenance-only mode. Cc: Lennert Buytenhek <kernel@wantstofly.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2009-08-18arch/arm/plat-iop: Use DIV_ROUND_CLOSESTJulia Lawall
The kernel.h macro DIV_ROUND_CLOSEST performs the computation (x + d/2)/d but is perhaps more readable. The semantic patch that makes this change is as follows: (http://www.emn.fr/x-info/coccinelle/) // <smpl> @haskernel@ @@ #include <linux/kernel.h> @depends on haskernel@ expression x,__divisor; @@ - (((x) + ((__divisor) / 2)) / (__divisor)) + DIV_ROUND_CLOSEST(x,__divisor) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2009-08-18iop3xx: ATU and PCI memory configuration correctedAaro Koskinen
There are two 64 MB outbound memory windows at bus addresses 0x80000000..0x83ffffff and 0x84000000..0x87ffffff for PCI memory. Currently, on iop32x, only the lower window is available for allocations, limiting the available space to 64 MB. On iop33x the full 128 MB can be allocated, but the translation value is wrong for the upper window. The patch enables the full 128 MB space on iop32x and corrects the initialization of OMWTVR1. Redundant definitions are deleted. Tested using a Thecus N2100 board with a graphics adapter in the expansion slot. Both windows are in use: 00:05.0 VGA compatible controller: XGI Technology Inc. (eXtreme Graphics Innovation) Volari Z7 (prog-if 00 [VGA controller]) [...] Region 0: Memory at 80000000 (32-bit, prefetchable) [size=64M] Region 1: Memory at 84080000 (32-bit, non-prefetchable) [size=256K] Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi> Cc: Lennert Buytenhek <kernel@wantstofly.org> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2009-08-18iop33x: update defconfig (default atu to on)Dan Williams
By default the iop3xx configurations are set to boot the platforms over an nfs root configuration. Since commit c34002c1 "iop: unconditionally initialize the ATU on platforms known to be 'hosts'" this configuration also requires iop3xx_init_atu=y to be specified on the kernel command line. Signed-off-by: Dan Williams <dan.j.williams@intel.com>
2009-08-17Merge branch 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linusLinus Torvalds
* 'upstream' of git://ftp.linux-mips.org/pub/scm/upstream-linus: MIPS: Fix HPAGE_SIZE redefinition
2009-08-17Merge branch 'for-linus' of git://oss.sgi.com/xfs/xfsLinus Torvalds
* 'for-linus' of git://oss.sgi.com/xfs/xfs: xfs: fix locking in xfs_iget_cache_hit
2009-08-17Merge branch 'for-linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6 * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6: security: define round_hint_to_min in !CONFIG_SECURITY Security/SELinux: seperate lsm specific mmap_min_addr SELinux: call cap_file_mmap in selinux_file_mmap Capabilities: move cap_file_mmap to commoncap.c
2009-08-17inotify: start watch descriptor count at 1Eric Paris
The inotify_add_watch man page specifies that inotify_add_watch() will return a non-negative integer. However, historically the inotify watches started at 1, not at 0. Turns out that the inotifywait program provided by the inotify-tools package doesn't properly handle a 0 watch descriptor. In 7e790dd5 we changed from starting at 1 to starting at 0. This patch starts at 1, just like in previous kernels, but also just like in previous kernels it's possible for it to wrap back to 0. This preserves the kernel functionality exactly like it was before the patch (neither method broke the spec) Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-17inotify: tail drop inotify q_overflow eventsEric Paris
In f44aebcc the tail drop logic of events with no file backing (q_overflow and in_ignored) was reversed so IN_IGNORED events would never be tail dropped. This now means that Q_OVERFLOW events are NOT tail dropped. The fix is to not tail drop IN_IGNORED, but to tail drop Q_OVERFLOW. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-17notify: unused event private raceEric Paris
inotify decides if private data it passed to get added to an event was used by checking list_empty(). But it's possible that the event may have been dequeued and the private event removed so it would look empty. The fix is to use the return code from fsnotify_add_notify_event rather than looking at the list. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-17Merge master.kernel.org:/home/rmk/linux-2.6-armLinus Torvalds
* master.kernel.org:/home/rmk/linux-2.6-arm: (37 commits) ARM: 5673/1: U300 fix initsection compile warning ARM: Fix broken highmem support mx31moboard: invert sdhc ro signal sense ARM: S3C24XX: Fix clkout mpx error ARM: S3C64XX: serial: Fix a typo in Kconfig IXP4xx: Fix IO_SPACE_LIMIT for 2.6.31-rc core PCI changes OMAP3: RX51: Updated rx51_defconfig OMAP2/3: mmc-twl4030: Free up MMC regulators while cleaning up OMAP3: RX51: Define TWL4030 USB transceiver in board file OMAP3: Overo: Fix smsc911x platform device resource value OMAP3: Fix omap3 sram virtual addres overlap vmalloc space after increasing vmalloc size OMAP2/3: DMA errata correction OMAP: Fix testing of cpu defines for mach-omap1 OMAP3: Overo: add missing pen-down GPIO definition OMAP: GPIO: clear/restore level/edge detect settings on mask/unmask OMAP3: PM: Fix wrong sequence in suspend. OMAP: PM: CPUfreq: obey min/max settings of policy OMAP2/3/4: UART: allow in-order port traversal OMAP2/3/4: UART: Allow per-UART disabling wakeup for serial ports OMAP3: Fixed crash bug with serial + suspend ...
2009-08-17MIPS: Fix HPAGE_SIZE redefinitionAtsushi Nemoto
This patch fixes warnings like this: CC fs/proc/meminfo.o In file included from /work/linux/include/linux/mmzone.h:20, from /work/linux/include/linux/gfp.h:4, from /work/linux/include/linux/mm.h:8, from /work/linux/fs/proc/meminfo.c:5: /work/linux/arch/mips/include/asm/page.h:36:1: warning: "HPAGE_SIZE" redefined In file included from /work/linux/fs/proc/meminfo.c:2: /work/linux/include/linux/hugetlb.h:107:1: warning: this is the location of the previous definition Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> Acked-by: David Daney <ddaney@caviumnetworks.com> Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2009-08-17xfs: fix locking in xfs_iget_cache_hitChristoph Hellwig
The locking in xfs_iget_cache_hit currently has numerous problems: - we clear the reclaim tag without i_flags_lock which protects modifications to it - we call inode_init_always which can sleep with pag_ici_lock held (this is oss.sgi.com BZ #819) - we acquire and drop i_flags_lock a lot and thus provide no consistency between the various flags we set/clear under it This patch fixes all that with a major revamp of the locking in the function. The new version acquires i_flags_lock early and only drops it once we need to call into inode_init_always or before calling xfs_ilock. This patch fixes a bug seen in the wild where we race modifying the reclaim tag. Signed-off-by: Christoph Hellwig <hch@lst.de> Reviewed-by: Felix Blyakher <felixb@sgi.com> Reviewed-by: Eric Sandeen <sandeen@sandeen.net> Signed-off-by: Felix Blyakher <felixb@sgi.com>
2009-08-17security: define round_hint_to_min in !CONFIG_SECURITYEric Paris
Fix the header files to define round_hint_to_min() and to define mmap_min_addr_handler() in the !CONFIG_SECURITY case. Built and tested with !CONFIG_SECURITY Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
2009-08-17Security/SELinux: seperate lsm specific mmap_min_addrEric Paris
Currently SELinux enforcement of controls on the ability to map low memory is determined by the mmap_min_addr tunable. This patch causes SELinux to ignore the tunable and instead use a seperate Kconfig option specific to how much space the LSM should protect. The tunable will now only control the need for CAP_SYS_RAWIO and SELinux permissions will always protect the amount of low memory designated by CONFIG_LSM_MMAP_MIN_ADDR. This allows users who need to disable the mmap_min_addr controls (usual reason being they run WINE as a non-root user) to do so and still have SELinux controls preventing confined domains (like a web server) from being able to map some area of low memory. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
2009-08-17SELinux: call cap_file_mmap in selinux_file_mmapEric Paris
Currently SELinux does not check CAP_SYS_RAWIO in the file_mmap hook. This means there is no DAC check on the ability to mmap low addresses in the memory space. This function adds the DAC check for CAP_SYS_RAWIO while maintaining the selinux check on mmap_zero. This means that processes which need to mmap low memory will need CAP_SYS_RAWIO and mmap_zero but will NOT need the SELinux sys_rawio capability. Signed-off-by: Eric Paris <eparis@redhat.com> Signed-off-by: James Morris <jmorris@namei.org>
2009-08-17Capabilities: move cap_file_mmap to commoncap.cEric Paris
Currently we duplicate the mmap_min_addr test in cap_file_mmap and in security_file_mmap if !CONFIG_SECURITY. This patch moves cap_file_mmap into commoncap.c and then calls that function directly from security_file_mmap ifndef CONFIG_SECURITY like all of the other capability checks are done. Signed-off-by: Eric Paris <eparis@redhat.com> Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: James Morris <jmorris@namei.org>
2009-08-16dm-log-userspace: fix printk format warningRandy Dunlap
drivers/md/dm-log-userspace-transfer.c:110: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'size_t' Previously posted and acked, but apparently lost. http://lkml.indiana.edu/hypermail/linux/kernel/0906.2/02074.html Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Cc: dm-devel@redhat.com Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-15poll/select: initialize triggered field of struct poll_wqueuesGuillaume Knispel
The triggered field of struct poll_wqueues introduced in commit 5f820f648c92a5ecc771a96b3c29aa6e90013bba ("poll: allow f_op->poll to sleep"). It was first set to 1 in pollwake() (now __pollwake() ), tested and later set to 0 in poll_schedule_timeout(), but not initialized before. As a result when the process needs to sleep, triggered was likely to be non-zero even if pollwake() is not called before the first poll_schedule_timeout(), meaning schedule_hrtimeout_range() would not be called and an extra loop calling all ->poll() would be done. This patch initialize triggered to 0 in poll_initwait() so the ->poll() are not called twice before the process goes to sleep when it needs to. Signed-off-by: Guillaume Knispel <gknispel@proformatique.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Acked-by: Tejun Heo <tj@kernel.org> Cc: stable@kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-15ARM: 5673/1: U300 fix initsection compile warningLinus Walleij
The u300_init_check_chip() function was not properly tagged with the __init macro and provided a initsection mismatch on compilation. Signed-off-by: Linus Walleij <linus.walleij@stericsson.com> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2009-08-15Merge branch 's3c-fixes' of git://aeryn.fluff.org.uk/bjdooks/linuxRussell King
2009-08-15Merge branch 'for-rmk-rc' of git://git.pengutronix.de/git/imx/linux-2.6Russell King
2009-08-15ARM: Fix broken highmem supportRussell King
Currently, highmem is selectable, and you can request an increased vmalloc area. However, none of this has any effect on the memory layout since a patch in the highmem series was accidentally dropped. Moreover, even if you did want highmem, all memory would still be registered as lowmem, possibly resulting in overflow of the available virtual mapping space. The highmem boundary is determined by the highest allowed beginning of the vmalloc area, which depends on its configurable minimum size (see commit 60296c71f6c5063e3c1f1d2619ca0b60940162e7 for details on this). We should create mappings and initialize bootmem only for low memory, while the zone allocator must still be told about highmem. Currently, memory nodes which are completely located in high memory are not supported. This is not a huge limitation since systems relying on highmem support are unlikely to have discontiguous memory with large holes. [ A similar patch was meant to be merged before commit 5f0fbf9ecaf3 and be available in Linux v2.6.30, however some git rebase screw-up of mine dropped the first commit of the series, and that goofage escaped testing somehow as well. -- Nico ] Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Reviewed-by: Nicolas Pitre <nico@marvell.com>
2009-08-14Merge git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixesLinus Torvalds
* git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes: GFS2: Fix permissions on "recover" file
2009-08-14Merge branch 'for_linus' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6 * 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (38 commits) V4L/DVB (12441): siano: read buffer overflow V4L/DVB (12440): Use kzalloc for frontend states to have struct dvb_frontend properly V4L/DVB (12438): Read buffer overflow V4L/DVB (12437): dvb: siano uses/depends on INPUT V4L/DVB (12436): stk-webcam: read buffer overflow V4L/DVB (12432): em28xx: fix regression in Empire DualTV digital tuning V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM default handlers V4L/DVB (12428): hdpvr: add missing initialization of current_norm V4L/DVB (12424): soc-camera: fix recursive locking in .buf_queue() V4L/DVB (12422): media/zr364xx: fix build errors V4L/DVB (12405): em28xx-cards: move register 0x13 setting to the proper place V4L/DVB (12411): em28xx: Fix artifacts with Silvercrest webcam V4L/DVB (12410): em28xx: Move the non-board dependent part to be outside em28xx_pre_card_setup() V4L/DVB (12407): em28xx: Adjust Silvercrest xtal frequency V4L/DVB (12406): em28xx: fix: don't do image interlacing on webcams V4L/DVB (12403): em28xx: properly reports some em2710 chips V4L/DVB (12402): em28xx: fix: some em2710 chips use a different vendor ID V4L/DVB (12401): m9v011: add vflip/hflip controls to control mirror/upside down V4L/DVB (12400): em28xx: Allow changing fps on webcams V4L/DVB (12399): mt9v011: Add support for controlling frame rates ...
2009-08-14GFS2: Fix permissions on "recover" fileSteven Whitehouse
Although this file is only ever written and not read by userspace, it seems that the utils are opening this file O_RDWR, so we need to allow that. Also fixes the whitespace which seemed to be broken. Signed-off-by: Steven Whitehouse <swhiteho@redhat.com> Cc: David Teigland <teigland@redhat.com>
2009-08-14mx31moboard: invert sdhc ro signal senseValentin Longchamp
Small confusion with our hardware engineer, the WP signal (RO) is active low on our boards, the signal has to inverted. This is a pretty straightforward patch, it could even go to -rc, but if not, then push it for 2.6.32. Signed-off-by: Valentin Longchamp <valentin.longchamp@epfl.ch> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
2009-08-14ARM: S3C24XX: Fix clkout mpx errorDavide Rizzo
Bug correction: CLK Outputs cannot have XTAL as parent Signed-off-by: Davide Rizzo <elpa.rizzo@gmail.com> [ben-linux@fluff.org: updated patch subject] Signed-off-by: Ben Dooks <ben-linux@fluff.org>
2009-08-14ARM: S3C64XX: serial: Fix a typo in KconfigRamax Lo
The typo causes drivers/serial/s3c6400.c not being built for s3c6400 platform. Signed-off-by: Ramax Lo <ramaxlo@gmail.com> Signed-off-by: Ben Dooks <ben-linux@fluff.org>
2009-08-13V4L/DVB (12441): siano: read buffer overflowRoel Kluin
With mode DEVICE_MODE_RAW_TUNER a read occurs past the end of smscore_fw_lkup[]. Subsequently an attempt is made to load the firmware from the resulting filename. Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12440): Use kzalloc for frontend states to have struct dvb_frontend ↵Matthias Schwarzott
properly This patch changes most frontend drivers to allocate their state structure via kzalloc and not kmalloc. This is done to properly initialize the embedded "struct dvb_frontend frontend" field, that they all have. The visible effect of this struct being uninitalized is, that the member "id" that is used to set the name of kernel thread is totally random. Some board drivers (for example cx88-dvb) set this "id" via videobuf_dvb_alloc_frontend but most do not. So I at least get random id values for saa7134, flexcop and ttpci based cards. It looks like this in dmesg: DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S) The related kernel thread then also gets a strange name like "kdvb-ad-1-fe--1". Cc: Michael Krufky <mkrufky@linuxtv.org> Cc: Steven Toth <stoth@linuxtv.org> Cc: Timothy Lee <timothy.lee@siriushk.com> Cc: Igor M. Liplianin <liplianin@me.by> Signed-off-by: Matthias Schwarzott <zzam@gentoo.org> Acked-by: Andreas Oberritter <obi@linuxtv.org> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12438): Read buffer overflowRoel Kluin
parport[n] is checked before n < MAX_CAMS Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12437): dvb: siano uses/depends on INPUTRandy Dunlap
siano uses input_*() functions so it should depend on INPUT to prevent build errors: ERROR: "input_event" [drivers/media/dvb/siano/sms1xxx.ko] undefined! ERROR: "input_register_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined! ERROR: "input_free_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined! ERROR: "input_unregister_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined! ERROR: "input_allocate_device" [drivers/media/dvb/siano/sms1xxx.ko] undefined! Cc: Michael Krufky <mkrufky@linuxtv.org> Cc: Uri Shkolnik <uris@siano-ms.com> Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12436): stk-webcam: read buffer overflowRoel Kluin
It tested the value of stk_sizes[i].m before checking whether i was in range. Cc: Hans Verkuil <hverkuil@xs4all.nl> Cc: Trent Piepho <xyzzy@speakeasy.org> Signed-off-by: Roel Kluin <roel.kluin@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12432): em28xx: fix regression in Empire DualTV digital tuningDevin Heitmueller
Restore support for digital tuning caused by regression during introduction of disable_i2c_gate parameter to zl10353 driver. Thanks to user "Xwang" for reporting the problem and testing the fix Cc: Xwang <xwang1976@email.it> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12429): v4l2-ioctl: fix G_STD and G_PARM default handlersHans Verkuil
The v4l core supplies default handlers for G_STD and G_PARM. However, both default handlers are buggy. This patch fixes the following: 1) If no g_std is supplied and current_norm == 0, then this driver does not support TV video standards (e.g. a radio or webcam driver). Return -EINVAL. This ensures that there is no bogus VIDIOC_G_STD support for such drivers. 2) The default VIDIOC_G_PARM handler used current_norm instead of first checking if the driver supported g_std and calling that to get the norm. It also didn't check if current_norm was 0, since in that case the driver does not support TV standards (or no standard was set at all) and the default handler should return -EINVAL. Note that I am very unhappy with these default handlers: I think they basically behave like some very strange and unexpected side-effect. Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12428): hdpvr: add missing initialization of current_normHans Verkuil
Drivers should either set current_norm or supply a g_std callback. The hdpvr driver does neither. Since it initializes to a 60 Hz format I've initialized the current_norm to NTSC | PAL_M | PAL_60 which is the 60 Hz subset of tvnorms. Cc: Janne Grunau <j@jannau.net> Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12424): soc-camera: fix recursive locking in .buf_queue()Guennadi Liakhovetski
The .buf_queue() V4L2 driver method is called under spinlock_irqsave(q->irqlock,...), don't take the lock again inside the function. Reported-by: Antonio Ospite <ospite@studenti.unina.it> Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12422): media/zr364xx: fix build errorsRandy Dunlap
Fix build errors in zr364xx by adding selects: zr364xx.c:(.text+0x195ed7): undefined reference to `videobuf_streamon' zr364xx.c:(.text+0x196030): undefined reference to `videobuf_dqbuf' zr364xx.c:(.text+0x1960c4): undefined reference to `videobuf_qbuf' zr364xx.c:(.text+0x196123): undefined reference to `videobuf_querybuf' zr364xx.c:(.text+0x196182): undefined reference to `videobuf_reqbufs' zr364xx.c:(.text+0x196224): undefined reference to `videobuf_queue_is_busy' zr364xx.c:(.text+0x196390): undefined reference to `videobuf_vmalloc_free' zr364xx.c:(.text+0x196571): undefined reference to `videobuf_iolock' zr364xx.c:(.text+0x196678): undefined reference to `videobuf_mmap_mapper' zr364xx.c:(.text+0x196760): undefined reference to `videobuf_poll_stream' zr364xx.c:(.text+0x19689a): undefined reference to `videobuf_read_one' zr364xx.c:(.text+0x1969ec): undefined reference to `videobuf_mmap_free' zr364xx.c:(.text+0x197862): undefined reference to `videobuf_queue_vmalloc_init' zr364xx.c:(.text+0x197a28): undefined reference to `videobuf_streamoff' zr364xx.c:(.text+0x198203): undefined reference to `videobuf_to_vmalloc' zr364xx.c:(.text+0x198603): undefined reference to `videobuf_streamoff' drivers/built-in.o: In function `free_buffer': zr364xx.c:(.text+0x19930c): undefined reference to `videobuf_vmalloc_free' drivers/built-in.o: In function `zr364xx_open': zr364xx.c:(.text+0x19a7de): undefined reference to `videobuf_queue_vmalloc_init' drivers/built-in.o: In function `read_pipe_completion': zr364xx.c:(.text+0x19b17f): undefined reference to `videobuf_to_vmalloc' Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com> Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12405): em28xx-cards: move register 0x13 setting to the proper placeMauro Carvalho Chehab
Register 0x13 seems to be a sort of image control, maybe gamma, white level or black level. Lower values produce better images, while higher values increases the contrast and shifts colors to green. 0xff produces a black image. This register is not Silvercrest-specific, so its code should be moved to a better place. If this register is left alone, a random value can be found at the register, producing weird results. While here, let's remove register 0x0d, as it had no noticed effect at the image. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12411): em28xx: Fix artifacts with Silvercrest webcamMauro Carvalho Chehab
Silvercrest mt9v011 sensor produces a 640x480 image. However, previously, the code were getting only half of the lines and merging two consecutive frames to "produce" a 640x480 image. With the addition of progressive mode, now em28xx is working with a full image. However, when the number of lines is bigger than 240, the beginning of some odd lines are filled with blank. After lots of testing, and physically checking the device for a Xtal, it was noticed experimentally that mt9v011 is using em28xx XCLK as its clock. Due to that, changing XCLK value changes the maximum speed of the stream. At the tests, it were possible to produce up to 32 fps, using a 30 MHz XCLK. However, at that rate, the artifacts happen even at 320x240. Lower values of XCLK produces artifacts only at 640x480. At some values of xclk (for example XCLKK = 6 MHz, 640x480), it is possible to see an invalid sucession of artifacts with this pattern: .xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx .xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx (where the dots represent the blanked pixels) So, it seems that a waveform in the format of a ramp is interferring at the image. The cause of this interference is currently unknown. Some possibilities are: - electrical interference (maybe this device is broken?); - some issue at mt9v011 programming; - some bug at em28xx chip. So, for now, let's be conservative and use a value of XCLK that we know for sure that it won't cause artifacts. As I'm waiting for more of such devices with different em28xx chipset revisions, I'll have the opportunity to double check the issue with other pieces of hardware. Later patches can vary XCLK depending on the vertical resolutions, if a proper fix is not discovered. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12410): em28xx: Move the non-board dependent part to be outside ↵Mauro Carvalho Chehab
em28xx_pre_card_setup() em28xx_pre_card_setup() is meant to contain board-specific initialization. Also, as autodetection sometimes occur only after having i2c bus enabled, this function may need to be called later. Moving those setups to happen outside the function avoids calling it twice without need and without duplicating output lines at dmesg. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12407): em28xx: Adjust Silvercrest xtal frequencyMauro Carvalho Chehab
We don't know the xtal frequency of Silvercrest, but we need to have some value in order to allow controlling the frame rate frequency. The value is probably still wrong, since the manufacturer announces this device as being capable of 30fps, but the maximum we can get is 13.5 fps. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12406): em28xx: fix: don't do image interlacing on webcamsMauro Carvalho Chehab
Due to historical reasons, em28xx driver gets two consecutive frames and fold them into an unique framing, doing interlacing. While this works fine for TV images, this produces two bad effects with webcams: 1) webcam images are progressive. Merging two consecutive images produce interlacing artifacts on the image; 2) since the driver needs to get two frames, it reduces the maximum frame rate by two. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12403): em28xx: properly reports some em2710 chipsMauro Carvalho Chehab
As reported by hermann pitton <hermann-pitton@arcor.de>, some devices has a different chip id for em2710 (likely the older ones): em28xx: New device @ 480 Mbps (eb1a:2710, interface 0, class 0) em28xx #0: Identified as EM2710/EM2750/EM2751 webcam grabber (card=22) em28xx #0: em28xx chip ID = 17 Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12402): em28xx: fix: some em2710 chips use a different vendor IDMauro Carvalho Chehab
Thanks to hermann pitton <hermann-pitton@arcor.de> for pointing this new variation. Tested-by: hermann pitton <hermann-pitton@arcor.de> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12401): m9v011: add vflip/hflip controls to control mirror/upside downMauro Carvalho Chehab
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12400): em28xx: Allow changing fps on webcamsMauro Carvalho Chehab
em28xx doesn't have temporal scaling. However, on webcams, sensors are capable of changing the output rate. So, VIDIOC_[G|S]_PARM ioctls should be passed to the sensor for it to properly set frame rate. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12399): mt9v011: Add support for controlling frame ratesMauro Carvalho Chehab
Implement g_parm/s_parm ioctls. Those are used to check the current frame rate (in fps) and to set it to a value. In practice, there are only 15 possible different speeds, due to chip limits. Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-08-13V4L/DVB (12394): cx88: Disable xc3028 power management for Geniatech x8000Devin Heitmueller
A user discovered that the Geniatech x8000 encountered a regression when the xc3028 power management was introduced. The xc3028 never recovers after setting the powerdown register, which is probably because the xc3028 reset GPIO is not properly configured. Since I do not have access to the hardware and thus cannot determine the correct GPIO configuration, just disable xc3028 power management on this board, which fixes the regression. Thanks to user "ritec" for reporting the issue and testing the fix. Cc: rictec <rictec@netcabo.pt> Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>