ARM: tegra: fix pinctrl misconfiguration on Venice2

Other boards use PULL_NONE for their debug UART pins, and without this
change, the board doesn't accept any serial input.

Don't set the I2S port pins to tristate mode, or no audio signal will
be sent out.

Fixes: 605ae5804385 ("ARM: tegra: add default pinctrl nodes for Venice2")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: Fix misconfiguration of pin PH2 on Venice2

This pin needs to be configured in pull-down, non-tristate mode in order
for the backlight to work correctly.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: Add SPI controller nodes for Tegra124

The SPI controllers on Tegra124 are compatible with those found on the
Tegra114 SoC.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Merge branch for-3.14/deps-from-dma-defer_probe into for-next
Merge branch for-3.14/deps-from-asoc-dma into for-next
Merge branch for-3.14/deps-from-dma-of into for-next
Merge branch for-3.14/deps-from-clk-tegra into for-next
Merge branch for-3.14/trusted-foundations into for-next
Merge branch for-3.14/dmas-resets-rework into for-next
Merge branch for-3.14/soc into for-next
Merge branch for-3.14/dt into for-next
Merge branch for-3.14/defconfig into for-next
Merge remote-tracking branch 'korg_tegra_linux/for-next' into HEAD

Conflicts:
	arch/arm/configs/tegra_defconfig
APPLIED (tentative): mfd: always assign of_node in mfd_add_device()

mfd_add_device() assigns .of_node in the device objects it creates only
if the mfd_cell for the device has the .of_compatible field set and the
DT node for the top-level MFD device contains a child whose compatible
property matches the cell's .of_compatible field.

This leaves .of_node unset in many cases. When this happens, entries in
the DT /aliases property which refer to the top-level MFD DT node will
never match the MFD child devices, hence causing the requested alias not
to be honored.

Solve this by setting each MFD child device's .of_node equal to the top-
level MFD device's .of_node field in the cases where it would otherwise
remain unset.

The first use-case for this will be aliases for the TPS6586x's RTC
device.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
The 3 patches in this series are all independent; they can be applied
to their respective subsystems in any order. I'm simply posting them as
a series to make the use-case more obvious.
dma: tegra: add support for Tegra148/124

Tegra148 introduces a few changes to the APB DMA HW registers. Update the
driver to cope with them. Tegra124 inherits these changes.

* The register address stride between DMA channels increases.

* A new per-channel WCOUNT register is introduced.

Signed-off-by: Laxman Dewangan <ldewangan@nvidia.com>
Signed-off-by: Kunal Agrawal <kunala@nvidia.com>
[swarren, remove .dts file change, rewrote commit description, removed
some duplicate/unused code and register IO]
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
Tested-by: Thierry Reding <treding@nvidia.com>
---
v3:
* Remove some unnecessary parentheses.
v2:
* Remove some unused #defines that had incorrect names or values.
* Remove unnecessary initialization of wcount local variable.

This can be applied directly to the usual dmaengine branch; I've checked
it doesn't conflict with the patches going through other trees which
convert the driver to use the standard reset framework, or implement a
DT DMA provider.
mmc: tegra: add support for Tegra124

Tegra124's MMC controller is very similar to earlier SoC generations,
and can be supported by the same driver.

However, there are some non-backwards-compatible HW differences, and
hence a new DT compatible value must be used to describe the HW. This
patch updates the driver to support that new compatible value.

That said, the HW differences are only relevant when enabling certain
high-performance transfer modes. Since the driver is currently very
simple and doesn't enable those modes, we don't actually need to address
any of these HW differences in the code yet, hence the simple nature of
this patch.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
ASoC: dmaengine: remove SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME

struct snd_dmaengine_pcm_config's new chan_names field implements the
same feature, and nothing uses SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME,
so remove it.

FIXME: Need to create a patch to ASoC's topic/samsung(?) branch to stop
it from using SND_DMAENGINE_PCM_FLAG_CUSTOM_CHANNEL_NAME first...

Signed-off-by: Stephen Warren <swarren@nvidia.com>
rtc: honor device tree /alias entries when assigning IDs

Assign RTC device IDs based on device tree /aliases entries if present,
falling back to the existing numbering scheme if there is no /aliases
entry (which includes when the system isn't booted using DT), or there
is a numbering conflict.

This is useful in systems with multiple RTC devices, to ensure that the
best RTC device is selected as /dev/rtc0, which provides the overall
system time.

For example, Tegra has an on-SoC RTC that is not battery backed,
typically coupled with an off-SoC RTC that is battery backed. Only the
latter is useful for populating the system time, yet the former is
useful e.g. for wakeup timing, since the time is not lost when the
system is sleeps.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
The 3 patches in this series are all independent; they can be applied
to their respective subsystems in any order. I'm simply posting them as
a series to make the use-case more obvious.
ARM: tegra: set up /aliases entries for RTCs

This ensures that the PMIC RTC provides the system time, rather than
the on-SoC RTC, which is not battery-backed.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
---
This patch is just an example. If the previous two patches are accepted,
I'll flesh this patch out to cover all boards, and repost.
ARM: tegra: use simplefb for Tegra20 boards with LCDs

Signed-off-by: Stephen Warren <swarren@nvidia.com>