android-sdk/kernel-video.git
5 years agoRevert "ARM: OMAP: DRA7: change IPU1 clk domain to SWSUP for proper boot" glsdk-7.01.00.03
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.

Change-Id: Id6d219f4d275c2c1f34e478c8303fb3181aa6553
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>
Conflicts:

arch/arm/mach-omap2/pdata-quirks.c

Change-Id: I1dffc3aa72d7bd2d6c00305a1781b795711d0819
Signed-off-by: Angela Stegmaier <angelabaker@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>
Conflicts:

drivers/iommu/omap-iommu.c
drivers/iommu/omap-iommu.h

Change-Id: Ib81ea12d2dd0ad4469f6b070b7acb1fb6e8000cb
Signed-off-by: Angela Stegmaier <angelabaker@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

Change-Id: I6782de1034fb2d9f3cd25aa6ca5ca1d9de180f65
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agomedia: i2c: tvp5158: Correct enum_fmt implementation
Nikhil Devshatwar [Thu, 25 Jun 2015 09:41:10 +0000 (15:11 +0530)]
media: i2c: tvp5158: Correct enum_fmt implementation

TVP5158 analog camera decode can only generate BT656 standard video.
Which is in UYVY medibus format.
But the enum_fmt subdev ioctl returns YUYV as the mbus format.
Correct this behavior and also correct the enum_fmt ioctl such that
it returns the correct mbus format based on the index passed.

Change-Id: I93870e7f399c97fb8c56aa17919c11e2057c135a
Signed-off-by: Nikhil Devshatwar <nikhil.nd@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.

Change-Id: I3d8c932455fac75cee8f247b80ea7d9df028d4e1
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@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).

Change-Id: I2f37b5514f9546b41f09c6bd198534b3482945d0
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@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.

Change-Id: I78bc8a3fc92562d21cb6d8e9f50ed162f8c94dd8
Signed-off-by: Benoit Parrot <bparrot@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@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.

Change-Id: Ib3f42d4decdc54ff332e813d54004cbf5f8c3b22
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Jyri Sarha <jsarha@ti.com>
5 years agotemp: media: ti-vpe: vip: Fix YUYV VPDMA format
Nikhil Devshatwar [Wed, 24 Jun 2015 09:56:29 +0000 (15:26 +0530)]
temp: media: ti-vpe: vip: Fix YUYV VPDMA format

VPDMA format for YUYV is not correct (even after the errata fix).
Fix the VPDMA format for YUYV capture in VIP driver.
Note that this change does not address the VPDMA errata.

The real fix would involve changing the definitions of the VPDMA data types
and correspondingly, update the VIP and VPE drivers.

This fix only corrects the YUYV so that the YUYV and NV12 capture works fine.

Change-Id: Ia5b3572f1d33287e81dcc6ced0137b2435099837
Signed-off-by: Nikhil Devshatwar <nikhil.nd@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 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 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: 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 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 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 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")

Change-Id: I963afaa6bd56e71ad845f3a1cb409f7bef426228
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>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
5 years agoserial: 8250: Prevent dead lock in serial transfer
John Ogness [Mon, 22 Jun 2015 13:37:06 +0000 (19:07 +0530)]
serial: 8250: Prevent dead lock in serial transfer

uart_write_wakeup function expects to be called
with uart_lock unlocked but serial8250_tx_chars
calls the function with lock acquired.

Also make sure that we disable interrupts if already
enabled during the call to wakeup.

Change-Id: Ib6e3302af3a4175849df95c7871e591c7a4109c5
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
5 years agoti_config_fragments/auto.cfg: adding cmdline bootargs for qspi bootmode
Ravi Babu [Fri, 5 Jun 2015 09:14:43 +0000 (14:44 +0530)]
ti_config_fragments/auto.cfg: adding cmdline bootargs for qspi bootmode

override the kernel default cmdline bootargs with
auto-specific for dra7xx platform. This is needed to
pass bootargs during single stage boot-mode for qspi.

In qspi single stage boot  mode, MLO/u-boot, kernel/dtb are
stored in qspi partition. The execution flow is
ROM->QSPI(MLO)->QSPI(kernel/dtb), filesystem at eMMC/SD.

Change-Id: I09db8451966419e22992e3ff53a3f8920189feb3
Signed-off-by: Ravi Babu <ravibabu@ti.com>
[removed earlyprintk option]
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
5 years agommc: omap_hsmmc: fixed intense insertion/removal card enumeration failure
Vignesh R [Thu, 21 May 2015 10:48:47 +0000 (16:18 +0530)]
mmc: omap_hsmmc: fixed intense insertion/removal card enumeration failure

Add iadditional clean up function to omap_hsmmc_detect when
a card is remove during an ongoing transfer.

Change-Id: I024e635f11de930427c96eb569cc903966478418
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Ravikumar Kattekola <rk@ti.com>
5 years agoMerge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android...
Praneeth Bajjuri [Fri, 19 Jun 2015 20:12:20 +0000 (15:12 -0500)]
Merge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio into p-ti-linux-3.14.y-common

* 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio:
  ALSA: pcm_dmaengine: Run complete cb only if runtime check passes

Change-Id: Ia60759a3501112b2e490243f32ad360798e6984f
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
5 years agoALSA: pcm_dmaengine: Run complete cb only if runtime check passes
Misael Lopez Cruz [Wed, 20 May 2015 06:26:50 +0000 (01:26 -0500)]
ALSA: pcm_dmaengine: Run complete cb only if runtime check passes

The DMA complete callback uses substream's runtime data, so make
sure the runtime check passes before going forward.

The callback could run while the stream is closing or after it's
already closed.  By then, the substream's runtime data might already
been freed and cause NULL pointer dereferences.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: dts: DRA7: i845: enable fix for false disconnect for usb2phy
Ravi Babu [Thu, 18 Jun 2015 11:07:06 +0000 (16:37 +0530)]
ARM: dts: DRA7: i845: enable fix for false disconnect for usb2phy

Enable the workaround for false detection of disconnect
condition i845 on usb2 instance for dra7xx platform.

Reduce the sensitivity of internal USB2PHY by enabling the
DISCON_BYP_LATCH of the USB2PHY_ANA_CONFIG1 register. This
resolves issues with certain devices which can otherwise
be prone to false disconnects

This fixes the issue where specific usb stick does not
get enumerate on usb2 port but works on PC and other
embedded platform. Enabling this Workaround fixes the issue.

Change-Id: I66f109a7a907a4ab0dff57755e19bf0cedeadf2e
Signed-off-by: Ravi Babu <ravibabu@ti.com>
5 years agophy: usb2: add compatible documentation binding for dra7x/am437x/omap5 Soc
Ravi Babu [Thu, 18 Jun 2015 13:36:34 +0000 (19:06 +0530)]
phy: usb2: add compatible documentation binding for dra7x/am437x/omap5 Soc

add the compatible documentation binding for usb2phy for
dra7x, am437x and omap5 platforms.

Change-Id: Ib16184e6ed7e021fbdd2771422848113e09b0fff
Signed-off-by: Ravi Babu <ravibabu@ti.com>
5 years agoARM: dts: dra72-evm: update wlan irq pinmux
Vishal Mahaveer [Thu, 4 Jun 2015 15:59:58 +0000 (10:59 -0500)]
ARM: dts: dra72-evm: update wlan irq pinmux

Update pinmux entry for WLAN IRQ GPIO.

Change-Id: I1fa2ece040cb4ade189a6382edfed7264c9cf682
Signed-off-by: Vishal Mahaveer <vishalm@ti.com>
5 years agomedia: ti-vpe: vpe: Add cropping ioctl support
Archit Taneja [Thu, 19 Dec 2013 09:35:31 +0000 (15:05 +0530)]
media: ti-vpe: vpe: Add cropping ioctl support

Add crop ioctl ops. For VPE, cropping only makes sense with the input to VPE, or
the V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE buffer type.

For the CAPTURE type, a S_CROP ioctl results in setting the crop region as the
whole image itself, hence making crop dimensions same as the pix dimensions.

Setting the crop successfully should result in re-configuration of those
registers which are affected when either source or destination dimensions
change, set_srcdst_params() is called for thist purpose.

Some standard crop parameter checks are done in __vpe_try_crop().

Change-Id: I9329dee27db526bde54000552b1184e8f061244f
Signed-off-by: Archit Taneja <archit@ti.com>
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
5 years agomedia: vb2: verify data_offset only if nonzero bytesused
Nikhil Devshatwar [Thu, 19 Jun 2014 09:56:37 +0000 (15:26 +0530)]
media: vb2: verify data_offset only if nonzero bytesused

verify_planes would fail if the user space fills up the data_offset field
and bytesused is left as zero. Correct this.
When comparing data_offset > bytesused, bypass the check if the
bytesused field is set to zero.

Change-Id: I4c63bc03f6d455ce00a56d63df08c624579bc831
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
5 years agoMerge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android...
Praneeth Bajjuri [Fri, 5 Jun 2015 21:05:55 +0000 (16:05 -0500)]
Merge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio into p-ti-linux-3.14.y-common

* 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio: (21 commits)
  ARM: dts: dra7*-evm: Enable McASP3 DAT port and AFIFO
  ARM: dts: DRA7: Use eDMA for McASP3
  ARM: dts: DRA7: Add eDMA and eDMA xbar nodes
  ARM: dts: DRA7: Update sDMA xbar to new mechanism
  ARM: DRA7: hwmod: Add data for eDMA tpcc, tptc0, tptc1
  ARM: edma: Mark xbar related channels as used
  ASoC: davinci-mcasp: Register eDMA platform driver for DRA7xx
  dmaengine: ti-dma-crossbar: Add support for eDMA xbar
  dmaengine: ti-dma-crossbar: Make idr xbar instance-specific
  dmaengine: Add driver for TI DMA crossbar on DRA7x
  dmaengine: omap-dma: Reduce the number of virtual channels
  dmaengine: omap-dma: Remove mapping between virtual channels and requests
  dmaengine: omap-dma: Take DMA request number from DT if it is available
  dmaengine: omap-dma: Use defines for dma channels and request count
  Documentation: devicetree: dma: Binding documentation for TI DMA crossbar
  dmaengine: of_dma: Support for DMA routers
  Revert "drivers: dma: omap-dma: Avoid hard-coding of the dma-request channels"
  Revert "drivers: dma: omap-dma: Add a seperate xlate function to get router data"
  Revert "drivers: omap-dma: Add crossbar line as a resource to omap_chan structure"
  Revert "drivers: dma: Add dma crossbar driver"
  ...

Change-Id: Idf3b559692a62ca766040a683b6ce3eed8a5ff7a
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
5 years agoARM: dts: dra7*-evm: Enable McASP3 DAT port and AFIFO
Misael Lopez Cruz [Tue, 26 May 2015 04:34:09 +0000 (23:34 -0500)]
ARM: dts: dra7*-evm: Enable McASP3 DAT port and AFIFO

Now that McASP3 is using eDMA, the DAT port and AFIFO can
be safely enabled.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: dts: DRA7: Use eDMA for McASP3
Misael Lopez Cruz [Tue, 26 May 2015 04:22:59 +0000 (23:22 -0500)]
ARM: dts: DRA7: Use eDMA for McASP3

McASP3 does not support constant addressing mode on the DAT
port, so increment transfers must be used instead.  This
restriction is also applicable for McASP1 and McASP2.

This DMA addressing constraint poses a major problem for sDMA
where constant addressing mode is used on the peripheral side.
Unfortunately, using increment transfers in sDMA comes with
important side effects.

The addressing mode used in eDMA is INC, so above silicon
limitation doesn't have any impact.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: dts: DRA7: Add eDMA and eDMA xbar nodes
Misael Lopez Cruz [Tue, 26 May 2015 04:15:07 +0000 (23:15 -0500)]
ARM: dts: DRA7: Add eDMA and eDMA xbar nodes

Add the devicetree nodes for the eDMA and the eDMA
crossbar.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: dts: DRA7: Update sDMA xbar to new mechanism
Misael Lopez Cruz [Tue, 26 May 2015 04:09:17 +0000 (23:09 -0500)]
ARM: dts: DRA7: Update sDMA xbar to new mechanism

Migrate sDMA crossbar related properties to the new
dra7-dma-crossbar mechanism.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: DRA7: hwmod: Add data for eDMA tpcc, tptc0, tptc1
Misael Lopez Cruz [Tue, 26 May 2015 04:12:19 +0000 (23:12 -0500)]
ARM: DRA7: hwmod: Add data for eDMA tpcc, tptc0, tptc1

Add hwmod data for the eDMA blocks:
 - TPCC: Third-party channel controller
 - TPTC0: Third-party transfer controller 0
 - TPTC1: Third-party transfer controller 1

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: edma: Mark xbar related channels as used
Misael Lopez Cruz [Tue, 26 May 2015 03:38:58 +0000 (22:38 -0500)]
ARM: edma: Mark xbar related channels as used

eDMA channels not being used in the platform are assumed to
be without event association.  The ones detected as 'used'
are those from DT nodes whose "dmas" property have a direct
reference to the eDMA controller node.

However, when a DMA crossbar is present the "dmas" property
actually points to the crossbar node, not to the DMA controller.
The DMA crossbar related channels can be identified in the
controller's translation function and marked as 'used' in
the platform.

Due to the current direct mapping between DMA requests and eDMA
channels, it's possible that the DMA channel corresponding to
the crossbar-translated DMA request might have been already
taken by another client.  The conflict might occur if such
client uses memcpy transfer type.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoASoC: davinci-mcasp: Register eDMA platform driver for DRA7xx
Misael Lopez Cruz [Tue, 26 May 2015 04:18:07 +0000 (23:18 -0500)]
ASoC: davinci-mcasp: Register eDMA platform driver for DRA7xx

McASP in DRA7xx SoC family (VERSION_4) can use either sDMA
or eDMA.  In order to be able to use either DMA controller
make sure their corresponding platform driver is registered.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agodmaengine: ti-dma-crossbar: Add support for eDMA xbar
Misael Lopez Cruz [Tue, 26 May 2015 03:34:06 +0000 (22:34 -0500)]
dmaengine: ti-dma-crossbar: Add support for eDMA xbar

eDMA crossbar works exactly the same way as sDMA, but sDMA
requires an offset of 1, while no offset is needed for eDMA.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agodmaengine: ti-dma-crossbar: Make idr xbar instance-specific
Misael Lopez Cruz [Tue, 26 May 2015 03:54:04 +0000 (22:54 -0500)]
dmaengine: ti-dma-crossbar: Make idr xbar instance-specific

In preparation for supporting multiple DMA crossbar instances,
make the idr xbar instance specific.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agodmaengine: Add driver for TI DMA crossbar on DRA7x
Peter Ujfalusi [Thu, 9 Apr 2015 09:35:49 +0000 (12:35 +0300)]
dmaengine: Add driver for TI DMA crossbar on DRA7x

[ Upstream commit a074ae38f859b90bd259f5df43784834b44412d1 ]

The DRA7x has more peripherals with DMA requests than the sDMA can handle:
205 vs 127. All DMA requests are routed through the DMA crossbar, which can
be configured to route selected incoming DMA requests to specific sDMA
request.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
5 years agodmaengine: omap-dma: Reduce the number of virtual channels
Peter Ujfalusi [Thu, 9 Apr 2015 09:35:53 +0000 (12:35 +0300)]
dmaengine: omap-dma: Reduce the number of virtual channels

[ Upstream commit 8a32222693af0edf4ad0ed2c6c4c9e383fd922dd ]

Since the mapping between the hardware request lines and channels has been
removed it no longer make sense to have too many channels.
Set the number of channels to match with the number of logical channels
supported by sDMA.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
5 years agodmaengine: omap-dma: Remove mapping between virtual channels and requests
Peter Ujfalusi [Thu, 9 Apr 2015 09:35:52 +0000 (12:35 +0300)]
dmaengine: omap-dma: Remove mapping between virtual channels and requests

[ Upstream commit eea531ea4147f60708c7ee9e53b5735ec387adb6 ]

Do not direct map the virtual channels to sDMA request number. When the
sDMA is behind of a crossbar this direct mapping can cause situations when
certain channel can not be requested since the crossbar request number
will no longer match with the sDMA request line.
The direct mapping for virtual channels with HW request lines will make it
harder to implement MEM_TO_MEM mode for the driver.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
5 years agodmaengine: omap-dma: Take DMA request number from DT if it is available
Peter Ujfalusi [Thu, 9 Apr 2015 09:35:51 +0000 (12:35 +0300)]
dmaengine: omap-dma: Take DMA request number from DT if it is available

[ Upstream commit de506089e78bc7cea77c64a836f6cfc7fa592219 ]

Use the dma-requests property from DT to get the number of DMA requests.
In case of legacy boot or failure to find the property, use the default
127 as number of requests.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
5 years agodmaengine: omap-dma: Use defines for dma channels and request count
Peter Ujfalusi [Thu, 9 Apr 2015 09:35:50 +0000 (12:35 +0300)]
dmaengine: omap-dma: Use defines for dma channels and request count

[ Upstream commit 341ce712868d90fd68cc4635b7c9963a026f9207 ]

Instead of magic numbers in the code, use define for number of logical DMA
channels and DMA requests.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
5 years agoDocumentation: devicetree: dma: Binding documentation for TI DMA crossbar
Peter Ujfalusi [Thu, 9 Apr 2015 09:35:48 +0000 (12:35 +0300)]
Documentation: devicetree: dma: Binding documentation for TI DMA crossbar

[ Upstream commit 73f67d35b5b96eaf6c5d90fc10527c15b135eda2 ]

The DRA7x has more peripherals with DMA requests than the sDMA can handle:
205 vs 127. All DMA requests are routed through the DMA crossbar, which can
be configured to route selected incoming DMA requests to specific request
line of the DMA controller.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
5 years agodmaengine: of_dma: Support for DMA routers
Peter Ujfalusi [Thu, 9 Apr 2015 09:35:47 +0000 (12:35 +0300)]
dmaengine: of_dma: Support for DMA routers

[ Upstream commit 56f13c0d9524c5816f5dc9c91b9d766d6b1064ca ]

DMA routers are transparent devices used to mux DMA requests from
peripherals to DMA controllers. They are used when the SoC integrates more
devices with DMA requests then their controller can handle.
DRA7x is one example of such SoC, where the sDMA can hanlde 128 DMA request
lines, but in SoC level it has 205 DMA requests.

The of_dma_router will be registered as of_dma_controller with special
xlate function and additional parameters. The driver for the router is
responsible to craft the dma_spec (in the of_dma_route_allocate callback)
which can be used to requests a DMA channel from the real DMA controller.
This way the router can be transparent for the system while remaining generic
enough to be used in different environments.

Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
5 years agoRevert "drivers: dma: omap-dma: Avoid hard-coding of the dma-request channels"
Misael Lopez Cruz [Wed, 13 May 2015 22:15:31 +0000 (17:15 -0500)]
Revert "drivers: dma: omap-dma: Avoid hard-coding of the dma-request channels"

This reverts commit 732de18cbd4cc7f1b03ed26790ef4e4868d98f16.

5 years agoRevert "drivers: dma: omap-dma: Add a seperate xlate function to get router data"
Misael Lopez Cruz [Wed, 13 May 2015 22:15:21 +0000 (17:15 -0500)]
Revert "drivers: dma: omap-dma: Add a seperate xlate function to get router data"

This reverts commit 6e4c8621eb1a69c015ceb2a0d9589dd24fa5b01e.

5 years agoRevert "drivers: omap-dma: Add crossbar line as a resource to omap_chan structure"
Misael Lopez Cruz [Wed, 13 May 2015 22:15:08 +0000 (17:15 -0500)]
Revert "drivers: omap-dma: Add crossbar line as a resource to omap_chan structure"

This reverts commit bcda43ed1153d6701a97ba72313c59d0fdab14ac.

5 years agoRevert "drivers: dma: Add dma crossbar driver"
Misael Lopez Cruz [Wed, 13 May 2015 22:15:02 +0000 (17:15 -0500)]
Revert "drivers: dma: Add dma crossbar driver"

This reverts commit 4abc176c4500b580d19e03e5c7c6bb9efbc85be5.

5 years agoRevert "drivers: dma: of-dma: Add support for dma-request line routers"
Misael Lopez Cruz [Wed, 13 May 2015 22:02:20 +0000 (17:02 -0500)]
Revert "drivers: dma: of-dma: Add support for dma-request line routers"

This reverts commit dd5cdc95cd8de84150f65732dccbf59b73488a05.

5 years agodrm: remove automatic load of omapdrm_pvr
Anand Balagopalakrishnan [Wed, 28 Jan 2015 12:06:12 +0000 (17:36 +0530)]
drm: remove automatic load of omapdrm_pvr

omapdrm plugin patch automatically tries to load the SGX (omapdrm_pvr) kernel
module as part of dev_open. The name of SGX kernel module in Android is
pvrsrvkm.

This patch removes the auto-load of omapdrm_pvr kernel module to ensure common
code base across Linux and Android.

Change-Id: I03d7e92b9e6f9addd41e83614e8878d8cfc244b7
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
5 years agodrm/omap: Add omapdrm plugin API
Rob Clark [Thu, 4 Dec 2014 11:09:35 +0000 (16:39 +0530)]
drm/omap: Add omapdrm plugin API

This work is based on Rob Clark's patch :
http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=commit;h=6a42bc1660b06464f9da796604ecd4934bb31acd
WIP: drm/omap: V2: add plugin API
from the GLP kernel tree available at
http://dev.omapzoom.org/?p=integration/kernel-ubuntu.git;a=summary

Omapdrm is fixed so that it can accept plugins.
Plugin add functions like load/unload etc are added in omap_drv.c
In omap_gem.c GEM object mapping functions has been added

This patch is required for gfx driver to be built as a drm plugin

Subhajit : k3.12: removed const from ioctls table
Anand : k3.14 : rebased with LCPD baseline

Signed-off-by: Rob Clark <rob@ti.com>
Signed-off-by: Subhajit Paul <subhajit_paul@ti.com>
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
Conflicts:

drivers/gpu/drm/omapdrm/omap_drv.c
drivers/gpu/drm/omapdrm/omap_drv.h

Change-Id: I72133ad08ddd4682320fa2e7f5f4dd017ee92dae
Signed-off-by: Anand Balagopalakrishnan <anandb@ti.com>
5 years agoARM: dts: dra7xx-jamr3: Reserve memory for RingIO SR0
Kishor Jm [Wed, 27 May 2015 15:53:52 +0000 (10:53 -0500)]
ARM: dts: dra7xx-jamr3: Reserve memory for RingIO SR0

Reserve 1MB for RingIO SR0.

Change-Id: Ie1af67266e61f3eb8ad69ea4a3b8bda3a66f7ebf
Signed-off-by: Kishor Jm <kishor.jinde@ti.com>
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: dts: DRA7: add a new dts file to support late attach on IPU2
Amarinder Bindra [Tue, 1 Jul 2014 09:05:35 +0000 (14:35 +0530)]
ARM: dts: DRA7: add a new dts file to support late attach on IPU2

The 'late attach' functionality has the remote processors configured,
programmed and booted even before the kernel is booted. This includes
loading the necessary firmware into memory, programming the IOMMU,
configuring the required timers, and programming the corresponding
device's clocks and resets.

The omap hwmod init sequence includes resetting all the hwmods and
idling them to put the devices in sane states to make them independent
of bootloader and corresponding drivers. The "ti,no-idle-on-init" and
"ti,no-reset-on-init" attributes are added to specific omap_hwmod's
associated with the IPU2 processor subsystems to support the 'late
attach' feature on these devices, and change the omap hwmod init
behavior.

The "ti,no-reset-on-init" attribute is needed to allow the omap_hwmod
layer to not perform a reset (and thereby reset the programming done
prior to kernel boot). The "ti,no-reset-on-init" is needed to leave the
modules/device in enabled state (and thereby avoid any disabling of the
clocks/modules).

The "ti,late-attach" attribute indicates that the remotecore has already
been loaded and configured and IPU2, MMU_IPU2 and the timers should not
be reconfigured or reset.

These attributes are added in a separate dts file, and includes the
original dts file so that the default configuration stays untouched.
The user can switch the regular dtb file to the dtb generated from
this file to enable the "late attach" functionality.

TODO:
Evaluate if setting of the right attributes for late attach can be achieved
directly from the boot loader. If so, the need for maintaining a separate
dts file for normal operation and 'late attach' operation can be eliminated.

Change-Id: I5c5526816fe94fc80077fcf2554c8cf940b7aaac
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
5 years agoremoteproc/omap: add "late attach" support
Venkateswara Rao Mandela [Tue, 20 Jan 2015 10:21:21 +0000 (15:51 +0530)]
remoteproc/omap: add "late attach" support

Add the necessary support in the OMAP remoteproc driver to enable the
"late attach" functionality. The 'late attach' functionality has the
processors already loaded and running by the time the kernel has booted.

The 'late attach' support in OMAP remoteproc driver is added through
minimal changes like skipping the releasing of the processor reset.
The processor reset is skipped as this relies on the omap_hwmod /
omap_device API which perform a module disable/enable sequence in
addition to the reset programming. Other required functionality is
achieved through the late attach support in the remoteproc driver core.

During late attach, we use non-zeroing dma ops to prevent the kernel
from overwriting already loaded code and data segments. When shutting
down the processor, we restore the normal zeroing dma ops.  This allows
the kernel to clear memory when loading a new remoteproc binary or
during error recovery with the current remoteproc binary.

The 'late attach' capability is announced through a "ti,late-attach"
property on the respective remoteproc node in the device tree blob.
The corresponding IOMMU and timer nodes should also have this property
set. All the nodes should also have the "ti,no-idle-on-init" and
"ti,no-reset-on-init" properties set to prevent omap_hwmod from
resetting and idling these devices on boot.

The parsed property is stored in a .late_attach field in the rproc
data structure. The field is used for differentiating a normal boot
from a late-attach boot. The "ti,late-attach" feature is relevant only
for the first time boot of the kernel, and is therefore removed from
the remoteproc device-tree node on the first probe. This prevents the
.late_attach flag from being set for subsequent probes of the remoteproc
node. The flag is also reset during the stopping of the remoteproc,
so that any error recovery results in a regular boot.

Change-Id: If52e3e3980fe0bc76725ef94c0ffce415cfee138
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
5 years agoremoteproc: add "late attach" support
Robert Tivy [Fri, 21 Feb 2014 01:49:19 +0000 (17:49 -0800)]
remoteproc: add "late attach" support

The remoteproc driver core is, in general, responsible for allocating
the memory for firmware segments, parsing and loading the firmware
segments into the allocated memory regions, mapping these memory
regions into associated IOMMUs, starting/releasing the processors
from reset, and finally establishing IPC between the host and the
remote processors.

The "late attach" feature refers to a model wherein a remote processor
has already been configured, loaded and started by some external entity
prior to kernel boot (u-boot, for example), and the remoteproc driver
needs to be configured to 'attach' or establish a connection with the
currently running code on the remote processor without resetting or
reconfiguring the device and associated peripherals. The feature is
being added to support specific use-cases (eg: "early camera" or "early
video"), requiring certain KPI criteria. The feature is currently based
on having a remote processor perform all the necessary activities to
achieve the required KPI in a stand-alone mode without having to rely
on communicating with the MPU or perform any IPC activities until the
remoteproc driver is up.

The "late attach" support in the remoteproc driver core is currently
designed to not perform the loading of the firmware segments, or
programming of the IOMMUs. The driver though still goes through the
sequence of processing the firmware to set up the correct virtio
based IPC transports, and allocating the required memory segments
to mark these memory regions as used/reserved from kernel in the
corresponding rproc device's CMA pools. The driver expects the
allocator to not perform any memory initialization, to avoid wiping
out the pre-loaded code. Virtio-based IPC with the remote processors
is established once the driver completes processing the firmware,
just as in a regular boot.

Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Change-Id: I90ba599373523d29a5ea72eaf0e8e43ba0bf3095
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
5 years agoARM: dma-mapping: create non-zeroing dma_map_ops
Martin Ambrose [Fri, 21 Feb 2014 01:49:21 +0000 (17:49 -0800)]
ARM: dma-mapping: create non-zeroing dma_map_ops

A new dma_ops, 'arm_dma_m_ops', is created from a copy of the
standard 'arm_dma_ops' but with a new non-zeroing .alloc method.

These ops are added mainly to support a 'late attach' feature in
the OMAP remoteproc driver. When remoteproc does a 'late attach'
to a remote processor, it does not load any firmware contents into
memory, but it still needs to allocate the processor's CMA memory
to mark the memory as reserved/used from the kernel. The standard
'arm_dma_ops' contains an .alloc method that zeroes out the memory,
thereby overwriting the firmware code/data in the memory that was
pre-loaded before the Linux kernel has booted.

This scenario is handled by adding a new non-zeroing allocation
function and using it as the .alloc method in a copy of the
'arm_dma_ops'. The so created 'arm_dma_m_ops' will be assigned
as the rproc device's dma_ops when supporting the 'late attach'
functionality.

Signed-off-by: Martin Ambrose <martin@ti.com>
Signed-off-by: Robert Tivy <rtivy@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
Signed-off-by: Amarinder Bindra <a-bindra@ti.com>
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Change-Id: Ib7437e482a34c94446a85c3b328d067baa439dab

5 years agoARM: OMAP: dmtimer: Add support to handle late attach of rproc timers
Venkateswara Rao Mandela [Fri, 6 Feb 2015 06:51:14 +0000 (12:21 +0530)]
ARM: OMAP: dmtimer: Add support to handle late attach of rproc timers

During late attach, the dmtimers used by remote processors would already
have been configured and running. To prevent the kernel from resetting or
reconfiguring the timers,

- Parse the late attach attribute from device tree on probe and set a
  flag in the omap_dm_timer data structure. Clear the late attach
  attribute from the device tree as it is only valid on boot.
- If late attach flag is set, increment the dmtimer's usage counter
  immediately on probe and maintain this state until remoteproc starts
  the timer. This prevents kernel power management functionality from
  idling and disabling the dmtimers.
- If late attach flag is set, also prevent the dmtimer configuration
  code from modifying the dmtimer registers.

The late attach flag in the omap_dm_timer structure is cleared on timer
start to allow normal operation to resume.

Change-Id: Ibc612df92e4d8ec157c7eeb6bcac4a3aa53c35f2
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoiommu/omap: add support for performing a "late attach"
Venkateswara Rao Mandela [Thu, 22 Jan 2015 11:48:01 +0000 (17:18 +0530)]
iommu/omap: add support for performing a "late attach"

The remoteproc module has a concept of "late attach" whereby a remote
core is loaded externally to remoteproc, for which remoteproc must
attach to the core without disrupting its existing state. Introduce an
iommu-based "late attach" model for the same use case.

In the "late attach" model, the iommu subsystem is mostly unused since
the external loader will have programmed the remote core's mmu, but
certain "attach" functionality must be performed so that subsequent
"detach" functionality can complete.

This logic is detected in the driver through a "ti,late-attach" property
set on the IOMMU node in the device tree. The IOMMU node should also have
the "ti,no-init-on-reset" and "ti,no-init-on-idle" so that the omap_hwmod
and omap_device layers do not reset and idle/disable the device during
the initial kernel boot. This "ti,late-attach" is therefore removed from
the device tree on the first probe so that further probes or remoteproc
recovery boots treat the IOMMU device normally.

Change-Id: Id288932641a99378f7ca4b0addc3edbcc3d29ed4
Signed-off-by: Venkateswara Rao Mandela <venkat.mandela@ti.com>
Signed-off-by: Angela Stegmaier <angelabaker@ti.com>
Signed-off-by: Suman Anna <s-anna@ti.com>
5 years agoOMAPDSS: Reorder the Makefile so that LCD is loaded before HDMI
Marcus Cooksey [Thu, 9 Apr 2015 18:49:13 +0000 (13:49 -0500)]
OMAPDSS: Reorder the Makefile so that LCD is loaded before HDMI

To comply with Android UI assumption of LCD being the primary display,
the display driver initialization sequence is reordered for LCD driver
initialization to occur before ALL other diplays.

This is necessary now that pinmux config occurs in bootloader.
Without this change hdmi could be initialized and set as primary display
thereby violating the Android UI assumption.

Change-Id: I215b55a3136201bbed7cc554cc7375b41f9e8706
Signed-off-by: Marcus Cooksey <mcooksey@ti.com>
5 years agoRevert "TEMP: ARM: dts: dra7-evm: add i2c2 pinmux back in kernel"
Marcus Cooksey [Thu, 9 Apr 2015 20:58:17 +0000 (15:58 -0500)]
Revert "TEMP: ARM: dts: dra7-evm: add i2c2 pinmux back in kernel"

This reverts commit 1ee4618aeb746e98b8cbc279564d306d1045ace4.

Change-Id: Icb4909078708bea01f5dc4254e71c491a28a4788
Signed-off-by: Marcus Cooksey <mcooksey@ti.com>
5 years agoi2c: tvp5158: Enabling the enum_framesizes subdev op
Rakesh Movva [Wed, 20 May 2015 01:14:28 +0000 (20:14 -0500)]
i2c: tvp5158: Enabling the enum_framesizes subdev op

This patch allows the VIP driver to call the enum_framsizes subdev
'op' so that it can return the corresct set of supported preview
sizes of the sensor.

Change-Id: I3aca8d913ba30c2cf82678f58bdb83d934d0a610
Signed-off-by: Rakesh Movva <r-movva@ti.com>
5 years agoARM: dts: dra7-evm: Add TVP5158 node
Rakesh Movva [Wed, 20 May 2015 04:56:18 +0000 (23:56 -0500)]
ARM: dts: dra7-evm: Add TVP5158 node

Adding the TVP5158 analog video decoder support which generates
BT656 embedded sync video. Add the device tree node and the
corresponding endpoint pair.

Change-Id: Id6d4df16fedbf321396b3fb4ee350f965f4b7367
Signed-off-by: Rakesh Movva <r-movva@ti.com>
5 years agoti_fragments: audio_display: Make VIP/VPE/TVP5158 a built-in
Rakesh Movva [Mon, 18 May 2015 16:04:58 +0000 (11:04 -0500)]
ti_fragments: audio_display: Make VIP/VPE/TVP5158 a built-in

VIP/VPE/TVP5158 are made as a built-in feature.

Change-Id: I348c221ca912480310abaa38650fdce6481809c6
Signed-off-by: Rakesh Movva <r-movva@ti.com>
5 years agoi2c: tvp5158: Analog camera decoder driver
Sathishkumar S [Sat, 31 Jan 2015 13:40:48 +0000 (19:10 +0530)]
i2c: tvp5158: Analog camera decoder driver

Add support for TVP5158 video decoder. This driver
does the default initialization for single channel
NTSC decode. It is tested with NTSC camera source.

Change-Id: Ia5f6bd038a5bcd5e7571afdc5447acbf575a97ef
Signed-off-by: Sathishkumar S <sathish.omap@gmail.com>
[Added multi channel support]
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
5 years agoMerge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android...
Subramaniam Chanderashekarapuram [Wed, 27 May 2015 00:25:34 +0000 (19:25 -0500)]
Merge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio into p-ti-linux-3.14.y-common

* 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio:
  ASoC: davinci-mcasp: Logic low for inactive output slots

Signed-off-by: Subramaniam Chanderashekarapuram <subramaniam.ca@ti.com>
5 years agoARM: dts: dra72-evm: Set MMC host controller capability properties
Kishon Vijay Abraham I [Mon, 25 May 2015 14:14:54 +0000 (19:44 +0530)]
ARM: dts: dra72-evm: Set MMC host controller capability properties

Added properties in device tree to indicate the MMC controller support
SDR12, SDR25 and DDR50 modes.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
5 years agoARM: dts: dra7-evm: Add IODELAY values for the UHS MMC modes
Kishon Vijay Abraham I [Mon, 25 May 2015 14:14:53 +0000 (19:44 +0530)]
ARM: dts: dra7-evm: Add IODELAY values for the UHS MMC modes

Add IODELAY values for sdr12, sdr25, ddr50 and mmc ddr52 modes.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
5 years agommc: omap_hsmmc: Add support to set IODELAY values for MMC DDR52
Kishon Vijay Abraham I [Mon, 25 May 2015 14:14:52 +0000 (19:44 +0530)]
mmc: omap_hsmmc: Add support to set IODELAY values for MMC DDR52

commit e81ae6df66 (mmc: host: omap_hsmmc: Set appropriate
IODELAY values for various MMC modes) added support to set IODELAY
values for various MMC modes but failed to add support for
DDR52.
Add support to set IODELAY values for MMC DDR52 mode.

Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
5 years agoARM: dts: dra7-evm: MMC2 in DDR52 mode
Misael Lopez Cruz [Tue, 12 May 2015 23:56:03 +0000 (18:56 -0500)]
ARM: dts: dra7-evm: MMC2 in DDR52 mode

MMC2 was using high-speed timing by default which has lower
throughput than DDR52, which is also supported.  So switch
MMC2 to DDR52 mode.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agommc: omap_hsmmc: Set MMC DDR52 also from dt property
Misael Lopez Cruz [Tue, 12 May 2015 23:52:57 +0000 (18:52 -0500)]
mmc: omap_hsmmc: Set MMC DDR52 also from dt property

All other controller capabilities were set from dt property
but MMC DDR52 was missing.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agommc: omap_hsmmc: Fix MMC DDR52 support
Misael Lopez Cruz [Tue, 12 May 2015 23:49:28 +0000 (18:49 -0500)]
mmc: omap_hsmmc: Fix MMC DDR52 support

MMC DDR52 mode also requires the DDR bit set.

This fix is pretty much what's done in upstream commit 903101a
"mmc: omap_hsmmc: Fix UHS card with DDR50 support", except
that in ti-kernel-3.14 MMC DDR52 was broken, not UHS DDR50.

Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoASoC: davinci-mcasp: Logic low for inactive output slots
Misael Lopez Cruz [Tue, 19 May 2015 18:05:15 +0000 (13:05 -0500)]
ASoC: davinci-mcasp: Logic low for inactive output slots

The default state when serializers are in inactive slots is Hi-Z.
In some cases, there are no additional components driving the data
lines to a safe state so they might have noise.

While in inactive slots, the McASP AXR pins configured as outputs
can be driven low through the serializer pin drive mode setting
(DISMOD) to prevent such noise.

Change-Id: I945a806fe1ad77a5f3d09e9fa039ae0366a5b088
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: OMAP: Add function to install alternate secure dispatcher
Harinarayan Bhatta [Fri, 17 Apr 2015 05:09:11 +0000 (10:39 +0530)]
ARM: OMAP: Add function to install alternate secure dispatcher

This change adds the function omap_secure_dispatcher_switch
which is used to setup an alternate implemention of the function
omap_secure_dispatcher in omap-secure.c

Change-Id: Ib4b2579a5e5bef3e35adc3bce4f11f739c5a3851
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
5 years agoARM: DRA7: hwmod: register timer12 only for GP device type
Harinarayan Bhatta [Fri, 17 Apr 2015 04:57:01 +0000 (10:27 +0530)]
ARM: DRA7: hwmod: register timer12 only for GP device type

This update separates out timer12 into a different list
registered for GP devices only. On a HS device, timer12
is used in secure world and is not available for linux.

Change-Id: I6629680debbb399c8932d20ee860103211197843
Signed-off-by: Harinarayan Bhatta <harinarayan@ti.com>
5 years agoMerge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel...
Praneeth Bajjuri [Thu, 21 May 2015 22:36:17 +0000 (17:36 -0500)]
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common

* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel:
  TI-Integration: usb: musb: fix botched up merge (again)

Change-Id: I8f5adc9e1e1e37c731e1d6405a071012e6064ebc
Signed-off-by: Praneeth Bajjuri <praneeth@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 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android...
Praneeth Bajjuri [Thu, 21 May 2015 19:19:11 +0000 (14:19 -0500)]
Merge branch 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio into p-ti-linux-3.14.y-common

* 'p-ti-linux-3.14.y-common/audio-for-next' of git://git.ti.com/android-sdk/kernel-audio:
  ARM: dtsi: dra7xx-jamr3: McASP2 is shared with DSP
  ARM: dts: dra72-evm: TEMP: Add pinmux for radio
  ARM: dts: dra72-evm: TEMP: Add pinmux for UART3

Change-Id: I5a700c1fe78ac6e730ebf1f07dd8265322ee46c2
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
5 years agoARM: dtsi: dra7xx-jamr3: McASP2 is shared with DSP
Misael Lopez Cruz [Thu, 21 May 2015 05:38:44 +0000 (00:38 -0500)]
ARM: dtsi: dra7xx-jamr3: McASP2 is shared with DSP

McASP2 is configured and used from the DSP side, with the
exception of the PM resources that are taken care on the
MPU side.

Change-Id: If133a69de6c50b3aeb7a31edb557725b0753f39d
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: dts: dra72-evm: TEMP: Add pinmux for radio
Misael Lopez Cruz [Wed, 20 May 2015 17:09:16 +0000 (12:09 -0500)]
ARM: dts: dra72-evm: TEMP: Add pinmux for radio

Add pinmux settings for radio related modules (McASP2, McASP6, i2c4,
etc).  This is a temporary patch as all padconf settings are expected
to be moved to the bootloader, as already done for J6 / dra7-evm.

Change-Id: I6c59ce7446c40f2d8db9c017f095f070754e6c1d
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
5 years agoARM: dts: dra72-evm: TEMP: Add pinmux for UART3
Misael Lopez Cruz [Wed, 20 May 2015 15:37:07 +0000 (10:37 -0500)]
ARM: dts: dra72-evm: TEMP: Add pinmux for UART3

Add pinmux settings for UART3 used in Bluetooth.  This is a
temporary patch as all padconf settings are expected to be
moved to the bootloader, as already done for J6 / dra7-evm.

Change-Id: Idb861390be182eb296e2dc6e8aee7d6458a6543a
Signed-off-by: Misael Lopez Cruz <misael.lopez@ti.com>
6 years agoarm: dtsi: dra7x: Add Vision application board device tree
Nikhil Devshatwar [Fri, 5 Dec 2014 10:01:26 +0000 (15:31 +0530)]
arm: dtsi: dra7x: Add Vision application board device tree

Vision app board is an application board which is designed
to work with TI dra7xx-evm specifically for multi camera use cases.

This board consists of:-
 OV10635 8bit camera with parallel interface.
* HDMI video receiver chip
* 3 GPIO expanders for configuring the video deserializers
* 6 video deserializers ( using FPDlink III)
  Each deserializer allows to connect one OV10635 camera via a video
  serializer connected over LVDS
* 6 serializer chips one each on the deserializer i2c  bus
* 6 OV10635 cameras one each on the deserializer i2c bus
* There are some CPLD muxes on the board which control the data
  routing of multiple video cameras. These muxes are controlled using
  gpio pins

Create a skeleton DTS file for vision app board.
Also add the device tree files for dra7-evm and dra72-evm with vision
app board.

Change-Id: I113857832c82d4ce4112911a3c7e4ad0adab73ad
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
6 years agovideo: serdes: Add TI FPDlink3 video (de)serializer driver
Nikhil Devshatwar [Sat, 6 Dec 2014 10:23:22 +0000 (15:53 +0530)]
video: serdes: Add TI FPDlink3 video (de)serializer driver

Add necessary documentation, Makefile, Kconfig and header files
Add support for DS90UB914Q/913Q 12bit video (de)serializer
Add support for DS90UB925/928 12bit video (de)serializer
- Register gpio chip for local gpios
- Register i2c adapter for remote bus
- Act as i2c bridge for all remote slave devices

Change-Id: Ic8046018fea04ed9faca8808a2519c1ea4754248
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
6 years agoMerge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel...
Praneeth Bajjuri [Mon, 18 May 2015 18:54:32 +0000 (13:54 -0500)]
Merge branch 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel into p-ti-linux-3.14.y-common

* 'ti-linux-3.14.y' of git://git.ti.com/ti-linux-kernel/ti-linux-kernel: (74 commits)
  TI-Integration: Cherry picking this commit to fix merge issue
  TI-Integration: Fix merge conflict on musb_core.c
  remoteproc/omap: add support for system suspend/resume
  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
  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
  Linux 3.14.43
  ...

Change-Id: I93e347ad013ffa4aeeb5c1d088d79e0efc0c80e7
Signed-off-by: Praneeth Bajjuri <praneeth@ti.com>
6 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

6 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>
6 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>
6 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>
6 years agodts: Adding entry for GC320.
Gowtham Tammana [Thu, 11 Dec 2014 18:03:00 +0000 (12:03 -0600)]
dts: Adding entry for GC320.

GC320 entry is added to the dts file. Using crossbar index number
for interrupt mapping.

Change-Id: I3ff5644fbcc2ec74db40af945caac8436bafe3aa
Signed-off-by: Gowtham Tammana <g-tammana@ti.com>
6 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>
6 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>
6 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>
6 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>
6 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>
6 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>
6 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>
6 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>
6 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>
6 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>
6 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>
6 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>