rtc: max8907: weekday encoding fixes

The current MAX8907 driver has two issues related to weekday value
handling:

1)

The HW WEEKDAY register has range 0..6 rather than 1..7 as documented,
hence we should write Linux's tm_wday value to the register without
modifying it. Fix the driver not to add/subtract 1 when handling this
register.

Note that I validated the actual HW range by observing the HW register
roll from 6->0 rather than 6->7->1 as would otherwise be expected. This
also matches the fact that when the CMOS RAM content is lost and reads
all zeroes, the date returned from the device is 2007-01-01, which is
a Monday, and the WEEKDAY register reads 0 in this case.

2)

There's no need to make alarms match on the WEEKDAY register, since the
other fields together uniquely define the alarm date/time. Ignoring
the WEEKDAY value in the match isolates the driver from any incorrect
value in the current time copy of the WEEKDAY register.

Each change individually, or both together, solves an issue that I
observed; "hwclock -r" would time out waiting for its alarm to fire if
the CMOS RAM content had been lost, and hence the WEEKDAY register value
mismatched what the driver expected it to be. "hwclock -w" would solve
this by over-writing the HW default WEEKDAY register value with what the
driver expected.

Cc: <stable@vger.kernel.org>
Signed-off-by: Stephen Warren <swarren@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>
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>
HACK: ARM: tegra: temp hack to enable poweroff on Venice2

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.
ARM: tegra: remove tegra EMC scaling driver

Nothing calls into the Tegra EMC (External Memory Controller) scaling
driver any more, so it's dead code. Remove it.

Signed-off-by: Stephen Warren <swarren@nvidia.com>
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.
mmc: core: don't return 1 for max_discard

In mmc_do_calc_max_discard(), if only a single erase block can be
discarded within the host controller's timeout, don't allow discard
operations at all.

Previously, the code allowed sector-at-a-time discard (rather than
erase-block-at-a-time), which was chronically slow.

Without this patch, on the NVIDIA Tegra Cardhu board, the loops result
in qty == 1, which is immediately returned. This causes discard to
operate a single sector at a time, which is chronically slow. With this
patch in place, discard operates a single erase block at a time, which
is reasonably fast.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Dong Aisheng <dongas86@gmail.com>
Cc: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Vladimir Zapolskiy <vz@mleia.com>
Fixes: e056a1b5b67b "(mmc: queue: let host controllers specify maximum discard timeout")
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Revert "mmc: core: don't return 1 for max_discard"

This reverts commit afb1238d1a4be99749c37bbb48a437034e05e5f8.
Revert "mmc: queue: let host controllers specify maximum discard timeout"

This reverts commit e056a1b5b67b4e4bfad00bf143ab14f634777705.

Conflicts:
	drivers/mmc/card/queue.c
mmc: core: use timeout for erase operation not erase cmd submission

FIXME:

Signed-off-by: Stephen Warren <swarren@nvidia.com>
Revert "mmc: core: use timeout for erase operation not erase cmd submission"

This reverts commit 65e68f8a2bb596a179ae90c32f32ee028456bd9a.
Revert "Revert "mmc: queue: let host controllers specify maximum discard timeout""

This reverts commit 99ea1bfac40e4767dffc2a48eb603400d4732779.
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.