17 Jun, 2015
3 commits
-
…ux-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 offSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
…-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 tps65218Signed-off-by: Dan Murphy <DMurphy@ti.com>
-
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
16 Jun, 2015
5 commits
-
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
-
…egration-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 propertySigned-off-by: Dan Murphy <dmurphy@ti.com>
-
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
Tested-by: Mugunthan V N
Signed-off-by: Lokesh Vutla
Signed-off-by: Sekhar Nori -
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
Acked-by: Roger Quadros
Signed-off-by: Lokesh Vutla
Signed-off-by: Sekhar Nori -
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
Tested-by: Mugunthan V N
Signed-off-by: Lokesh Vutla
Signed-off-by: Sekhar Nori
12 Jun, 2015
2 commits
-
…ux-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 loadingSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
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
Signed-off-by: Jyri Sarha
08 Jun, 2015
2 commits
-
…egration-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 handlingSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
…ux-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 probedSigned-off-by: Dan Murphy <DMurphy@ti.com>
07 Jun, 2015
1 commit
-
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
Tested-by: Yan Liu
Signed-off-by: Kishon Vijay Abraham I
Signed-off-by: Sekhar Nori
05 Jun, 2015
1 commit
-
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
Signed-off-by: Jyri Sarha
03 Jun, 2015
9 commits
-
…rnel/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 hwmodConflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.cSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
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
-
…-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 contextSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
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
Signed-off-by: Dave Gerlach -
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
Signed-off-by: Dave Gerlach -
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
Signed-off-by: Dave Gerlach -
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
Signed-off-by: Dave Gerlach -
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
Signed-off-by: Dave Gerlach -
…rnel/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 hwmodConflicts:
arch/arm/mach-omap2/omap_hwmod_7xx_data.cSigned-off-by: Dan Murphy <DMurphy@ti.com>
02 Jun, 2015
2 commits
-
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
-
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
01 Jun, 2015
5 commits
-
…ux-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 mcaspSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
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
Signed-off-by: Jyri Sarha -
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
Signed-off-by: Jyri Sarha -
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 NV12Also 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
Signed-off-by: Jyri Sarha -
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
Signed-off-by: Jyri Sarha
31 May, 2015
2 commits
-
…egration-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 themselvesSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
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/resumeSigned-off-by: Dan Murphy
30 May, 2015
8 commits
-
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 instancesSigned-off-by: Suman Anna
-
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
-
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
-
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
-
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 constraintSigned-off-by: Suman Anna
-
…rnel/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>
-
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
-
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