hwspinlock/omap: enable module before reading SYSSTATUS register

The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.

This particular issue is seen rather easily on AM33XX, since the
module wakeup is software controlled, and it is disabled out of
reset. Make sure the module is enabled and clocked before reading
the SYSSTATUS register.

Signed-off-by: Suman Anna <s-anna@ti.com>
[replace pm_runtime_put_sync with lenient pm_runtime_put]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit 'e1e4528' from v3.17]
Signed-off-by: Suman Anna <s-anna@ti.com>
hwspinlock: enable OMAP build for AM33xx, AM43xx & DRA7xx

HwSpinlocks are supported on TI's AM33xx, AM43xx and DRA7xx SoC
device families as well. The IPs are identical to that of
OMAP4/OMAP5, except for the number of locks.

Add a depends on to the above family of SoCs to enable the
build support for OMAP hwspinlock driver for any of the above
SoC configs.

Signed-off-by: Suman Anna <s-anna@ti.com>
[small commit log changes]
Signed-off-by: Ohad Ben-Cohen <ohad@wizery.com>
[s-anna@ti.com: cherry-pick commit 'ceca89e' from v3.17]
Signed-off-by: Suman Anna <s-anna@ti.com>
Documentation: dt: add common bindings for hwspinlock

This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.

All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver core. This base id
needs to be unique across multiple IP instances of a hwspinlock
device, so that each hwlock can be represented uniquely in a
system.

The number of locks is represented by 'hwlock-num-locks' property,
and the base id is represented by the 'hwlock-base-id' property.
The args specifier length is dependent on each vendor-specific
implementation and is represented through the '#hwlock-cells'
property. Client users need to use the property 'hwlocks' for
requesting specific lock(s).

Note that the document is named hwlock.txt deliberately to keep
it a bit more generic.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
Documentation: dt: add the omap hwspinlock bindings document

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.

Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Suman Anna <s-anna@ti.com>
hwspinlock/core: maintain a list of registered hwspinlock banks

The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks. A specific lock can be requested
by users using a global lock id, and any device-specific fields
can be retrieved through a reference to the hwspinlock_device in
each lock.

The global lock id, however, is not friendly to be requested for
users using the device-tree model. The device-tree representation
will typically have each of the hwspinlock devices represented as
a DT node, and a specific lock can be requested using the device's
phandle and a lock specifier. Add support to the core therefore to
maintain all the registered hwspinlock_devices, so that a device
can be looked up and a specific lock belonging to the device
requested through a phandle + args approach.

Signed-off-by: Suman Anna <s-anna@ti.com>
hwspinlock/core: add common OF helpers

This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.

1. The of_hwspin_lock_get_num_locks() is a common OF helper
   function to read the 'hwlock-num-locks' property.
2. The of_hwspin_lock_get_base_id() is a common OF helper
   function to read the 'hwlock-base-id' property.
3. The of_hwspin_lock_get_id() API can be used by hwspinlock
   clients to get the id for a specific lock using the phandle
   + args specifier, so that it can be requested using the
   available hwspin_lock_request_specific() API.

Signed-off-by: Suman Anna <s-anna@ti.com>
hwspinlock/omap: add support for dt nodes

HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.

Signed-off-by: Suman Anna <s-anna@ti.com>
[tony@atomide.com: ack for legacy file removal]
Acked-by: Tony Lindgren <tony@atomide.com>
hwspinlock/core: prepare unregister code to support reserved locks

Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.

Signed-off-by: Suman Anna <s-anna@ti.com>
hwspinlock/core: prepare core to support reserved locks

The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.

This patch prepares the hwspinlock core to support this concept
of reserved locks. A new element is added to struct hwspinlock
to identify whether it is reserved to be allocated using the
hwspin_lock_request_specific() API or available for dynamic
allocation. A new tag name, HWSPINLOCK_RESERVED, is introduced
to mark the reserved locks as such.

Signed-off-by: Suman Anna <s-anna@ti.com>
hwspinlock/core: add support for reserved locks

The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime for clients that do not care about a specific
lock.

The HwSpinlock core has been enhanced to:
  1. mark certain locks as 'reserved' by parsing the DT blob for any
     locks used by client nodes.
  2. restrict the anonymous hwspin_lock_request() API to allocate only
     from non-reserved locks for DT boots.
  3. limit these reserved locks to be allocated only using the
     hwspin_lock_request_specific() API for DT boots.

Signed-off-by: Suman Anna <s-anna@ti.com>
ARM: dts: am335x-evm: add SD card write protect support

Add SD card write protect (lock switch) support for AM335x EVM.

Signed-off-by: Balaji T K <balajitk@ti.com>
Signed-off-by: Sourav Poddar <sourav.poddar@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
ti_config_fragments/audio_display.cfg: Fix compile warning with AM33xx only build

AM33xx only build give the following compile warning:
warning: (VIDEO_AM437X_VPFE && VIDEO_OV2659) selects VIDEO_V4L2_SUBDEV_API which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_DEV && MEDIA_CONTROLLER)
warning: (VIDEO_AM437X_VPFE && VIDEO_OV2659) selects VIDEO_V4L2_SUBDEV_API which has unmet direct dependencies (MEDIA_SUPPORT && VIDEO_DEV && MEDIA_CONTROLLER)
Fixing the same.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Acked-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
Merge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree into ti-linux-3.14.y

TI-Feature: audio-display
TI-Tree: git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree.git
TI-Branch: audio-display-ti-linux-3.14.y

* 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux-kernel/audio-display-linux-feature-tree:
  ti_config_fragments/audio_display.cfg: Fix compile warning with AM33xx only build

Signed-off-by: Dan Murphy <DMurphy@ti.com>
ASoC: davinci-mcasp: Save and restore the serializer registers on suspend

If the board is suspended to a deep sleep state McASP is going to loose it's
context. We also need to save and restore the configuration of the McASP
serializers.
Since the number of serializers depend on the SoC we need to allocate the
memory for them dynamically.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
ARM: dra7.dtsi: Add audio related parameters to hdmi node

Adds HDMI audio sDMA property through a dma-crossbar reference.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
ARM: dts: am437x-gp-evm: disable LCD backlight when using HDMI

Disable the LCD backlight device when the HDMI is used.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
ARM: dts: am43x-epos-evm: disable LCD backlight when using HDMI

Disable the LCD backlight device when the HDMI is used.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: DISPC: fix mflag offset

The register offset for DISPC_OVL_MFLAG_THRESHOLD is wrong, fix it.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: fix dispc register dump for preload & mflag

Preload register is dumped twice for video overlays and mflag register
is not dumped for GFX.

Fix the register dump.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>
OMAPDSS: setup default fifo thresholds

At the moment we don't setup FIFO thresholds by default in omapdss. It's
supposed to be done by the user of omapdss. And that is missing from
omapdrm, causing unoptimal thresholds to be used when using omapdrm.

While I believe it's in theory better to allow the user of omapdss to
setup the fifo thresholds, in practice we always use the same values,
and we could as well setup the thresholds in omapdss.

Furthermore, in omapdss init we always swap the FIFO used for GFX and WB
overlays, but we don't swap the FIFO thresholds for those overlays
(which is the reason for omapdrm using unoptimal HW reset values). So
it would make sense to setup the thresholds to account for the swapping
of the FIFOs.

So, this patch adds code to setup default FIFO tresholds at omapdss
init.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Darren Etheridge <detheridge@ti.com>