android-sdk/kernel-video.git
5 years agoMerge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux... ti2014.10.03
Dan Murphy [Wed, 17 Jun 2015 13:42:52 +0000 (08:42 -0500)]
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:
  OMAPDSS: HDMI: Do not abort audio playback when display is turned off

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoMerge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm...
Dan Murphy [Wed, 17 Jun 2015 13:00:25 +0000 (08:00 -0500)]
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y

TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y

* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
  ARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218
Dave Gerlach [Tue, 16 Jun 2015 19:22:16 +0000 (14:22 -0500)]
ARM: dts: am437x-sk-evm: Reduce i2c0 bus speed for tps65218

Based on the latest timing specifications for the TPS65218 from the data
sheet, http://www.ti.com/lit/ds/symlink/tps65218.pdf, document SLDS206
from November 2014, we must change the i2c bus speed to better fit within
the minimum high SCL time required for proper i2c transfer.

When running at 400khz, measurements show that SCL spends
0.8125 uS/1.666 uS high/low which violates the requirement for minimum
high period of SCL provided in datasheet Table 7.6 which is 1 uS.
Switching to 100khz gives us 5 uS/5 uS high/low which both fall above
the minimum given values for 100 khz, 4.0 uS/4.7 uS high/low.

Without this patch occasionally a voltage set operation from the kernel
will appear to have worked but the actual voltage reflected on the PMIC
will not have updated, causing problems especially with cpufreq that may
update to a higher OPP without actually raising the voltage on DCDC2,
leading to a hang.

Based on debug effort by Nishanth Menon, Felipe Balbi, Aparna
Balasubramanian, Franklin Cooper, and Dave Gerlach.

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoOMAPDSS: HDMI: Do not abort audio playback when display is turned off
Jyri Sarha [Mon, 15 Jun 2015 08:21:37 +0000 (11:21 +0300)]
OMAPDSS: HDMI: Do not abort audio playback when display is turned off

Do not abort audio playback when display is turned off. The audio DMA
stops when the display turned off and the audio stream will timeout in
couple of seconds unless the display is enabled again in time. Without
this patch the audio playback is aborted immediately when display is
turned off.

Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoMerge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integrat...
Dan Murphy [Tue, 16 Jun 2015 13:49:33 +0000 (08:49 -0500)]
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  ARM: DRA7: GMAC: Apply Errata i877
  ARM: OMAP2+: GMAC: Fix clock domain flags
  ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property

Signed-off-by: Dan Murphy <dmurphy@ti.com>
5 years agoARM: DRA7: GMAC: Apply Errata i877
Lokesh Vutla [Tue, 16 Jun 2015 05:35:03 +0000 (11:05 +0530)]
ARM: DRA7: GMAC: Apply Errata i877

Errata ID: i877

Description:
The RGMII Transmit timing is based on the output clock (rgmiin_txc) being
driven relative to the rising edge of an internal clock and the output
control/data (rgmiin_txctl/txd) being driven relative to the falling edge
of an internal clock source. If the internal clock source is allowed to be
static low (i.e., disabled) for an extended period of time then when the
clock is actually enabled the timing delta between the rising edge and
falling edge can change over the lifetime of the device. This can result
in the device switching characteristics degrading over time, and
eventually failing to meet the Data Manual Delay Time/Skew specs.
To maintain RGMII IO Timings, SW should minimize the duration that the
Ethernet internal clock source is disabled. Note that the device reset
state for the Ethernet clock is "disabled".

Workaround:
If the SoC Ethernet interface(s) are used in RGMII mode, SW should minimize
the time the Ethernet internal clock source is disabled to a maximum of
200 hours in a device life cycle. This is done by enabling the clock as
early as possible in IPL (QNX) or SPL/u-boot (Linux/Android) by setting
the register CM_GMAC_CLKSTCTRL[1:0]CLKTRCTRL = 0x2:SW_WKUP.
In addition to programming SW_WKUP(0x2) on CM_GMAC_CLKSTCTRL, SW should
also program modulemode field as ENABLED(0x2) on CM_GMAC_GMAC_CLKCTRL
register.

Note that this erratum applies only when device may need to be used
for 1Gbit operation.
Since the POR is to use 1GB mode, enabling this errata by hooking
ti,no-idle flag to gmac node.

Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoARM: OMAP2+: GMAC: Fix clock domain flags
Lokesh Vutla [Tue, 16 Jun 2015 05:35:02 +0000 (11:05 +0530)]
ARM: OMAP2+: GMAC: Fix clock domain flags

According to AM57x TRM, Document SPRUHZ6, Revised October 2014,
Table 3-1021, SW_SLEEP and HW_AUTO must not be programmed for
gmac clock domain. And also as per the the Errata i877, gmac clock
domain should always be kept in SW_WKUP.
So making the gmac clock domain flag as SWSUP.

AM57x TRM can be found here: http://www.ti.com/lit/ug/spruhz6/spruhz6.pdf

Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoARM: OMAP2+: hwmod: Introduce ti,no-idle dt property
Lokesh Vutla [Tue, 16 Jun 2015 05:35:01 +0000 (11:05 +0530)]
ARM: OMAP2+: hwmod: Introduce ti,no-idle dt property

Introduce a dt property, ti,no-idle, that prevents an IP to idle at any
point. This is to handle Errata i877, which tells that GMAC clocks
cannot be disabled.

Acked-by: Roger Quadros <rogerq@ti.com>
Tested-by: Mugunthan V N <mugunthanvnm@ti.com>
Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoMerge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux...
Dan Murphy [Thu, 11 Jun 2015 20:16:07 +0000 (15:16 -0500)]
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:
  media: ti-vpe: vpdma/vip/vpe: Fix race condition for firmware loading

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agomedia: ti-vpe: vpdma/vip/vpe: Fix race condition for firmware loading
Nikhil Devshatwar [Wed, 10 Jun 2015 07:54:15 +0000 (13:24 +0530)]
media: ti-vpe: vpdma/vip/vpe: Fix race condition for firmware loading

vpdma_create API is supposed to allocated the struct vpdma_data and
return it to the driver. Also, it would call the callback function
when the VPDMA firmware is loaded.

Typically, VIP VPE drivers have following function call:
    dev->vpdma = vpdma_create(pdev, firmware_load_callback);
And the callback implementation would continue the probe further.
Also, the dev->vpdma is accessed from the callback implementation.

This may lead to race condition between assignment of dev->vpdma
and the callback function being triggered.
This would lead to kernel crash because of NULL pointer access.

Fix this by passing a driver wrapped &vpdma_data instead of allocating
inside vpdma_create.
Change the vpdma_create prototype accordingly and fix return paths.

Also, update the VIP and VPE driver to use the updated API and
initialize the dev->vpdma before hand so that the race condition
is avoided.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoMerge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integrat...
Dan Murphy [Mon, 8 Jun 2015 15:03:16 +0000 (10:03 -0500)]
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  mmc: host: omap_hsmmc: Fix DTO and DCRC handling

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoMerge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux...
Dan Murphy [Mon, 8 Jun 2015 13:16:02 +0000 (08:16 -0500)]
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:
  drm/omap: ensure all displays have been probed

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agommc: host: omap_hsmmc: Fix DTO and DCRC handling
Kishon Vijay Abraham I [Fri, 5 Jun 2015 16:07:04 +0000 (21:37 +0530)]
mmc: host: omap_hsmmc: Fix DTO and DCRC handling

DTO/DCRC errors were not being informed to the mmc core since
commit ae4bf788ee ("mmc: omap_hsmmc: consolidate error report handling of
iHSMMC IRQ"). This commit made sure 'end_trans' is never set on DTO/DCRC
errors. This is because after this commit 'host->data' is checked after
it has been cleared to NULL by omap_hsmmc_dma_cleanup().

Because 'end_trans' is never set, omap_hsmmc_xfer_done() is never invoked
making core layer not to be aware of DTO/DCRC errors. Because of this
any command invoked after DTO/DCRC error leads to a hang.

Fix this by checking for 'host->data' before it is actually cleared.

Fixes: ae4bf788ee ("mmc: omap_hsmmc: consolidate error report handling of
iHSMMC IRQ")

Reported-by: Yan Liu <yan-liu@ti.com>
Tested-by: Yan Liu <yan-liu@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agodrm/omap: ensure all displays have been probed
Tomi Valkeinen [Fri, 5 Jun 2015 07:47:21 +0000 (10:47 +0300)]
drm/omap: ensure all displays have been probed

DRM offers no ways to add new displays after the DRM driver has been
loaded. This causes issues on boards that have multiple displays, and
omapdrm is loaded when some of them are loaded but not all. The result
is that omapdrm starts with the displays that were loaded at that time,
ignoring the displays loaded later.

This patch changes the behavior so that omapdrm ensures all display are
loaded which have an alias in the .dts file.

The downside is that this prevents omapdrm from loading if, say, the
user has not compiled a kernel module for one of the displays, or
there's some kind of failure in one of the displays. Thus, after this
patch, all the displays have to work, or none does.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoMerge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel...
Dan Murphy [Wed, 3 Jun 2015 14:55:19 +0000 (09:55 -0500)]
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y

TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y

* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  ARM: DRA7: hwmod: Fix gpmc hwmod

Conflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoARM: DRA7: hwmod: Fix gpmc hwmod
Lokesh Vutla [Wed, 3 Jun 2015 13:05:22 +0000 (18:35 +0530)]
ARM: DRA7: hwmod: Fix gpmc hwmod

GPMC does not support smart idle with wakeup.
Instead of removing SIDLE_SMART_WKUP for gpmc, it was removed for
ocp2scp by mistake. Fix it.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
5 years agoMerge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm...
Dan Murphy [Tue, 2 Jun 2015 21:29:47 +0000 (16:29 -0500)]
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y

TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y

* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
  ARM: OMAP2+: AMX3XX: Add HWMOD_NEEDS_REIDLE to gpmc
  ARM: OMAP2+: omap_hwmod: Reidle flagged hwmods when restoring context
  ARM: OMAP2+: omap_hwmod: Add softreset to _reidle
  ARM: OMAP2+: omap_hwmod: Refactor HWMOD_NEEDS_REIDLE support code
  ARM: OMAP2+: omap_hwmod: Always restore saved hardreset context

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoARM: OMAP2+: AMX3XX: Add HWMOD_NEEDS_REIDLE to gpmc
Dave Gerlach [Tue, 2 Jun 2015 15:57:11 +0000 (10:57 -0500)]
ARM: OMAP2+: AMX3XX: Add HWMOD_NEEDS_REIDLE to gpmc

gpmc hwmod on am43xx needs a softreset before idling, so add the
HWMOD_NEEDS_REIDLE flag so that in the case of no driver being present,
the module will get properly reidled and shut off after a suspend cycle
or when attempting to disable it after an RTC+DDR cycle.

Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoARM: OMAP2+: omap_hwmod: Reidle flagged hwmods when restoring context
Dave Gerlach [Tue, 2 Jun 2015 16:00:56 +0000 (11:00 -0500)]
ARM: OMAP2+: omap_hwmod: Reidle flagged hwmods when restoring context

After the PRCM loses context in the case of an RTC+DDR cycle omap_hwmod
attempts to return all hwmods to their previous state, however as
indicated in patch c388763a9c88 ("ARM: OMAP2+: omap_hwmod: Introduce
HWMOD_NEEDS_REIDLE"), certain hwmods cannot just be disabled when in
their default state, which is why they need the special handling present
in that patch when no driver is present.

In RTC+DDR mode, even if all drivers are present, the modules are all
returned to their previous state before any driver resume happens so we
will still face the issue described above. This can be prevented by
calling _reidle on all hwmods that need it for any module that is being
disabled to return to it's previous state.

Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoARM: OMAP2+: omap_hwmod: Add softreset to _reidle
Dave Gerlach [Tue, 2 Jun 2015 15:54:17 +0000 (10:54 -0500)]
ARM: OMAP2+: omap_hwmod: Add softreset to _reidle

Certain hwmods, like gpmc on am437x, require a softreset in order for
them to go idle. Add a call to omap_hwmod_softreset in our _reidle path
so that hwmods that must be reidled will have a software reset performed
on them before attempting to actually idle them.

Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoARM: OMAP2+: omap_hwmod: Refactor HWMOD_NEEDS_REIDLE support code
Dave Gerlach [Tue, 2 Jun 2015 15:41:48 +0000 (10:41 -0500)]
ARM: OMAP2+: omap_hwmod: Refactor HWMOD_NEEDS_REIDLE support code

Refactor the _reidle_all function introduced by c388763a9c88 ("ARM:
OMAP2+: omap_hwmod: Introduce HWMOD_NEEDS_REIDLE") to use a _reidle
function that can reidle single omap_hwmods so that we are able to
call this for single hwmods rather than running it for the
oh_reidle_list.

Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoARM: OMAP2+: omap_hwmod: Always restore saved hardreset context
Dave Gerlach [Mon, 1 Jun 2015 19:08:03 +0000 (14:08 -0500)]
ARM: OMAP2+: omap_hwmod: Always restore saved hardreset context

Previously when restoring hardreset context during
omap_hwmod_restore_context we would only deassert the hardreset lines if
the module was previously active, however, if a hwmod has all hardresets
asserted then _enable will return without actually enabling the module.

This is a problem for the gfx hwmod on am437x as it gets disabled in
suspend path so it appears as disabled to the restore context code but
then during the attempted enable call during the regular kernel resume
path, the hwmod cannot actually be enabled.

Acked-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoMerge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel...
Dan Murphy [Tue, 2 Jun 2015 17:05:14 +0000 (12:05 -0500)]
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into ti-linux-3.14.y

TI-Feature: platform_base
TI-Tree: git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree.git
TI-Branch: platform-ti-linux-3.14.y

* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree:
  ARM: DRA7: hwmod: Fix GPMC from preventing core suspend
  ARM: DRA7: hwmod: fix gpmc hwmod

Conflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.c

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoARM: DRA7: hwmod: Fix GPMC from preventing core suspend
Roger Quadros [Mon, 1 Jun 2015 14:22:48 +0000 (17:22 +0300)]
ARM: DRA7: hwmod: Fix GPMC from preventing core suspend

GPMC hwmod is flagged as HWMOD_INIT_NO_IDLE so it is kept
enabled at boot. If the GPMC driver is not loaded then
GPMC will not be idled thus preventing CORE from going idle
during suspend.

Disable HWMOD_INIT_NO_IDLE and HWMOD_INIT_NO_RESET.

The only reason HWMOD_INIT_NO_RESET was there was to retain
GPMC timings/settings configured by bootloader. We no longer
need that as we're configuring the timins in the kernel.

There is no reasoning as to why HWMOD_INIT_NO_IDLE was there.
Seems to have beein blindly copied from omap3/4 hwmod code.

Signed-off-by: Roger Quadros <rogerq@ti.com>
5 years agoARM: DRA7: hwmod: fix gpmc hwmod
Roger Quadros [Mon, 1 Jun 2015 14:22:47 +0000 (17:22 +0300)]
ARM: DRA7: hwmod: fix gpmc hwmod

GPMC smart idle is not really broken but it does not support
smart idle with wakeup.

Fixes: 3a85559fcf34d ("ARM: OMAP: DRA7: hwmod: Make gpmc software supervised as the smart idle is broken")

Signed-off-by: Roger Quadros <rogerq@ti.com>
5 years agoMerge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux...
Dan Murphy [Mon, 1 Jun 2015 13:51:55 +0000 (08:51 -0500)]
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:
  media: ti-vpe: vip: Fix input/std/parm reporting
  media: ti-vpe: VIP/VPE/VPDMA: Correction of data type label.
  media: ti-vpe: vip: Fix format negotiation with sub-device
  OMAPDSS: dra7-tpd12s015: fix dependency to mcasp

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agomedia: ti-vpe: vip: Fix input/std/parm reporting
Benoit Parrot [Fri, 29 May 2015 18:08:43 +0000 (13:08 -0500)]
media: ti-vpe: vip: Fix input/std/parm reporting

v4l2-compliance was reporting errors and warning wrt
s/g/enum input, s/g/query std and s/g parm ioctl.
These currently return static values but were incomplete
causing the errors and warnings.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agomedia: ti-vpe: VIP/VPE/VPDMA: Correction of data type label.
Benoit Parrot [Fri, 29 May 2015 18:08:42 +0000 (13:08 -0500)]
media: ti-vpe: VIP/VPE/VPDMA: Correction of data type label.

The YUV data type definition below are taken from
both the TRM and i839 Errata information.
Use the correct data type considering byte
reordering of components.

Also since the single use of "C" in the 422 case
to mean "Cr" (i.e. V component). It was decided
to explictly label them CR to remove any confusion.
Bear in mind that the type label refer to the memory
packed order (LSB - MSB).

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agomedia: ti-vpe: vip: Fix format negotiation with sub-device
Benoit Parrot [Fri, 29 May 2015 18:08:41 +0000 (13:08 -0500)]
media: ti-vpe: vip: Fix format negotiation with sub-device

As recently understood VIP only expect the input format to be in UYVY form.
Commit b74d2ff "YUV422 data is not interpreted correctly" was attempting
to allow all of the various subdevice supported bus format to be used
as input format to VIP. Unfortunately this is having side effect
when trying to convert any of these various input formats to NV12
for example. In order to have VIP generate the correct/expected
output format for instance UYVY, YUYV or NV12 the input data coming
from the sub-device must be in UYVY format.

As a result VIP will now expect the sub-device to support UYVY
and will be able to support at least:

- YUV422 UYVY
- YUV422 YUYV
- YUV422 VYUY
- YUV422 YVYU
- YUV420 NV12

Also v4l2-compliance was reporting errors and warning wrt
s/g/try fmt ioctl.
The errors were caused by mis-handling of invalid format details
which would generates error return codes.
These calls are not supposed to fail on invalid input.
Instead they are supposed to return a valid configuration
instead of an error as per v4l2-compliance tests.
Reworked g_fmt, s_fmt and try_fmt to simplify/streamlined them
Reworked the subdev fmt enumeration on subdev discovery.
Added subdev g_fmt call on device open to provide a valid initial format.

Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoOMAPDSS: dra7-tpd12s015: fix dependency to mcasp
Tomi Valkeinen [Fri, 29 May 2015 05:31:46 +0000 (08:31 +0300)]
OMAPDSS: dra7-tpd12s015: fix dependency to mcasp

The recent changes to dra7-tpd12s015 driver require mcasp, but it was
not expressed in the Kconfig, leading to errors like:

drivers/built-in.o: In function `hdmi_i2c2_hack_demux':
linux/git/drivers/video/fbdev/omap2/displays-new/dra7-evm-encoder-tpd12s015.c:117:
undefined reference to `dra7_mcasp_hdmi_gpio_set'

Add dependency to SND_DAVINCI_SOC_MCASP.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoMerge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integrat...
Dan Murphy [Sat, 30 May 2015 19:55:07 +0000 (14:55 -0500)]
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  usb: dwc3: core: don't break during suspend/resume while we're dual-role
  usb: dwc3: core: Prevent otg events from disabling themselves

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoMerge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux...
Dan Murphy [Sat, 30 May 2015 17:15:54 +0000 (12:15 -0500)]
Merge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux-3.14.y

TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-3.14.y

* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
  samples/rpmsg: add support for multiple instances
  Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
  ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
  iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
  iommu/omap: add pdata ops for setting powerdomain constraint
  ARM: dts: OMAP5: Fix the standby info for IPU & DSP
  remoteproc/omap: revise the comment about standby in _suspend
  remoteproc/pruss: fix pruss_init return on error
  remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
  remoteproc/omap: fix a minor typo in a trace message
  remoteproc/omap: add support for runtime auto-suspend/resume

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoMerge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux...
Suman Anna [Sat, 30 May 2015 02:13:31 +0000 (21:13 -0500)]
Merge branch 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into rpmsg-ti-linux-3.14.y

Pull in a minor enhancement to the rpmsg_client_sample driver to support
multiple instances. This will allow the driver to communicate to each
instance that may be present on different remote processors.

* 'rpmsg-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
  samples/rpmsg: add support for multiple instances

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agosamples/rpmsg: add support for multiple instances
Suman Anna [Sat, 30 May 2015 01:46:11 +0000 (20:46 -0500)]
samples/rpmsg: add support for multiple instances

The current rpmsg_client_sample is a very simple example and
is not designed to handle multiple instances. Add support for
multiple instances, so that the same number of pings are sent
to each instance. The instances can be on one or multiple
remote processors.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Sat, 30 May 2015 01:02:42 +0000 (20:02 -0500)]
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y

Pull in the updated remoteproc feature branch that includes the
necessary support to fix the DRA7 IPU1 boot issue when integrated
with PM tree or TI Integration kernel. The merge also syncs up
the RPMsg integration branch with the latest platform base code.

* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc: (132 commits)
  Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
  ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
  iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
  iommu/omap: add pdata ops for setting powerdomain constraint
  ARM: dts: OMAP5: Fix the standby info for IPU & DSP
  ARM: OMAP: Check for clocks which do not have parents
  ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
  ARM: dts: DRA7: Add DT node for AES2 IP
  ARM: DRA7: hwmod: Add data for AES2 IP
  crypto: omap-aes - Add support for multiple cores
  crypto: omap-aes - Fix registration of Algos
  crypto: omap-aes - Fix enabling clocks
  crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
  crypto: omap-aes - Add support for GCM mode
  crypto: omap-aes - Fix configuring of AES mode
  crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
  crypto: omap-des: Fix unmapping of dma channels
  dmaenegine: edma: allow pause/resume for non-cyclic mode
  ARM: common: edma: clear completion interrupts on stop
  bus: omap_l3_noc: Fix master id address decoding for OMAP5
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoRevert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"
Suman Anna [Wed, 27 May 2015 21:50:16 +0000 (16:50 -0500)]
Revert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot"

This reverts commit 6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0.

The commit 6d6dd44c5563 ("ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP
for proper boot") switched the IPU1 clock domain to SWSUP only to resolve
an IPU1 boot issue. However, this solution worked only because of another
pre-existing bug in the omap_hwmod code, wherein a usage count for the hwmod
parent clockdomain was incremented during omap_device_deassert_hardreset()
and was never balanced, causing the clockdomain to always remain on and
never allowing the corresponding power domain to enter a low power state.
This eliminated the pre-condition for the IPU1 boot issue. The bug in
omap_hwmod layer was resolved by commit e1d52c6d4ff7 ("ARM: OMAP2+: hwmod:
fix deassert hardreset clkdm usecounting"), and this resulted in the
recurrence of the IPU1 boot issue on some platforms.

The IPU1 boot issue has now been resolved by restricting the target power
domain state to ON during the power-up of the MMU and allowing RET or a
lower power state only when the MMU and the corresponding parent remoteproc
is suspended (system or runtime suspend). So revert back to the default
expected HWSUP mode for the IPU1 clock domain.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux...
Suman Anna [Sat, 30 May 2015 00:41:21 +0000 (19:41 -0500)]
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y

Merge in the updated iommu feature branch into remoteproc tree to
pull in the necessary support to fix the DRA7 IPU1 boot issue when
integrated with PM tree.

* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
  ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
  iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
  iommu/omap: add pdata ops for setting powerdomain constraint

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel...
Suman Anna [Sat, 30 May 2015 00:36:15 +0000 (19:36 -0500)]
Merge branch 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree into rproc-linux-3.14.y

Resync with the latest platform base code. Relevant
fixes include fixes on DPLL bypass clock settings
and support for Timers 12 through 16.

* 'platform-ti-linux-3.14.y' of git://git.ti.com/~rrnayak/ti-linux-kernel/platform-linux-feature-tree: (127 commits)
  ARM: OMAP: Check for clocks which do not have parents
  ARM: OMAP: DRA7: clockdomain: Implement timer workaround for errata i874
  ARM: dts: DRA7: Add DT node for AES2 IP
  ARM: DRA7: hwmod: Add data for AES2 IP
  crypto: omap-aes - Add support for multiple cores
  crypto: omap-aes - Fix registration of Algos
  crypto: omap-aes - Fix enabling clocks
  crypto: tcrypt - Added speed tests for Async AEAD crypto alogrithms
  crypto: omap-aes - Add support for GCM mode
  crypto: omap-aes - Fix configuring of AES mode
  crypto: omap-aes - Add support for lengths not aligned with AES_BLOCK_SIZE
  crypto: omap-des: Fix unmapping of dma channels
  dmaenegine: edma: allow pause/resume for non-cyclic mode
  ARM: common: edma: clear completion interrupts on stop
  bus: omap_l3_noc: Fix master id address decoding for OMAP5
  ARM: edma: Clear IRQ if we get interrupted by a unknown event
  bus: omap_l3_noc: Fix connID for OMAP4
  bus: omap_l3_noc: Fix offset for DRA7 CLK1_HOST_CLK1_2 instance
  crypto: omap-sham: Use pm_runtime_irq_safe()
  crypto: omap-sham: Add the offset of sg page to vaddr
  ...

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot
Suman Anna [Wed, 27 May 2015 03:00:51 +0000 (22:00 -0500)]
ARM: OMAP2+: use separate IOMMU pdata to fix DRA7 IPU1 boot

The IPU1 MMU has been using common IOMMU pdata quirks defined and
used by all IPU IOMMU devices on OMAP4 and beyond. Separate out the
pdata for IPU1 MMU with the additional .set_pwrdm_constraint ops
plugged in, so that the IPU1 power domain can be restricted to ON
state during the boot and active period of the IPU1 remote processor.
This eliminates the pre-conditions for the IPU1 boot issue as
described in [1].

NOTE:
The fix is currently applied only to IPU1 on DRA7xx SoC, as the
other affected processors on OMAP4/OMAP5/DRA7 are in domains that
are not entering RET. The fix can be easily scaled if these domains
do hit RET in the future.

[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoiommu/omap: fix boot issue on remoteprocs with AMMU/Unicache
Suman Anna [Wed, 27 May 2015 03:15:03 +0000 (22:15 -0500)]
iommu/omap: fix boot issue on remoteprocs with AMMU/Unicache

This patch invokes the .set_pwrdm_constraint pdata ops, if present,
during the runtime resume and suspend callbacks to resolve a possible
boot issue on remote processors with AMMU/Unicache, and whose power
domains enter RET between the time the MMU is powered ON to the time
the remote processor is released from reset. The issue is described
in detail in [1].

The pdata ops implementation restricts the target power domain to
ON during resume, and back to the original power domain state during
suspend, and thereby eliminating the conditions for the boot issue.
The implementation is effective only when the original power domain
state is either RET or OFF, and is a no-op when it is ON or INACTIVE.
Doing this in the PM runtime callbacks ensures that the target power
domain stays ON only during the time when the remote processor is
active. The remote processors are typically auto-suspended after an
inactivity period of 10 seconds.

The .set_pwrdm_constraint ops need to be plugged in pdata-quirks
for the affected remote processors to be able to boot properly.

[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm...
Dan Murphy [Fri, 29 May 2015 23:43:33 +0000 (18:43 -0500)]
Merge branch 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree into ti-linux-3.14.y

TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y

* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
  ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode
  regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs
  mfd: tps65218: add version check to the PMIC probe
  rtc: omap: fix ext-wakeup setup
  rtc: omap: do not disable RTC alarm during shutdown
  rtc: omap: setup the regulators for poweroff mode
  ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode
  regulator: tps65218: force set power-up/down strobe to 3 for dcdc3
  regulator: of: setup initial suspend state
  ARM: dts: AM43xx: update regulator nodes for new layout
  regulator: of: Add support for parsing regulator_state for suspend state
  ARM: dts: dra7: add i810 errata dpll data
  ARM: DRA7: dpll: add implementation for errata i810

Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.h

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoiommu/omap: add pdata ops for setting powerdomain constraint
Suman Anna [Wed, 27 May 2015 02:30:04 +0000 (21:30 -0500)]
iommu/omap: add pdata ops for setting powerdomain constraint

Add a new platform data ops to allow the OMAP IOMMU driver to be able
to request a specific target power domain state for the domain it
belongs to. This ops is being added to resolve a boot issue on OMAP
remote processors like IPU that have an AMMU/Unicache, which will be
in an invalid state if the particular power domain enters RET between
the MMU programming and releasing the reset of the remote processor.
See [1] for more details on the issue.

The ops will allow to invoke the pwrdm_set_next_pwrst() API in a
multi-arch kernel environment. The ops also returns the current power
domain state while enforcing the constraint so that the driver can
store it and use it to set back the power domain state while releasing
the constraint.

[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode
Tero Kristo [Fri, 29 May 2015 07:09:13 +0000 (10:09 +0300)]
ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode

Without this, the memory will remain active during poweroff consuming
extra power. Please note revision 2.1 PMIC seems to fail when DCDC3
disable is attempted, so this is not done on that PMIC revision. The
PMIC revision checks in the regulator patches make sure of this.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoregulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs
Tero Kristo [Thu, 28 May 2015 07:37:41 +0000 (10:37 +0300)]
regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs

Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agomfd: tps65218: add version check to the PMIC probe
Tero Kristo [Thu, 28 May 2015 07:36:19 +0000 (10:36 +0300)]
mfd: tps65218: add version check to the PMIC probe

Version information will be needed to handle some error cases under the
regulator driver, so store the information once during MFD probe.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agortc: omap: fix ext-wakeup setup
Tero Kristo [Mon, 25 May 2015 09:03:57 +0000 (12:03 +0300)]
rtc: omap: fix ext-wakeup setup

The register write for the ext-wakeup handling does not write the
EXT_WAKEUP_EN bit at all, which causes a system shutdown after
20 seconds after wakeup from EXT_WAKEUP (e.g. power button.) Fixed
by adding the missing bit.

Fixes: 4c71e686101d (drivers/rtc/rtc-omap.c: Enable power..)

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agortc: omap: do not disable RTC alarm during shutdown
Tero Kristo [Thu, 21 May 2015 09:41:45 +0000 (12:41 +0300)]
rtc: omap: do not disable RTC alarm during shutdown

This enables use cases like rtc-only mode, where most of the system is
shutdown just waiting for an RTC alarm to occur and boot the device up.

Only supported for systems that have the RTC act as a system power
controller at the moment (AM33xx/AM43xx.)

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agortc: omap: setup the regulators for poweroff mode
Tero Kristo [Thu, 21 May 2015 09:37:50 +0000 (12:37 +0300)]
rtc: omap: setup the regulators for poweroff mode

In certain cases, like rtc-only mode, the system regulators shall be
set to slightly different mode compared to suspend to mem. As the RTC
driver is handling the poweroff setup on some systems, add a callback
to regulator core from the RTC power off to setup the valid regulator
states.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode
Tero Kristo [Thu, 21 May 2015 09:35:27 +0000 (12:35 +0300)]
ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode

Without this, the memory will remain active during poweroff consuming
extra power.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoregulator: tps65218: force set power-up/down strobe to 3 for dcdc3
Tero Kristo [Thu, 21 May 2015 09:33:18 +0000 (12:33 +0300)]
regulator: tps65218: force set power-up/down strobe to 3 for dcdc3

The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoregulator: of: setup initial suspend state
Tero Kristo [Fri, 22 May 2015 08:24:22 +0000 (11:24 +0300)]
regulator: of: setup initial suspend state

Setup initial suspend state to mem, if suspend state is defined for
mem state. This makes sure that the regulators are in proper mode
already from boot.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoARM: dts: AM43xx: update regulator nodes for new layout
Tero Kristo [Fri, 22 May 2015 08:03:35 +0000 (11:03 +0300)]
ARM: dts: AM43xx: update regulator nodes for new layout

Upstream has support for regulator-state-mem, instead of the internal
version of regulator-suspend-enable. Update the AM43xx DT nodes to
support the upstream layout.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoregulator: of: Add support for parsing regulator_state for suspend state
Chanwoo Choi [Fri, 10 Oct 2014 11:35:33 +0000 (20:35 +0900)]
regulator: of: Add support for parsing regulator_state for suspend state

[ Upstream commit 5e5e3a42c653c5ef1c281651f1882411601129bd ]

The regulation_constraints structure includes specific field to support
suspend state for global PMIC SUSPEND/HIBERNATE mode. This patch add support
for parsing regulator_state for suspend state.

Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>
Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
Conflicts:

drivers/regulator/of_regulator.c

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoARM: dts: dra7: add i810 errata dpll data
Tero Kristo [Tue, 26 May 2015 10:43:57 +0000 (13:43 +0300)]
ARM: dts: dra7: add i810 errata dpll data

Add DPLL sink clockdomain info for dra7. Required for errata i810;
downstream clockdomain for a DPLL must be force enabled while
changing the M/N ratios.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoARM: DRA7: dpll: add implementation for errata i810
Tero Kristo [Wed, 27 May 2015 06:14:51 +0000 (09:14 +0300)]
ARM: DRA7: dpll: add implementation for errata i810

Errata i810 states that the DPLL controller can be stuck if the downstream
clocks are disabled and DPLL is in auto mode while M/N ratios are changed.
Workaround for this is to force enable (SW_WKUP) the downstream clockdomain
while reprogramming the DPLL. This patch adds the support for this, the
actual clkdm-sink info needs to be added in a separate patch.

See DRA75x, DRA74x Errata; id i810 for more details.

Signed-off-by: Tero Kristo <t-kristo@ti.com>
Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agoMerge branch 'platform-ti-linux-3.14.y' into pm-ti-linux-3.14.y
Dave Gerlach [Fri, 29 May 2015 21:35:28 +0000 (16:35 -0500)]
Merge branch 'platform-ti-linux-3.14.y' into pm-ti-linux-3.14.y

Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.h
include/linux/mfd/palmas.h

Signed-off-by: Dave Gerlach <d-gerlach@ti.com>
5 years agousb: dwc3: core: don't break during suspend/resume while we're dual-role
Roger Quadros [Thu, 28 May 2015 16:58:42 +0000 (19:58 +0300)]
usb: dwc3: core: don't break during suspend/resume while we're dual-role

We can't rely just on dr_mode to decide if we're in host or gadget
mode when we're configured as otg/dual-role. So while dr_mode is
OTG, we find out from  the otg state machine if we're in host
or gadget mode and take the necessary actions during suspend/resume.

Also make sure that we disable OTG irq and events during system suspend
so that we don't lockup the system during system suspend/resume.

Known Issue:
when otg-host, usb device disconnects and reconnects after system suspend/resume.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agousb: dwc3: core: Prevent otg events from disabling themselves
Roger Quadros [Wed, 27 May 2015 16:30:58 +0000 (19:30 +0300)]
usb: dwc3: core: Prevent otg events from disabling themselves

There is a race happening during dwc3_drd_init() that causes
otg events to get disabled. This is what happens.

dwc3_otg_irq() happens immediately when PRTCAP is set to OTG,
even though OEVTEN is 0. This is because BIT 31 IRQ of
OEVT can't be disabled by OEVTEN.
We configure OEVTEN in dwc3_otg_init() but dwc3_otg_irq() has
already saved OEVTEN as 0 into dwc->oevten. So finally when
dwc3_irq_thread_irq() is called we save 0 into OEVTEN
thus disabling OTG irqs forever.

We fix this by disabling IRQs when configuring OEVTEN in
dwc3_otg_init().

eviewed-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoARM: dts: OMAP5: Fix the standby info for IPU & DSP
Suman Anna [Wed, 27 May 2015 20:17:26 +0000 (15:17 -0500)]
ARM: dts: OMAP5: Fix the standby info for IPU & DSP

The commit 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for
IPU and DSP") added the ti,rproc-standby-info property mistakenly
to the IPU & DSP MMU nodes instead of adding them to the processor
nodes. This results in a probe failure of the OMAP remoteproc driver.
Fix this error by moving these properties from the MMU nodes to the
processor nodes.

Fixes: 04e7b6f76f6b ("ARM: dts: OMAP5: Add standby info for IPU and DSP")
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux...
Dan Murphy [Wed, 27 May 2015 17:21:34 +0000 (12:21 -0500)]
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:
  OMAPDSS: dra7-tpd12s015: support system suspend
  OMAPDSS: dra7-tpd12s015: lock i2c adapter when using DDC
  OMAPDSS: dra7-tpd12s015: move ddc pixmux to .dts
  OMAPDSS: dra7-tpd12s015: remove legacy platform data
  ASoC: davinci-mcasp: HACK interface to handle dra7-evm's i2c2/HDMI mux
  ARM: DTS: dra7-evm: Enable mcasp8
  ARM: DTS: dra7: Add node for McASP8
  ARM: DRA7: hwmod: Add data for McASP8
  ARM: clk: dra7xx: Correct mcasp8_ahclkx_mux name

Signed-off-by: Dan Murphy <dmurphy@ti.com>
5 years agoOMAPDSS: dra7-tpd12s015: support system suspend
Tomi Valkeinen [Tue, 26 May 2015 09:59:21 +0000 (12:59 +0300)]
OMAPDSS: dra7-tpd12s015: support system suspend

The driver uses mcasp2 pin for a gpio, with direct register writes. On
system suspend the mcasp2 is left alive, preventing suspend.

Also, mcasp2 may be used for other purposes, so directly touching the
mcasp2 registers can cause problems. Luckily, the same pin can be muxed
to mcasp8 mode, and mcasp8 is not used by anyone.

We now have hacks made to mcasp driver which allows the dra7-tpd12s015
driver to manage the mcasp8 pin via the mcasp driver. While the solution
is a pure hack, it allows us to do proper power management, and remove
all the direct register write hackery.

dra7-tpd12s015's device tree data contains a phandle to the mcasp8 node,
and dra7-tpd12s015 driver uses this handle to enable and disable the
mcasp8 module, and to set the gpio output value.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoOMAPDSS: dra7-tpd12s015: lock i2c adapter when using DDC
Tomi Valkeinen [Tue, 26 May 2015 09:59:20 +0000 (12:59 +0300)]
OMAPDSS: dra7-tpd12s015: lock i2c adapter when using DDC

On DRA7 the i2c2 bus is shared between i2c and DDC modes. At the moment
the TPD12S015 driver can switch the muxing at any time, which could lead
to an i2c device getting transfer errors if it is using i2c2 bus.

This patch solves the issue by making TPD12S015 driver use
i2c_lock_adapter() when the pins are in DDC mode.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoOMAPDSS: dra7-tpd12s015: move ddc pixmux to .dts
Tomi Valkeinen [Tue, 26 May 2015 09:59:19 +0000 (12:59 +0300)]
OMAPDSS: dra7-tpd12s015: move ddc pixmux to .dts

We need to do runtime pinmuxing for HDMI, as the HDMI DDC lines are also
used as I2C2 lines. This is currently done in the DRA7 EVM specific
tpd12s015 driver, by writing directly to the pinmux registers.

Remove that hackery by moving the muxing to .dts.

We also need to use a McASP2 pin, which is used as a gpio via McASP2
functionality (i.e. not in GPIO mode). Muxing for this pin is also moved
to .dts, but changing the output value of the pin is still handled in
the driver via direct register writes.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoOMAPDSS: dra7-tpd12s015: remove legacy platform data
Tomi Valkeinen [Tue, 26 May 2015 09:59:18 +0000 (12:59 +0300)]
OMAPDSS: dra7-tpd12s015: remove legacy platform data

The DRA7 specific TPD12S015 driver is neve used with legacy platform
data. So remove the related code.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoASoC: davinci-mcasp: HACK interface to handle dra7-evm's i2c2/HDMI mux
Peter Ujfalusi [Tue, 26 May 2015 09:59:17 +0000 (12:59 +0300)]
ASoC: davinci-mcasp: HACK interface to handle dra7-evm's i2c2/HDMI mux

McASP2_ACLKR pin (in McASP8.AXR2 mode) is used in GPIO mode to control
the mux selection between I2C2 or HDMI.
This patch adds direct interface to handle this:
dra7_mcasp_hdmi_gpio_get() to select GPIO mode with pm_runtime_get
dra7_mcasp_hdmi_gpio_set() to change the GPIO pin state
dra7_mcasp_hdmi_gpio_put() to disable the GPIO mode and pm_runtime_put

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoARM: DTS: dra7-evm: Enable mcasp8
Peter Ujfalusi [Tue, 26 May 2015 09:59:16 +0000 (12:59 +0300)]
ARM: DTS: dra7-evm: Enable mcasp8

McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoARM: DTS: dra7: Add node for McASP8
Peter Ujfalusi [Tue, 26 May 2015 09:59:15 +0000 (12:59 +0300)]
ARM: DTS: dra7: Add node for McASP8

McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoARM: DRA7: hwmod: Add data for McASP8
Peter Ujfalusi [Tue, 26 May 2015 09:59:14 +0000 (12:59 +0300)]
ARM: DRA7: hwmod: Add data for McASP8

McASP8.AXR2 pin is going to be used as GPIO to control the I2C2/HDMI mux
on dra7-evm.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoARM: clk: dra7xx: Correct mcasp8_ahclkx_mux name
Peter Ujfalusi [Tue, 26 May 2015 09:59:13 +0000 (12:59 +0300)]
ARM: clk: dra7xx: Correct mcasp8_ahclkx_mux name

rename the mcasp8_ahclk_mux to mcasp8_ahclkx_mux.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ti.com>
Tested-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoMerge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Tue, 26 May 2015 21:00:14 +0000 (16:00 -0500)]
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y

Pull in couple of minor patches from the remoteproc feature tree,
one is a minor bug fix in PRUSS remoteproc driver, and the other
is a comment correction in OMAP remoteproc driver.

* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/omap: revise the comment about standby in _suspend
  remoteproc/pruss: fix pruss_init return on error

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc/omap: revise the comment about standby in _suspend
Suman Anna [Tue, 26 May 2015 20:39:44 +0000 (15:39 -0500)]
remoteproc/omap: revise the comment about standby in _suspend

The _suspend() function has a TODO comment about implementing a
BIOS-independent hook to send a message to notify the MPU the
completion of the context save on the remoteproc side. This has
been clarified with the SYS/BIOS team now, and this race condition
between the remoteproc saving the context and the MPU waiting for
the sync point before it puts the remote processor into reset, can
never be resolved using a message ACK or a shared memory variable
signalling. So, update the comment appropriately.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc/pruss: fix pruss_init return on error
Felipe Balbi [Tue, 26 May 2015 19:52:56 +0000 (14:52 -0500)]
remoteproc/pruss: fix pruss_init return on error

If the pru_rproc_driver fails to register in pruss_init(),
the failure code should be returned instead of returning 0,
a success value. So, fix the pruss_init() return code
accordingly.

Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integrat...
Dan Murphy [Tue, 26 May 2015 13:23:32 +0000 (08:23 -0500)]
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  usb: host: xhci-pci: Fix NULL pointer dereference error
  ti_config_fragments/connectivity.cfg: disable CONFIG_USB_OTG_WHITELIST

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoMerge branch 'audio-display-ti-linux-3.14.y' of git://git.ti.com/~darrene/ti-linux...
Dan Murphy [Tue, 26 May 2015 12:47:57 +0000 (07:47 -0500)]
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:
  media: ti-vpe: vpe: Fix kernel warning on close

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agousb: host: xhci-pci: Fix NULL pointer dereference error
Kishon Vijay Abraham I [Mon, 25 May 2015 10:43:26 +0000 (16:13 +0530)]
usb: host: xhci-pci: Fix NULL pointer dereference error

commit 5fa63bd959 (usb: xhci: Fix suspend/resume when used
with OTG core) removes assigning xhci->main_hcd from xhci_gen_setup
and adds it in the probe of xhci-plat and xhci-pci.

In the case of xhci-pci, xhci_mem_init is invoked before main_hcd is
initialized in the probe causing a null pointer deferencing error.

Fix it by initializing xhci->main_hcd in xhci_gen_setup and removing
it from xhci_pci_probe().

Fixes: 5fa63bd959cc ("usb: xhci: Fix suspend/resume when used with OTG core")
Acked-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoti_config_fragments/connectivity.cfg: disable CONFIG_USB_OTG_WHITELIST
Sekhar Nori [Thu, 21 May 2015 09:25:51 +0000 (14:55 +0530)]
ti_config_fragments/connectivity.cfg: disable CONFIG_USB_OTG_WHITELIST

CONFIG_USB_OTG_WHITELIST is to be enabled for compliance to OTG
specification. However, on TI SoCs, we only support/test USB
dual-role device, not the full OTG specification.

Moreover, with CONFIG_USB_OTG_WHITELIST enabled, on AM335x
beaglebone black, on connecting a USB webcam we get:

[   74.960459] musb-hdrc musb-hdrc.1.auto: otg: usb_otg_kick_fsm: invalid host/gadget device
[   75.080228] usb 1-1: new high-speed USB device number 4 using musb-hdrc
[   75.270151] usb 1-1: device v03f0 pa707 is not supported
[   75.275670] hub 1-0:1.0: unable to enumerate USB device on port 1

This is because kernel refuses to enumerate peripherals which
are not listed in kernel's OTG whitelist. This is needed for
full compliance with OTG specification.

Disable CONFIG_USB_OTG_WHITELIST since we support only dual-role
device and do not need to reject non-whitelisted devices during
enumeration.

Suggested-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agomedia: ti-vpe: vpe: Fix kernel warning on close
Nikhil Devshatwar [Tue, 19 May 2015 15:29:04 +0000 (20:59 +0530)]
media: ti-vpe: vpe: Fix kernel warning on close

When running a VPE application, if the application is killed suddenly,
STREAMOFF ioctl won't get called and directly close syscall for the
video device is called.

As part of the cleanup process, all of the VPDMA buffers are freed.
Sometimes a kernel warning is printed if the buffers are being freed
before they are unmapped.

Fix this by adding a streamOFF call to each of the CAPTURE AND OUTPUT stream
so that proper cleanup happens, the transaction is finished properly and
all the video buffers / VPDMA buffers are unmapped and freed.

Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agoTI-Integration: usb: musb: fix botched up merge (again)
Sekhar Nori [Thu, 21 May 2015 16:28:58 +0000 (16:28 +0000)]
TI-Integration: usb: musb: fix botched up merge (again)

Merge bc058ac090e8 ("Merge tag 'v3.14.42' of
http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable into
ti-linux-3.14.y") was a botched up merge.

commit df47ad1ce42b ("TI-Integration: Fix merge conflict
on musb_core.c") tried to fix it up but only did it
partially.

commit d0f5c460aac2 ("TI-Integration: Cherry picking this
commit to fix merge issue") tried to finish the job by
cherry-picking commit 889ad3b60f9c ("usb: musb: try a race-free
wakeup") which was the commit introducing code botched up by
original merge.

While  doing this it was missed that a later commit 1007020e37f9
("usb: musb: fix device hotplug behind hub") had made further
fixes which now got reverted due to the cherry-pick. So,
cherry-picking an older commit to fix a bad merge was a bad idea.

This patch finally brings back code to where it should have
been after original merge bc058ac090e8.

Fixes: d0f5c460aac2 ("TI-Integration: Cherry picking this commit to fix merge issue")

Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoMerge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Thu, 21 May 2015 16:00:16 +0000 (11:00 -0500)]
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y

Pull in a minor trace change for the PRUSS remoteproc driver.

* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc/pruss: lower the trace level in pru_rproc_mbox_callback
Suman Anna [Thu, 21 May 2015 15:42:16 +0000 (10:42 -0500)]
remoteproc/pruss: lower the trace level in pru_rproc_mbox_callback

The current virtio rpmsg stack is such that it processes all the
pending messages in the vring on a single interrupt. So, it is
possible to see an empty interrupt without having to process any
messages, especially in cases where there is additional message
message communication that happens in-band within the callback
of a received message while processing it.

This behavior is seen when running the rpmsg_client_sample, and
printing the current trace message in pru_rproc_mbox_callback()
rather frequently, so lower the level of this trace from KERN_ERR
to KERN_DBG.

Reported-by: Jason Reeder <jreeder@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Tue, 19 May 2015 23:32:40 +0000 (18:32 -0500)]
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y

Pull in the updated remoteproc feature branch that adds the runtime
auto-suspend/resume support on the IPU and DSP remote processors
that already support system suspend. Also, includes a minor typo fix.

* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/omap: fix a minor typo in a trace message
  remoteproc/omap: add support for runtime auto-suspend/resume

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc/omap: fix a minor typo in a trace message
Suman Anna [Mon, 18 May 2015 23:27:17 +0000 (18:27 -0500)]
remoteproc/omap: fix a minor typo in a trace message

The omap_mbox_msg_send() is the legacy API for sending a mailbox
message. It has been replaced with the mbox_send_message() from
the mailbox framework, so update the failure trace message
accordingly.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc/omap: add support for runtime auto-suspend/resume
Suman Anna [Wed, 22 Apr 2015 23:57:09 +0000 (18:57 -0500)]
remoteproc/omap: add support for runtime auto-suspend/resume

This patch enhances the PM support in the OMAP remoteproc driver to
support the runtime auto-suspend. A remoteproc may not be required to
be running all the time, and typically will need to be active only
during certain usecases. As such, to save power, it should be turned
off during potential long periods of inactivity between usecases.
This suspend and resume of the device is a relatively heavy process
in terms of latencies, so a remoteproc should be suspended only after
a certain period of prolonged inactivity. The OMAP remoteproc driver
leverages the runtime pm framework's auto_suspend feature to accomplish
this functionality. This feature is automatically enabled when a remote
processor has successfully booted. The 'autosuspend_delay_ms' for each
device dictates the inactivity period/time to wait for before
suspending the device.

The runtime auto-suspend design relies on marking the last busy time
on every communication (virtqueue kick) to and from the remote processor.
When there has been no activity for 'autosuspend_delay_ms' time, the
runtime PM framework invokes the driver's runtime pm suspend callback
to suspend the device. The remote processor will be woken up on the
initiation of the next communication message through the runtime pm
resume callback. The current auto-suspend design also allows a remote
processor to deny a auto-suspend attempt, if it wishes to, by sending a
NACK response to the initial suspend request message sent to the remote
processor as part of the suspend process. The auto-suspend request is
also only attempted if the remote processor is idled and in standby at
the time of inactivity timer expiry. This choice is made to avoid
unnecessary messaging, and the auto-suspend is simply rescheduled to
be attempted again after a further lapse of autosuspend_delay_ms.

The runtime pm callbacks functionality in this patch reuses most of the
core logic from the suspend/resume support code, and make use of an
additional auto_suspend flag to differentiate the logic in common code
from system suspend. The system suspend/resume sequences are also updated
to reflect the proper pm_runtime statuses, and also to really perform a
suspend/resume only if the remoteproc has not been auto-suspended at the
time of request. The remote processor is left in suspended state on a
system resume if it has been auto-suspended before, and will be woken up
only when a usecase needs to run. The other significant change in this
patch is to reset the remoteproc device's pm_domain so as to avoid
conflicts with the ordering sequences in the device pm_domain's runtime
callbacks and the reset management and clock management implemented
within the runtime callbacks in the driver.

The OMAP remoteproc driver currently uses a default value of 10 seconds
for all OMAP remoteprocs, and a different value can be chosen either by
choosing a positive value for the 'autosuspend_delay' in the device's
omap_rproc_fw_data in the driver match data or by updating the
'autosuspend_delay_ms' field at runtime through the sysfs interface.
    Eg: To use 25 seconds for IPU2 on DRA7xx,
      echo 25000 > /sys/bus/platform/devices/55020000.ipu/power/autosuspend_delay_ms

The runtime suspend feature can also be similarly enabled or disabled by
writing 'auto' or 'on' to the device's 'control' power field. The default
is enabled.
    Eg: To disable auto-suspend for IPU2 on DRA7xx SoC,
      echo on > /sys/bus/platform/devices/55020000.ipu/power/control

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoTI-Integration: Cherry picking this commit to fix merge issue
Sebastian Andrzej Siewior [Wed, 22 Oct 2014 20:09:33 +0000 (22:09 +0200)]
TI-Integration: Cherry picking this commit to fix merge issue

Cherry picking this commit to the top of the tree to fix a
merge of the stable that broke this file.  Half of the
issue was the merge conflict resolution the other half
was gits auto merging of the file.

usb: musb: try a race-free wakeup

Attaching a keyboard, using it as a wakeup via
|for f in $(find /sys/devices/ocp.3/47400000.usb -name wakeup)
|do
| echo enabled > $f
|done

going into standby
|  echo standby >  /sys/power/state

and now a wake up by a pressing a key.
What happens is that the system wakes up but the USB device is dead. The
USB stack tries to send a few control URBs but nothing comes back.
Eventually it gaves up and the device remains dead:
|[  632.559678] PM: Wakeup source USB1_PHY
|[  632.581074] PM: noirq resume of devices complete after 21.261 msecs
|[  632.607521] PM: early resume of devices complete after 10.360 msecs
|[  632.616854] net eth2: initializing cpsw version 1.12 (0)
|[  632.704126] net eth2: phy found : id is : 0x4dd074
|[  636.704048] libphy: 4a101000.mdio:00 - Link is Up - 1000/Full
|[  638.444620] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[  653.713435] usb 1-1: device descriptor read/64, error -110
|[  669.093435] usb 1-1: device descriptor read/64, error -110
|[  669.473424] usb 1-1: reset low-speed USB device number 2 using musb-hdrc
|[  684.743436] usb 1-1: device descriptor read/64, error -110
|[  690.065097] PM: resume of devices complete after 57450.744 msecs
|[  690.076601] PM: Finishing wakeup.
|[  690.076627] Restarting tasks ...

It seems that since we got woken up via MUSB_INTR_RESUME the
musb_host_finish_resume() callback is executed before the
resume-callbacks of the PHY and glue layer are invoked. If I delay it
until the glue layer resumed then I don't see this problem.

I also move musb_host_resume_root_hub() into that callback since I don't
see any reason in doing anything resume-link if there are still pieces
not restored.

Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
Conflicts:
drivers/usb/musb/musb_core.c

5 years agoMerge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux...
Texas Instruments Auto Merger [Mon, 18 May 2015 17:16:04 +0000 (12:16 -0500)]
Merge branch 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg into ti-linux-3.14.y

TI-Feature: rpmsg
TI-Tree: git://git.ti.com/rpmsg/rpmsg.git
TI-Branch: rpmsg-ti-linux-3.14.y

* 'rpmsg-ti-linux-3.14.y' of git://git.ti.com/rpmsg/rpmsg:
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: DRA7: Add standby info for IPU & DSPs
  ARM: dts: OMAP5: Add standby info for IPU and DSP
  ARM: dts: OMAP4: Add standby info for IPU and DSP
  Documentation: dt: update omap remoteproc binding for suspend
  remoteproc/omap: use consistent match data structures for all SoCs
  iommu/omap: add support for runtime auto suspend/resume
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: introduce new API for suspend/resume
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle
  mailbox/omap: check for any unread messages during suspend
  mailbox/omap: add support for suspend/resume
  mailbox/omap: store mailbox interrupt type in omap_mbox_device

Signed-off-by: Texas Instruments Auto Merger <lcpd_integration@list.ti.com>
5 years agoMerge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg...
Suman Anna [Mon, 18 May 2015 16:13:27 +0000 (11:13 -0500)]
Merge branch 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc into rpmsg-ti-linux-3.14.y

Pull in the updated remoteproc feature branch that adds the support for
system suspend/resume for the IPU and DSP remote processors on OMAP4, OMAP5
and DRA7 (only IPUs). The feature branch also pulls in automatically the
dependent mailbox and iommu feature branches with suspend/resume support.

* 'rproc-linux-3.14.y' of git://git.ti.com/rpmsg/remoteproc:
  remoteproc/omap: add support for system suspend/resume
  ARM: dts: DRA7: Add standby info for IPU & DSPs
  ARM: dts: OMAP5: Add standby info for IPU and DSP
  ARM: dts: OMAP4: Add standby info for IPU and DSP
  Documentation: dt: update omap remoteproc binding for suspend
  remoteproc/omap: use consistent match data structures for all SoCs
  iommu/omap: add support for runtime auto suspend/resume
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: introduce new API for suspend/resume
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle
  mailbox/omap: check for any unread messages during suspend
  mailbox/omap: add support for suspend/resume
  mailbox/omap: store mailbox interrupt type in omap_mbox_device

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoTI-Integration: Fix merge conflict on musb_core.c
Dan Murphy [Mon, 18 May 2015 16:08:42 +0000 (11:08 -0500)]
TI-Integration: Fix merge conflict on musb_core.c

Fix merge conflict resolution on musb_core.c file
where the hard coded time out delayed was taken
over the defined delay that was introduced in patch

889ad3b60f9c5f9cf6bd722603ed63d75a83af27
usb: musb: try a race-free wakeup

Signed-off-by: Dan Murphy <dmurphy@ti.com>
5 years agoremoteproc/omap: add support for system suspend/resume
Suman Anna [Wed, 22 Apr 2015 23:57:09 +0000 (18:57 -0500)]
remoteproc/omap: add support for system suspend/resume

This patch adds the support for system suspend/resume to the
OMAP remoteproc driver so that the OMAP remoteproc devices can
be suspended/resumed during a system suspend/resume. The support
is added through the driver PM .suspend/.resume callbacks, and
requires appropriate support from the OS running on the remote
processors.

The IPU & DSP remote processors typically have their own private
modules like registers, internal memories, caches etc. The context
of these modules need to be saved and restored properly for a
suspend/resume to work. There are in general not accessible from
the MPU, so the remote processors themselves have to implement
the logic for the context save & restore of these modules.

The OMAP remoteproc driver initiates a suspend by sending a mailbox
message requesting the remote processor to save its context and
enter into an idle/standby state. The remote processor should
usually stop whatever processing it is doing to switch to a context
save mode. The OMAP remoteproc driver detects the completion of
the context save by checking the module standby status for the
remoteproc device. It also stops any resources used by the remote
processors like the timers. The timers need to be running only when
when the processor is active and executing, and need to be stopped
otherwise to allow the timer driver to reach low-power states. The
IOMMUs are also suspended by the remoteproc driver, and the suspend
process is completed by putting the remote processors into reset,
after which the Linux kernel can put the domain into further lower
power states as possible.

The resume sequence undoes the operations performed in the PM suspend
callback, by restoring the IOMMUs, starting the timers and finally
releasing the processors from reset. This requires that the remote
processor side OS be able to distinguish a power-resume boot from a
power-on/cold boot, restore the context of its private modules saved
during the suspend phase, and resume executing code from where it
was suspended.

The remote processors should save their context into System RAM (DDR),
as any internal memories are not guaranteed to retain context as it
depends on the lowest power domain that the remote processor device\
is put into. The management of the DDR contents will be managed by
the Linux kernel.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integrat...
Dan Murphy [Mon, 18 May 2015 14:56:53 +0000 (09:56 -0500)]
Merge branch 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel into ti-linux-3.14.y

TI-Feature: connectivity
TI-Tree: git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel.git
TI-Branch: connectivity-ti-linux-3.14.y

* 'connectivity-ti-linux-3.14.y' of git://git.ti.com/connectivity-integration-tree/connectivity-ti-linux-kernel:
  ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
  extcon: palmas: Support GPIO based USB ID detection
  usb: gadget: use $(srctree) instead of $(PWD) for includes

Signed-off-by: Dan Murphy <DMurphy@ti.com>
5 years agoARM: dts: am57xx-beagle-x15: use palmas-usb for USB2
Roger Quadros [Wed, 13 May 2015 11:02:15 +0000 (14:02 +0300)]
ARM: dts: am57xx-beagle-x15: use palmas-usb for USB2

The VBUS line of USB2 is connected to VBUS detect logic on
the PMIC. Use the palmas-usb driver to report VBUS events
to the USB driver.

As the palmas-usb driver supports GPIO based ID reporting
provide the GPIO for ID pin as well.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoextcon: palmas: Support GPIO based USB ID detection
Roger Quadros [Wed, 13 May 2015 11:02:14 +0000 (14:02 +0300)]
extcon: palmas: Support GPIO based USB ID detection

Some palmas based chip variants do not have OTG based ID logic.
For these variants we rely on GPIO based USB ID detection.

These chips do have VBUS comparator for VBUS detection so we
continue to use the old way of detecting VBUS.

Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agousb: gadget: use $(srctree) instead of $(PWD) for includes
Yegor Yefremov [Wed, 13 May 2015 17:09:20 +0000 (13:09 -0400)]
usb: gadget: use $(srctree) instead of $(PWD) for includes

[ Upstream commit fa31409a82ee050e52caad9e4c483fe3edca163a ]

Using $(PWD) breaks builds when make was invoked from outside
of the kernel tree.

Signed-off-by: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Jacob Stiffler <j-stiffler@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoARM: dts: DRA7: Add standby info for IPU & DSPs
Suman Anna [Thu, 14 May 2015 03:32:51 +0000 (22:32 -0500)]
ARM: dts: DRA7: Add standby info for IPU & DSPs

Add the data for the "ti,rproc-standby-info" property for all
the DSP and IPU remoteproc processor nodes on DRA7xx family of
SoCs. This data is same for all DRA7 boards, and is required
by the OMAP remoteproc driver to implement suspend/resume for
the IPU & DSP remoteproc devices on DRA7 SoCs.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: dts: OMAP5: Add standby info for IPU and DSP
Suman Anna [Thu, 14 May 2015 03:29:54 +0000 (22:29 -0500)]
ARM: dts: OMAP5: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes, applicable to
all OMAP5 boards. This is required by the OMAP remoteproc
driver to implement suspend/resume for the OMAP5 remoteproc
devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoARM: dts: OMAP4: Add standby info for IPU and DSP
Suman Anna [Thu, 14 May 2015 03:28:56 +0000 (22:28 -0500)]
ARM: dts: OMAP4: Add standby info for IPU and DSP

Add the data for the "ti,rproc-standby-info" property for
the DSP and IPU remoteproc processor nodes. This data is
common to all OMAP4 boards, and is required by the OMAP
remoteproc driver to implement suspend/resume for the OMAP4
remoteproc devices.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoDocumentation: dt: update omap remoteproc binding for suspend
Suman Anna [Thu, 14 May 2015 03:55:25 +0000 (22:55 -0500)]
Documentation: dt: update omap remoteproc binding for suspend

The OMAP remoteproc binding has been updated to add an additional
property, "ti,rproc-standby-info". The property is used to define
the standby register address required by the OMAP remoteproc driver
to check that a remote proessor has entered standby and ready to
be suspended during a system suspend or a runtime auto-suspend of
the corresponding remoteproc device.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoremoteproc/omap: use consistent match data structures for all SoCs
Suman Anna [Thu, 9 Apr 2015 01:26:53 +0000 (20:26 -0500)]
remoteproc/omap: use consistent match data structures for all SoCs

The OMAP remoteproc code currently stores the firmware names directly
in the match data fields for the OMAP4 & OMAP5 SoCs, while a separate
data structure (omap_rproc_fw_data) containing the device name and
firmware name is used for the processors on DRA7xx SoC family.

Switch the OMAP4 and OMAP5 SoCs also to use the same style as DRA7
SoCs for consistency. This also allows to easily add additional data
fields to this structure in the future if needed.

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux...
Suman Anna [Mon, 18 May 2015 02:03:33 +0000 (21:03 -0500)]
Merge branch 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu into rproc-linux-3.14.y

Merge in the updated iommu feature branch into remoteproc tree to
pull in the suspend/resume support in the OMAP IOMMU driver. The
following are the main changes:
    - improvements in the OMAP iommu to perform the enabling &
      disabling of the IOMMU from within the runtime pm callbacks
    - two new API that needs to be invoked from the OMAP remoteproc
      driver to suspend/resume the IOMMU.
    - locked TLB save & restore logic
    - add needed pdata quirks to all supported IOMMUs

* 'iommu-linux-3.14.y' of git://git.ti.com/rpmsg/iommu:
  iommu/omap: add support for runtime auto suspend/resume
  iommu/omap: add logic to save/restore locked TLBs
  iommu/omap: introduce new API for suspend/resume
  iommu/omap: streamline enable/disable through runtime pm callbacks
  ARM: OMAP2+: add pdata-quirks for OMAP3 ISP IOMMU
  ARM: OMAP2+: Add iommu pdata-quirks for DRA7 DSP EDMA MMUs
  ARM: OMAP2+: plug in device_enable/idle ops for IOMMUs
  iommu/omap: add pdata ops for omap_device_enable/idle

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoMerge branch 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox into rproc...
Suman Anna [Mon, 18 May 2015 01:59:23 +0000 (20:59 -0500)]
Merge branch 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox into rproc-linux-3.14.y

Pull in the updated mailbox feature branch into the remoteproc tree,
this includes the suspend/resume support in the OMAP mailbox driver.

* 'mailbox-linux-3.14.y' of git://git.ti.com/rpmsg/mailbox:
  mailbox/omap: check for any unread messages during suspend
  mailbox/omap: add support for suspend/resume
  mailbox/omap: store mailbox interrupt type in omap_mbox_device

Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoiommu/omap: add support for runtime auto suspend/resume
Suman Anna [Tue, 12 May 2015 19:11:43 +0000 (14:11 -0500)]
iommu/omap: add support for runtime auto suspend/resume

This patches adds the support for the OMAP IOMMUs to be suspended
during the auto suspend/resume of the OMAP remoteproc devices. The
remote processors are auto suspended after a certain time of idle
or inactivity period. This is done by extending the suspend/resume
API added with an additional flag to indicate the auto-suspend.
The runtime auto-suspend simply decrements and increments the
runtime usage count of the IOMMU devices and let the context be
saved/restored using the existing runtime pm callbacks.

Signed-off-by: Suman Anna <s-anna@ti.com>