ARM: OMAP: Add maintainer entry for IGEP machines

Enric and I have been mantained this machine and while we
are moving to device trees, it is good that people cc us
when reporting bugs or regression on the board file until
we have proper DT support.

Signed-off-by: Javier Martinez Canillas <javier@dowhile0.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP3: igep0020: Set WIFI/BT GPIO pins in correct mux mode

Setup the WIFI/BT GPIO pin muxes to enable WIFI/BT functionality.

This is needed to fix regression caused by recent versions of
u-boot that only mux essential pins.

Signed-off-by: Anders Hedlund <anders.j.hedlund@gmail.com>
Cc: Jonas Zetterberg <jozz@jozz.se>
Cc: Enric Balletbo i Serra <eballetbo@gmail.com>
Cc: Javier Martinez Canillas <martinez.javier@gmail.com>
Cc: Matthias Brugger <mbrugger@iseebcn.com>
[tony@atomide.com: updated comments to describe regression]
Signed-off-by: Tony Lindgren <tony@atomide.com>
ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC

On OMAP4 boards using the TWL6030 PMIC, the sys_drm_msecure is
connected to the MSECURE input of the TWL6030 PMIC.  This signal
controls the secure-mode operation of the PMIC.  If its not mux'd
correctly, some functionality of the PMIC will not be accessible since
the PMIC will be in secure mode.

For example, if the TWL RTC is in secure mode, most of its registers
are read-only, meaning (re)programming the RTC (e.g. for wakeup from
suspend) will fail.

To fix, ensure the signal is properly mux'd as output when TWL is
intialized.

This fix is required when using recent versions of u-boot (>= v2012.04.01)
since u-boot is no longer setting the default mux for this pin.

Signed-off-by: Kevin Hilman <khilman@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
[SCSI] isci: copy fis 0x34 response into proper buffer

SATA MICROCODE DOWNALOAD fails on isci driver. After receiving Register
Device to Host (FIS 0x34) frame Initiator resets phy.
In the frame handler routine response (FIS 0x34) was copied into wrong
buffer and upper layer did not receive any answer which resulted in
timeout and reset.
This patch corrects this bug.

Signed-off-by: Maciej Patelczyk <maciej.patelczyk@intel.com>
Signed-off-by: Lukasz Dorau <lukasz.dorau@intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[SCSI] Add a report opcode helper

The REPORT SUPPORTED OPERATION CODES command can be used to query
whether a given opcode is supported by a device. Add a helper function
that allows us to look up commands.

We only issue RSOC if the device reports compliance with SPC-3 or
later. But to err on the side of caution we disable the command for ATA,
FireWire and USB.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Acked-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[SCSI] sd: Permit merged discard requests

Support requests with more than one bio payload for discards. The total
number of bytes to be discarded is stored in req->__data_len and used in
sd_done() to complete the I/O.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[SCSI] sd: Implement support for WRITE SAME

Implement support for WRITE SAME(10) and WRITE SAME(16) in the SCSI disk
driver.

 - We set the default maximum to 0xFFFF because there are several
   devices out there that only support two-byte block counts even with
   WRITE SAME(16). We only enable transfers bigger than 0xFFFF if the
   device explicitly reports MAXIMUM WRITE SAME LENGTH in the BLOCK
   LIMITS VPD.

 - max_write_same_blocks can be overriden per-device basis in sysfs.

 - The UNMAP discovery heuristics remain unchanged but the discard
   limits are tweaked to match the "real" WRITE SAME commands.

 - In the error handling logic we now distinguish between WRITE SAME
   with and without UNMAP set.

The discovery process heuristics are:

 - If the device reports a SCSI level of SPC-3 or greater we'll issue
   READ SUPPORTED OPERATION CODES to find out whether WRITE SAME(16) is
   supported. If that's the case we will use it.

 - If the device supports the block limits VPD and reports a MAXIMUM
   WRITE SAME LENGTH bigger than 0xFFFF we will use WRITE SAME(16).

 - Otherwise we will use WRITE SAME(10) unless the target LBA is beyond
   0xFFFFFFFF or the block count exceeds 0xFFFF.

 - no_write_same is set for ATA, FireWire and USB.

Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Reviewed-by: Mike Snitzer <snitzer@redhat.com>
Reviewed-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
[PARISC] fix virtual aliasing issue in get_shared_area()

On Thu, 2012-11-01 at 16:45 -0700, Michel Lespinasse wrote:
> Looking at the arch/parisc/kernel/sys_parisc.c implementation of
> get_shared_area(), I do have a concern though. The function basically
> ignores the pgoff argument, so that if one creates a shared mapping of
> pages 0-N of a file, and then a separate shared mapping of pages 1-N
> of that same file, both will have the same cache offset for their
> starting address.
>
> This looks like this would create obvious aliasing issues. Am I
> misreading this ? I can't understand how this could work good enough
> to be undetected, so there must be something I'm missing here ???

This turns out to be correct and we need to pay attention to the pgoff as
well as the address when creating the virtual address for the area.
Fortunately, the bug is rarely triggered as most applications which use pgoff
tend to use large values (git being the primary one, and it uses pgoff in
multiples of 16MB) which are larger than our cache coherency modulus, so the
problem isn't often seen in practise.

Reported-by: Michel Lespinasse <walken@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: James Bottomley <JBottomley@Parallels.com>
drm/nvc0/disp: fix thinko in vblank regression fix..

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nv40: allocate ctxprog with kmalloc

Some archs defconfigs have CONFIG_FRAME_WARN set to 1024, which lead to this
warning:
drivers/gpu/drm/nouveau/core/engine/graph/ctxnv40.c: warning: the frame size
of 1184 bytes is larger than 1024 bytes

Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau: fix crash with noaccel=1

Reported-by: Ortwin Glück <odi@odi.ch>
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau: add missing pll_calc calls

Fixes a null pointer dereference when reclocking on my fermi.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm/nouveau/bios: fix DCB v1.5 parsing

memcmp->nv_strncmp conversion, in addition to name change, should have
inverted the return value.

But nv_strncmp does not act like strncmp - it does not check for string
terminator, returns true/false instead of -1/0/1 and has different
parameters order.

Let's rename it to nv_memcmp and let it act like memcmp.

Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
ARM: davinci: dm644x: fix out range signal for ED

Fix the video clock setting when custom timings are used with
pclock <= 27MHz. Existing video clock selection uses PLL2 mode
which results in a 54MHz clock whereas using the MXI mode results
in a 27MHz clock (which is the one actually desired).

This bug affects the Enhanced Definition (ED) support on DM644x.
Without this patch, out-range signals errors are were observed on
the TV when viewing ED. An out-of-range signal is often caused when
the field rate is above the rate that the television will handle.

Signed-off-by: Lad, Prabhakar <prabhakar.lad@ti.com>
Signed-off-by: Manjunath Hadli <manjunath.hadli@ti.com>
Cc: Sekhar Nori <nsekhar@ti.com>
[nsekhar@ti.com: reword commit message based on on-list discussion]
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Merge tag 'davinci-fixes-for-v3.7' of git://gitorious.org/linux-davinci/linux-davinci into fixes

From Sekhar Nori:

Fixes an "signal out of range" error when using enhanced
definition display with a DaVinci DM644x device.

* tag 'davinci-fixes-for-v3.7' of git://gitorious.org/linux-davinci/linux-davinci:
  ARM: davinci: dm644x: fix out range signal for ED
drm/radeon: properly track the crtc not_enabled case evergreen_mc_stop()

The save struct is not initialized previously so explicitly
mark the crtcs as not used when they are not in use.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
radeon: add AGPMode 1 quirk for RV250

The Intel 82855PM host bridge / Mobility FireGL 9000 RV250 combination
in an (outdated) ThinkPad T41 needs AGPMode 1 for suspend/resume (under
KMS, that is). So add a quirk for it.

(Change R250 to RV250 in comment for preceding quirk too.)

Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
Merge tag 'omap-for-v3.7-rc5/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes

From Tony Lindgren:
Few more regression fixes related to u-boot only muxing
essential pins.

* tag 'omap-for-v3.7-rc5/fixes-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap:
  ARM: OMAP4: TWL: mux sys_drm_msecure as output for PMIC
  ARM: OMAP3: igep0020: Set WIFI/BT GPIO pins in correct mux mode
  ARM: OMAP: Add maintainer entry for IGEP machines
drm/radeon: add new SI pci id

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
drm/nouveau: use the correct fence implementation for nv50

Only compile time tested, noticed nv50_fence_create was never used,
so fix this. This will probably fix vblank on nv50 cards.

Hopefully this is still in time for 3.7 final release.

Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>