APPLIED: gpio: document polarity flag best practices

Document what we (Laurent and I, following a mailing list dicussion)
believe are best practices for the polarity flag in a GPIO specifier.

While touching the doc, I made a few minor editing changes to other
areas.

Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
dt: palmas: support IRQ inversion at the board level

Some boards or SoCs have an inverter between the PMIC IRQ output pin and
the IRQ controller input signal.

The IRQ specifier in DT is meant to represent the IRQ flags at the input
to the IRQ controller.

The Palmas HW's IRQ output has configurable polarity. Software needs to
know which polarity to choose for the IRQ output. Software may be tempted
to extract the IRQ polarity from the IRQ specifier in order to make this
choice.

That approach works fine if the IRQ signal is routed directly from the
PMIC to the IRQ controller with no intervening logic. However, if the
signal is inverted between the two, this approach gets the wrong answer.

Add an additional optional DT property which indicates that such an
inversion occurs. This allows DT to give complete information about the
desired IRQ output polarity to software.

An alternative would have been to add a new non-optional DT parameter to
indicate the exact desired output polarity. However, this would have been
an incompatible change to the DT binding.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
v2: Split V1's patch 1/2 into separate patches 1/3 and 2/3.
mfd: palmas: support IRQ inversion at the board level

Implement the new DT property ti,irq-externally-inverted, and add an
equivalent platform data field to match. This allows the driver to
correctly automatically configure the IRQ output polarity when the board
or SoC contains an inverter between the Palmas IRQ output and IRQ
controller input.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
---
v2: Split V1's patch 1/2 into separate patches 1/3 and 2/3.

If this patch (and likely 1/3 too) could be applied to its own branch
(w/ signed tag) in the MFD tree, that would great; then I can pull patch
it into the Tegra tree so that I can apply patch 3/3 on top. Thanks.
ARM: tegra: fix Dalmore PMIC IRQ polarity

The Tegra PMC's resume-from-sleep logic wants an active-low IRQ input
from the PMIC. However, the PMIC IRQ is also routed to the GIC, which
only supports active high IRQs (or rising edge). Hence, the signal must
be inverted in the PMC before being routed to the GIC. This implies that
the PMC DT property nvidia,invert-interrupt must be set, and it is.

The PMIC's DT interrupts property must represent the IRQ level at the
GIC, since that is the PMIC's parent IRQ controller. Fix the PMIC's
interrupts property to correctly describe the GIC input polarity.

However, the PMIC IRQ output's polarity is programmable in HW, and by
default follows the parent IRQ controller's input polarity. We need to
have an active-low output due to the inversion inside the Tegra PMC.
Hence, add the ti,irq-externally-inverted property to the PMIC.

Reported-by: Stefan Agner <stefan@agner.ch>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Acked-by: Laxman Dewangan <ldewangan@nvidia.com>
---
v2: No change.
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>
ASoC: dmaengine: remove compat_request_channel

struct snd_dmaengine_pcm_config's compat_request_channel field is no
longer set anywhere. Remove it, and the code that implements it.

FIXME: Need to wait for ux500 driver not to be using this feature.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
LOCAL HACK: tegra_defconfig changes

Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: bluetooth testing hacks for Cardhu

Signed-off-by: Stephen Warren <swarren@nvidia.com>
HACK: Attempt to get DMICs working
Revert "HACK: Attempt to get DMICs working"

This reverts commit 7696d3e61c2dd5ce3f480083dc506be340062a9b.
ASoC: wm8903: disable IRQs during BIAS_OFF

If the WM8903 IRQ is triggered after the device is suspended, or before
it is resumed, the underlying I2C bus that the WM8903 is attached to may
not be available. This may cause the IRQ handler to emit the following
error:

    wm8903 0-001a: Failed to read IRQ status: -16

... or perhaps even cause a failure inside the I2C driver.

To prevent this, explicitly mask all interrupt sources when entering
BIAS_OFF. Also, modify the IRQ handler to immediately return if the
device is in BIAS_OFF, so that shared interrupt lines don't cause a
similar problem. This requires that WM8903 interrupts be disabled to
avoid interrupt storms.

During resume (actually, the transition back to BIAS_STANDBY), restore
the desired IRQ mask.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Revert "ASoC: wm8903: disable IRQs during BIAS_OFF"

This reverts commit 294680591cf91d99c1af375c055d39813338a04c.
HACK: attempt to convert sound/soc/samsung for ASoC DMA changes
Revert "HACK: attempt to convert sound/soc/samsung for ASoC DMA changes"

This reverts commit e072db5ec5c3f957196e602cd414e1518ee8a966.
HACK venice2 not to use an audio CODEC
Revert "HACK venice2 not to use an audio CODEC"

This reverts commit 4a837c5476e3a527ba570224595ca7d99d76dd36.
ARM: tegra: Overhaul Venice2 regulators

Some of the regulators and the relationships to other regulators are
wrong. This commit attempts to rectify this by making them more similar
to what the schematics contain. This starts by adding a +VDD_MUX supply
that represents the 12V input and derives the main +3.3V_SYS and +5V_SYS
supplies from that. The majority of the other regulators derive from one
of those three.

While at it, rename the regulators to match the names in the schematics
to make them easier to match up.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: Add Tegra124 USB support

The USB controllers on Tegra124 are backwards-compatible with those
found on Tegra30.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
ARM: tegra: Enable USB on Venice2

USB1 and USB3 are routed to two external connectors, while USB2 is used
for the integrated webcam.

Signed-off-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Stephen Warren <swarren@nvidia.com>
HACK USB to work on Venice2

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