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
18 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
-
…-linux-feature-tree into ti-linux-3.14.y
TI-Feature: power_management_base
TI-Tree: git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree.git
TI-Branch: pm-ti-linux-3.14.y* 'pm-ti-linux-3.14.y' of git://git.ti.com/~kristo/ti-linux-kernel/pm-linux-feature-tree:
ARM: dts: am437x-sk-evm: disable DDR regulator in rtc-only/poweroff mode
regulator: tps65218: do not disable DCDC3 during poweroff on broken PMICs
mfd: tps65218: add version check to the PMIC probe
rtc: omap: fix ext-wakeup setup
rtc: omap: do not disable RTC alarm during shutdown
rtc: omap: setup the regulators for poweroff mode
ARM: dts: am437x-gp-evm: disable DDR regulator in rtc-only/poweroff mode
regulator: tps65218: force set power-up/down strobe to 3 for dcdc3
regulator: of: setup initial suspend state
ARM: dts: AM43xx: update regulator nodes for new layout
regulator: of: Add support for parsing regulator_state for suspend state
ARM: dts: dra7: add i810 errata dpll data
ARM: DRA7: dpll: add implementation for errata i810Conflicts:
arch/arm/common/edma.c
arch/arm/mach-omap2/Makefile
drivers/regulator/palmas-regulator.c
include/dt-bindings/pinctrl/am43xx.hSigned-off-by: Dan Murphy <DMurphy@ti.com>
-
Add a new platform data ops to allow the OMAP IOMMU driver to be able
to request a specific target power domain state for the domain it
belongs to. This ops is being added to resolve a boot issue on OMAP
remote processors like IPU that have an AMMU/Unicache, which will be
in an invalid state if the particular power domain enters RET between
the MMU programming and releasing the reset of the remote processor.
See [1] for more details on the issue.The ops will allow to invoke the pwrdm_set_next_pwrst() API in a
multi-arch kernel environment. The ops also returns the current power
domain state while enforcing the constraint so that the driver can
store it and use it to set back the power domain state while releasing
the constraint.[1] http://git.ti.com/gitweb/?p=rpmsg/rpmsg.git;a=commit;h=6d6dd44c55638d54a151bf2ae6cc77b2f4e459d0
Signed-off-by: Suman Anna
-
Without this, the memory will remain active during poweroff consuming
extra power. Please note revision 2.1 PMIC seems to fail when DCDC3
disable is attempted, so this is not done on that PMIC revision. The
PMIC revision checks in the regulator patches make sure of this.Signed-off-by: Tero Kristo
Signed-off-by: Dave Gerlach -
Some versions of tps65218 do not seem to support poweroff modes properly
if DCDC3 regulator is shut-down. Thus, keep it enabled even during
poweroff if the version info matches the broken silicon revision.Signed-off-by: Tero Kristo
Signed-off-by: Dave Gerlach -
Version information will be needed to handle some error cases under the
regulator driver, so store the information once during MFD probe.Signed-off-by: Tero Kristo
Signed-off-by: Dave Gerlach -
The register write for the ext-wakeup handling does not write the
EXT_WAKEUP_EN bit at all, which causes a system shutdown after
20 seconds after wakeup from EXT_WAKEUP (e.g. power button.) Fixed
by adding the missing bit.Fixes: 4c71e686101d (drivers/rtc/rtc-omap.c: Enable power..)
Signed-off-by: Tero Kristo
Signed-off-by: Dave Gerlach -
This enables use cases like rtc-only mode, where most of the system is
shutdown just waiting for an RTC alarm to occur and boot the device up.Only supported for systems that have the RTC act as a system power
controller at the moment (AM33xx/AM43xx.)Signed-off-by: Tero Kristo
Signed-off-by: Dave Gerlach -
In certain cases, like rtc-only mode, the system regulators shall be
set to slightly different mode compared to suspend to mem. As the RTC
driver is handling the poweroff setup on some systems, add a callback
to regulator core from the RTC power off to setup the valid regulator
states.Signed-off-by: Tero Kristo
Signed-off-by: Dave Gerlach -
Without this, the memory will remain active during poweroff consuming
extra power.Signed-off-by: Tero Kristo
Signed-off-by: Dave Gerlach -
The reset value for this register seems broken on certain versions of
tps65218 chip, so make sure the dcdc3 settings is proper. Needed for
proper functionality of rtc+ddr / rtc-only modes.Signed-off-by: Tero Kristo
Signed-off-by: Dave Gerlach
