s390/mm: fix pmd_pfn() for thp

The pfn calculation in pmd_pfn() is broken for thp, because it uses
HPAGE_SHIFT instead of the normal PAGE_SHIFT. This is fixed by removing
the distinction between thp and normal pmds in that function, and always
using PAGE_SHIFT.

Reported-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390: use -fPIC for module compile

The xfs module uses a lot of tracepoint, with TRACEPOINTS=y and a
few debugging options the GOT table of the xfs module will get
bigger than 4K. To get a working xfs module it needs to be compiled
with -fPIC instead of -fpic. To play safe use -fPIC for all modules.

Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/time: fix sched_clock() overflow

Converting a 64 Bit TOD format value to nanoseconds means that the value
must be divided by 4.096. In order to achieve that we multiply with 125
and divide by 512.
When used within sched_clock() this triggers an overflow after appr.
417 days. Resulting in a sched_clock() return value that is much smaller
than previously and therefore may cause all sort of weird things in
subsystems that rely on a monotonic sched_clock() behaviour.

To fix this implement a tod_to_ns() helper function which converts TOD
values without overflow and call this function from both places that
open coded the conversion: sched_clock() and kvm_s390_handle_wait().

Cc: stable@kernel.org
Reviewed-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
s390/chsc: fix SEI usage

cbc0dd1 "s390/pci: CHSC PCI support for error and availability events"
introduced a new SEI notification type as part of pci support.
The way SEI was called with nt2 and nt0 consecutive broke the nt0
stuff used for channel subsystem notifications.

The reason why this was broken with the mentioned patch is that you
cannot selectively disable type 0 notifications (so even when asked
for type 2 only, type 0 could be presented).

The way to do it is to tell SEI which types of notification you can
process and -this is the important part- look at the SEI result which
notification type you actually received.

Reviewed-by: Peter Oberparleiter <peter.oberparleiter@de.ibm.com>
Tested-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux

Pull more s390 patches from Martin Schwidefsky:
 "A couple of bug fixes: one of the transparent huge page primitives is
  broken, the sched_clock function overflows after 417 days, the XFS
  module has grown too large for -fpic and the new pci code has broken
  normal channel subsystem notifications."

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/chsc: fix SEI usage
  s390/time: fix sched_clock() overflow
  s390: use -fPIC for module compile
  s390/mm: fix pmd_pfn() for thp
Linux 3.8-rc4
(#workaround) ARM: OMAP3: igep0020: Set DSS pins in correct mux mode.

Setup the DSS pin muxes to enable display functionality.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
(#workaround) omap3isp: implement ENUM_FMT

Whatever format is currently being delivered will be declared as the only
possible format

Signed-off-by: Michael Jones <michael.jones@matrix-vision.de>
(#workaround) omap3isp: support G_FMT

This allows a V4L2 application which has no knowledge of the media
controller to open a video device node of the already-configured ISP
and query what it will deliver. Previously, G_FMT only worked after a
S_FMT had already been done.

Signed-off-by: Michael Jones <michael.jones@matrix-vision.de>
(#waiting-approval) omap_vout: Drop overlay format enumeration

Enumerating formats for output overlays doesn't make sense, as the pixel
format is defined by the display API, not the V4L2 API. Drop the
vidioc_enum_fmt_vid_overlay ioctl operation.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
(#waiting-approval) omap_vout: Use the output overlay ioctl operations

The omap_vout device implements the output overlay API, use the
corresponding ioctl operations.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
(#workaround) omap_vout: Increase the maximum height to 768

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
(#work-in-progress) v4l: Add mt9v034 sensor driver.

The MT9V034 is a parallel wide VGA sensor from Aptina (formerly Micron)
controlled through I2C.

The driver creates a V4L2 subdevice. It currently supports binning and
cropping, and the gain, auto gain, exposure, auto exposure and test
pattern controls.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
(#workaround) OMAP3: igep00x0: Add CAMR0010 support.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
(#workaround) OMAP3: igep00x0: Register DVI device for all boards.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
(#workaround) OMAP3: igep00x0: Add default defconfig.

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
(#workaround) Fix ispvideo build

Signed-off-by: Enric Balletbo i Serra <eballetbo@iseebcn.com>
(#waiting-approval) ARM: OMAP3: clock: Back-propagate rate change from cam_mclk to dpll4_m5

The cam_mclk clock is generated through the following clocks chain:

dpll4 -> dpll4_m5 -> dpll4_m5x2 -> cam_mclk

As dpll4_m5 and dpll4_m5x2 do not driver any clock other than cam_mclk,
back-propagate the cam_clk rate changes up to dpll4_m5.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
(#waiting-approval) omap3isp: Set cam_mclk rate directly

Now that the cam_mclk rate changes are back-propagated to dpll4_m5_ck we
can set the cam_mclk rate directly instead of manually setting the rate
of the parent clock.

Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>