Remove CONFIG_ARCH_OMAP3 conditional compilation and cpu_is_omap34xx test
around buffer threshold based transfer and DMA operating mode control. Use
instead the buffer_size in platform data to determine when these sysfs
controls are exposed and when to access related McBSP registers. Rationale
for this is to make code generic and to allow to use it on OMAP4 that also
supports threshold based transfers.

Currently buffer_size variable is set only for OMAP3 SoCs but it is easy
to extend to OMAP4 and any later OMAP version.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

McBSP transmit and receive configuration control registers must be set up
for OMAP2430 and later. Replace is_omap tests in generic code with a new
feature flag has_ccr in platform data so that there is no need to change
code for any upcoming OMAP version.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Currently wakeup control code is compiled only when CONFIG_ARCH_OMAP3 is
set even it should be available for CONFIG_ARCH_OMAP4 only builds also.

Fix this by making wakeup control generic so that it is executed whenever
new feature flag has_wakeup in platform data is set. Currently flag is set
for McBSP config types 3 and 4.

Remove also old comments about idle mode settings and HW bug workarounds
that were not updated during hwmod conversion.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Register access can be made more generic by calculating register address
offsets runtime from common register definitions and by using reg_size and
reg_step variables that are passed via platform data. Common register
definitions are possible since McBSP registers are ordered similarly between
OMAP versions.

Remove also references to OMAP2+ specific config_type variable from generic
McBSP code since other variables and feature flags are better to carry needed
information from platform code.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Only OMAP1s are using omap_mcbsp_register_board_cfg after OMAP2+ hwmod
conversion so it can be moved to mach-omap1/mcbsp.c.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

These variables got unused after McBSP was converted to use resource
structures.
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>
Acked-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Tested-by: NJanusz Krzysztofik <jkrzyszt@tis.icnet.pl>
Signed-off-by: NTony Lindgren <tony@atomide.com>

Add omap_device pointer to the ARM-specific arch data in the
platform_device.  This will be used to attach OMAP-specific
device-data to the platform device with device lifetime.
Suggested-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Acked-by: NGrant Likely <grant.likely@secretlab.ca>
Signed-off-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NRussell King <rmk+kernel@arm.linux.org.uk>

Commit f41caddb (omap2+: Use
Kconfig symbol in Makefile instead of obj-y) cleaned up the
omap2+ Makefile. However this did not account for the inline
functions that are now needed for board_flash_init and
board_nand_init.
Reported-by: NArnd Bergmann <arnd@arndb.de>
Signed-off-by: NTony Lindgren <tony@atomide.com>

During the idle/suspend path, we expect the console lock to be held so
that no console output is done during/after the UARTs are idled.

However, when using the no_console_suspend argument on the
command-line, the console driver does not take the console lock.  This
allows the possibility of console activity after UARTs have been
disabled.

To fix, update the current is_suspending() to also check the
console_suspend_enabled flag.
Reported-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

Rather than embedding a struct platform_device inside a struct
omap_device, decouple them, leaving only a pointer to the
platform_device inside the omap_device.

Use the arch-specific data field of the platform_device (pdev_archdata)
to add an omap_device pointer after the platform_device has been created.
Signed-off-by: NKevin Hilman <khilman@ti.com>

Public omap_device functions need to take platform_device pointers,
conversion to omap_device pointers is done internal to the omap_device
layer.
Signed-off-by: NKevin Hilman <khilman@ti.com>

The internal device register functions do not need or use any omap_device
internals, so pass in a platform_device pointer instead of an omap_device
pointer.
Signed-off-by: NKevin Hilman <khilman@ti.com>

All of the device init and device driver interaction with omap_device
is done using platform_device pointers.  To make this more explicit,
have omap_device return a platform_device pointer instead of an
omap_device pointer.

All current users of the omap_device pointer were only using it to get
at the platform_device pointer or struct device pointer, so fixing all
of the users was trivial.

This also makes it more difficult for device init code to directly
access members of struct omap_device, and allows for easier changing
of omap_device internals.

Cc: Paul Walmsley <paul@pwsan.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

The *_device_register() functions and the count/fill resources functions
are internal to omap_device and do not need to be in the header.
Signed-off-by: NKevin Hilman <khilman@ti.com>

During normal system operation warning messages similar to this
are appearing quite often:
omap_device: omap4-keypad.-1: new worst case activate latency 0: 61035

This doesn't seem to be reporting a problem, nor is it very useful for
non-developers, so reduce it to debug level.
Acked-by: NSteve Sakoman <steve@sakoman.com>
Signed-off-by: NGrazvydas Ignotas <notasas@gmail.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

For consistency in kernel printk output for devices, use dev_dbg(),
dev_warn(), dev_err() instead of pr_debug(), pr_warning() and
pr_err(), some of which currently use direct access of name from
platform_device and others of which use dev_name().  Using the dev_*
versions uses the standard device naming from the driver core.

Some pr_* prints were not converted with this patch since they are
used before the platform_device and struct device are created so
neither the dev_* prints or dev_name() is valid.
Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
Reviewed-by: NFelipe Balbi <balbi@ti.com>
Signed-off-by: NKevin Hilman <khilman@ti.com>

struct omap_device *od is only set with find_omap_device_by_dev but not used
otherwise so remove them and references to omap device API.
Acked-by: NKevin Hilman <khilman@ti.com>
Signed-off-by: NJarkko Nikula <jarkko.nikula@bitmer.com>

Now that all of the users of the OMAP_CHIP bitfield code have been converted
to use lists, the OMAP_CHIP code, data, and declarations can be removed.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

At Tony's request, remove the OMAP_CHIP* flags from the hwmod data, and
replace it instead with chip family, variant, and ES level-specific lists
of hwmods to register.

Thanks to Gražvydas Ignotas <notasas@gmail.com> for finding a bug in the
AM3517/3505 support, and for other review comments.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>

At Tony's request, remove the omap_chip bitmasks from the powerdomain
definitions.  Instead, initialize powerdomains based on one or more
lists that are applicable to a particular SoC family, variant, and
silicon revision.

Gražvydas Ignotas <notasas@gmail.com> found and reported a bug in a
related patch that also applied to this patch - thanks Gražvydas.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Gražvydas Ignotas <notasas@gmail.com>

In preparation for OMAP_CHIP() removal, split pwrdm_init() into three
functions.  This allows some of them to be called multiple times: for
example, pwrdm_register_pwrdms() can be called once to register
powerdomains that are common to a group of SoCs, and once to register
powerdomains that are specific to a single SoC.

The appropriate order to call these functions - which is enforced
by the code - is:

1. pwrdm_register_platform_funcs()
2. pwrdm_register_pwrdms() (can be called multiple times)
3. pwrdm_complete_init()

Convert the OMAP2, 3, and 4 powerdomain init code to use these new
functions.

While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

At Tony's request, remove the omap_chip bitmasks from the clockdomain
and clockdomain dependency definitions.  Instead, initialize
clockdomains based on one or more lists that are applicable to a
particular SoC family, variant, and silicon revision.

Tony Lindgren <tony@atomide.com> found a bug in a previous version of this
patch - thanks Tony.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Tony Lindgren <tony@atomide.com>

In preparation for OMAP_CHIP() removal, split clkdm_init() into four
functions.  This allows some of them to be called multiple times: for
example, clkdm_register_clkdms() can be called once to register
clockdomains that are common to a group of SoCs, and once to register
clockdomains that are specific to a single SoC.

The appropriate order to call these functions - which is enforced
by the code - is:

1. clkdm_register_platform_funcs()
2. clkdm_register_clkdms() (can be called multiple times)
3. clkdm_register_autodeps() (optional; deprecated)
4. clkdm_complete_init()

Convert the OMAP2, 3, and 4 clockdomain init code to use these new
functions.

While here, improve documentation, and increase CodingStyle
conformance by shortening some local variable names.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>

The OMAP_REVBITS_* macros are just used as otherwise meaningless
aliases for the numbers zero through five, so remove these macros.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

omap3_cpuinfo() contains essentially duplicated code from
omap3_check_revision(), just for the purpose of determining the chip ES level.
Set the cpu_rev char array pointer in omap3_check_revision() instead,
and drop the now-useless code from omap3_cpuinfo().
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

Emit a warning to the console in omap3_check_revision() if that code
cannot determine what type of SoC the system is currently running on.

Remove some extra whitespace, remove some duplicate code, and
add an appropriate comment to a fallthrough case.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Hemant Pedanekar <hemantp@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

Use explicit revision codes for OMAP/AM 3505/3517 ES levels, as the rest
of the OMAP2+ SoCs do in mach-omap2/cpu.c.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

omap3_cpuinfo() is filled with useless strcpy() calls; remove them.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

The OMAP3505/AM3505 appears to be based on the same silicon as the
OMAP3517/AM3517, with some features disabled via eFuse bits.  Follow
the same practice as OMAP3430 and identify these devices internally as
part of the OMAP3517/AM3517 family.

The OMAP3503/3515/3525/3530 chips appear to be based on the same silicon
as the OMAP3430, with some features disabled via eFuse bits.  Identify
these devices internally as part of the OMAP3430 family.

Remove the old OMAP35XX_CLASS, which actually covered two very different
chip families.  The OMAP3503/3515/3525/3530 chips will now be covered by
OMAP343X_CLASS, since the silicon appears to be identical.  For the
OMAP3517/AM3517 family, create a new class, OMAP3517_CLASS.

Thanks to Tony Lindgren <tony@atomide.com> for some help with the second
revision of this patch.
Signed-off-by: NPaul Walmsley <paul@pwsan.com>
Cc: Sanjeev Premi <premi@ti.com>
Cc: Tony Lindgren <tony@atomide.com>
Tested-by: NIgor Grinberg <grinberg@compulab.co.il>
Tested-by: NAbhilash Koyamangalath <abhilash.kv@ti.com>

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm: Remove duplicate "return" statement
  drm/nv04/crtc: Bail out if FB is not bound to crtc
  drm/nouveau: fix nv04_sgdma_bind on non-"4kB pages" archs
  drm/nouveau: properly handle allocation failure in nouveau_sgdma_populate
  drm/nouveau: fix oops on pre-semaphore hardware
  drm/nv50/crtc: Bail out if FB is not bound to crtc
  drm/radeon/kms: fix DP detect and EDID fetch for DP bridges

* 'fixes' of git://git.linaro.org/people/arnd/arm-soc:
  ARM: CSR: add missing sentinels to of_device_id tables
  ARM: cns3xxx: Fix newly introduced warnings in the PCIe code
  ARM: cns3xxx: Fix compile error caused by hardware.h removed
  ARM: davinci: fix cache flush build error
  ARM: davinci: correct MDSTAT_STATE_MASK
  ARM: davinci: da850 EVM: read mac address from SPI flash
  OMAP: omap_device: fix !CONFIG_SUSPEND case in _noirq handlers
  OMAP2430: hwmod: musb: add missing terminator to omap2430_usbhsotg_addrs[]
  OMAP3: clock: indicate that gpt12_fck and wdt1_fck are in the WKUP clockdomain
  OMAP4: clock: fix compile warning
  OMAP4: clock: re-enable previous clockdomain enable/disable sequence
  OMAP: clockdomain: Wait for powerdomain to be ON when using clockdomain force wakeup
  OMAP: powerdomains: Make all powerdomain target states as ON at init

The LTTng 2.0 kernel tracer (stand-alone module package, available at
http://lttng.org) uses the 0xF6 ioctl range for tracer control and
transport operations.
Signed-off-by: NMathieu Desnoyers <mathieu.desnoyers@efficios.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

* 'for-linus' of git://github.com/chrismason/linux:
  Btrfs: add dummy extent if dst offset excceeds file end in
  Btrfs: calc file extent num_bytes correctly in file clone
  btrfs: xattr: fix attribute removal
  Btrfs: fix wrong nbytes information of the inode
  Btrfs: fix the file extent gap when doing direct IO
  Btrfs: fix unclosed transaction handle in btrfs_cont_expand
  Btrfs: fix misuse of trans block rsv
  Btrfs: reset to appropriate block rsv after orphan operations
  Btrfs: skip locking if searching the commit root in csum lookup
  btrfs: fix warning in iput for bad-inode
  Btrfs: fix an oops when deleting snapshots

kmemleak is reporting that 32 bytes are being leaked by FUSE:

  unreferenced object 0xe373b270 (size 32):
  comm "fusermount", pid 1207, jiffies 4294707026 (age 2675.187s)
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [<b05517d7>] kmemleak_alloc+0x27/0x50
    [<b0196435>] kmem_cache_alloc+0xc5/0x180
    [<b02455be>] fuse_alloc_forget+0x1e/0x20
    [<b0245670>] fuse_alloc_inode+0xb0/0xd0
    [<b01b1a8c>] alloc_inode+0x1c/0x80
    [<b01b290f>] iget5_locked+0x8f/0x1a0
    [<b0246022>] fuse_iget+0x72/0x1a0
    [<b02461da>] fuse_get_root_inode+0x8a/0x90
    [<b02465cf>] fuse_fill_super+0x3ef/0x590
    [<b019e56f>] mount_nodev+0x3f/0x90
    [<b0244e95>] fuse_mount+0x15/0x20
    [<b019d1bc>] mount_fs+0x1c/0xc0
    [<b01b5811>] vfs_kern_mount+0x41/0x90
    [<b01b5af9>] do_kern_mount+0x39/0xd0
    [<b01b7585>] do_mount+0x2e5/0x660
    [<b01b7966>] sys_mount+0x66/0xa0

This leak report is consistent and happens once per boot on
3.1.0-rc5-dirty.

This happens if a FORGET request is queued after the fuse device was
released.
Reported-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
Tested-by: NSitsofe Wheeler <sitsofe@yahoo.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

Commit 37fb3a30 ("fuse: fix flock") added in 3.1-rc4 caused flock() to
fail with ENOSYS with the kernel ABI version 7.16 or earlier.

Fix by falling back to testing FUSE_POSIX_LOCKS for ABI versions 7.16
and earlier.
Reported-by: NMartin Ziegler <ziegler@email.mathematik.uni-freiburg.de>
Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
Tested-by: NMartin Ziegler <ziegler@email.mathematik.uni-freiburg.de>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>