ARM: OMAP: Add function to request a timer by capability

Currently OMAP timers can be requested by requesting any available or by a
numerical device ID. If a specific timer is required because it has a particular
capability, such as can interrupt the on-chip DSP in addition to the ARM CPU,
then the user needs to know the device ID of the timer with this feature.
Therefore, add a new API called omap_dm_timer_request_by_cap() that allows
drivers to request a timer by capability.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
ARM: OMAP: Add a timer attribute for timers that can interrupt the DSP

Some instances of the DMTIMER peripheral on OMAP devices have the ability
to interrupt the on-chip DSP in addition to the ARM CPU. Add a DMTIMER
attribute to indicate which timers can interrupt the DSP. By using the
omap_dm_timer_request_by_cap() API, driver will now be able to allocate
a DMTIMER that can interrupt the DSP based upon this attribute and not require
the driver to know which instance has this capability.

DMTIMERs that have the ability to interrupt the DSP on OMAP devices are as
follows ...

- OMAP1 (OMAP5912/16xx/17xx) devices	- All 8 DMTIMERs
- OMAP2/3/4 devices			- DMTIMERs 5-8

Please note that for OMAP3+, timer8 has the ability to interrupt the DSP and
generate a PWM output.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
ARM: OMAP2+: Remove timer ID test when configuring system timers

Currently, when setting the parent clock of system timers (clock-events and
clock-source), we only set the parent clock if the timer ID is not 12 and
otherwise we leave it has the default. This test is not necessary for the
following reasons ...

1. I believe that this test is only relevant for OMAP3 GP devices where timer
   12 is present but only supports the default 32kHz clock source. Even for
   OMAP3 GP devices, this test will hide/workaround configuration issues.
   Therefore, by removing this test, let the devices fail to boot if configured
   incorrectly. Such configuration errors should be caught and fixed.
2. For OMAP2 devices, timer 12 is available and supports more than one clock
   source and this test would prevent users from selecting alternate clock
   sources for OMAP2.
3. For OMAP4/5 devices, timer 12 is not available and so the test is not
   relevant.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>
ARM: OMAP: Add DT support for timer driver

In order to add device-tree support to the timer driver the following changes
were made ...

1. Allocate system timers (used for clock-events and clock-source) based upon
   timer properties rather than using an hard-coded timer instance ID. To allow
   this a new helper function called omap_dmtimer_find_by_property() has been
   added for finding a timer with the particular properties in the device-tree
   blob. Please note that this is an internal helper function for system timers
   only to find a timer in the device-tree blob. This cannot be used by device
   drivers, another API has been added for that (see below). Timers that are
   allocated for system timers are dynamically disabled at boot time by adding
   a status property with the value "disabled" to the timer's device-tree node.
2. If DT blob is present, then let device-tree create the timer devices
   dynamically.
3. When device-tree is present the "id" field in the platform_device structure
   (pdev->id) is initialised to -1 and hence cannot be used to identify a timer
   instance. Due to this the following changes were made ...
   a). The API omap_dm_timer_request_specific() is not supported when using
       device-tree and will return an error if called when device-tree is
       present. Users of this API should instead use
       omap_dm_timer_request_by_cap().
   b). When removing the DMTIMER driver, the timer "id" was used to identify the
       timer instance. The remove function has been modified to use the device
       name instead of the "id".
4. When device-tree is present the platform_data structure will be NULL and so
   check for this.
5. The OMAP timer device tree binding optional parameters ...
   a). ti,timer-alwon  --> Timer is in an always-on power domain
   b). ti,timer-dsp    --> Timer can generate an interrupt to the on-chip DSP
   c). ti,timer-pwm    --> Timer can generate a PWM output
   Search for the above parameters and set the appropriate timer attribute
   flags.

Signed-off-by: Jon Hunter <jon-hunter@ti.com>