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

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.htmlSigned-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Cc: dm-devel@redhat.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

The triggered field of struct poll_wqueues introduced in commit
5f820f64 ("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>

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>

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 60296c71 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 5f0fbf9e
  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>

* git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-fixes:
  GFS2: Fix permissions on "recover" file

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

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

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>

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>

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>

The introduction of the zl10353 i2c gate control broke support for the
Geniatech board (which is not behind an i2 gate).  Add the needed parameter.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Remove the following build warning:

sms-cards.c: In function 'sms_board_event':
sms-cards.c:120: warning: unused variable 'board'

Thanks to Hans Verkuil for pointing this out.

The problem code has been #if 0'd for now, this will likely be
used again in the future, once the event interface is complete.

Cc: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

The iSight sends non-UVC status events through the interrupt endpoint. Those
invalid events are reported to the kernel log, resulting in a log flood.

Only log the events when the UVC_TRACE_STATUS flag is set.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>

Commit 50144aee broke the Samsung NC10
netbook webcam. Instead of applying the FIX_BANDWIDTH quirk to all ViMicro
devices, list the devices explicitly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>