Since commit 1137ceee ("ARM: OMAP1: ams-delta: Don't request unused
GPIOs"), on-board audio has appeared muted.  It has been discovered that
believed to be unused GPIO pins "hookflash1" and "hookflash2" need to be
set low for audible sound in handsfree and handset mode respectively.

According to Amstrad E3 wiki, the purpose of both pins hasn't been
clearly identified.  Original Amstrad software used to produce a high
pulse on them when the phone was taken off hook or recall was pressed.
With the current findings, we can assume the pins provide a kind of
audio mute function, separately for handset and handsfree operation
modes.

Commit 2afdb4c4 ("ARM: OMAP1: ams-delta: Fix audio permanently
muted") attempted to fix the issue temporarily by hogging the GPIO pin
"hookflash1" renamed to "audio_mute", however the fix occurred
incomplete as it restored audible sound only for handsfree mode.

Stop hogging that pin, rename the pins to "handsfree_mute" and
"handset_mute" respectively and implement appropriate DAPM event
callbacks for "Speaker" and "Earpiece" DAPM widgets.

Fixes: 1137ceee ("ARM: OMAP1: ams-delta: Don't request unused GPIOs")
Signed-off-by: NJanusz Krzysztofik <jmkrzyszt@gmail.com>
Reviewed-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20190907111650.15440-1-jmkrzyszt@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Some tools use the snd_pcm_info_get_name() to try to identify PCMs or for
other purposes.

Currently it is left empty with the dmaengine-pcm, in this case copy the
pcm->id string as pcm->name.

For example IGT is using this to find the HDMI PCM for testing audio on it.
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Reported-by: NArthur She <arthur.she@linaro.org>
Link: https://lore.kernel.org/r/20190906055524.7393-1-peter.ujfalusi@ti.comSigned-off-by: NMark Brown <broonie@kernel.org>

Currently the driver uses snd_soc_rtdcom_lookup() in it's mcbsp_start
function to try to stop/restart the DMA as the initial XSYNCERR workaround
need to be done before the DMA is armed.

There are couple of things wrong with this:
- the driver crashes with NULL pointer dereference as the
  component->driver->ops is actually NULL
- the driver should not use snd_soc_rtdcom_lookup() in the first place
- Fiddling with DMA is never a good thing

Move the workaround handling to .prepare which is called before the DMA is
armed, so it complies with the requirements.

Reported-by (usage of snd_soc_rtdcom_lookup): Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20190830103841.25128-3-peter.ujfalusi@ti.comSigned-off-by: NMark Brown <broonie@kernel.org>

Append fallthrough statement to fix warning reported during compilation.

Fixes: b80d19c1 ("ASoC: Intel: Restore Baytrail ADSP streams only when ADSP was in reset")
Signed-off-by: NCezary Rojewski <cezary.rojewski@intel.com>
Link: https://lore.kernel.org/r/20190828095102.15737-1-cezary.rojewski@intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The test case is
arecord -Dhw:0 -d 10 -f S16_LE -r 48000 -c 2 temp.wav &
aplay -Dhw:0 -d 30 -f S16_LE -r 48000 -c 2 test.wav

There will be error after end of arecord:
aplay: pcm_write:2051: write error: Input/output error

Capture and Playback work in parallel in master mode, one
substream stops, the other substream is impacted, the
reason is that clock is disabled wrongly.

The clock's reference count is not increased when second
substream starts, the hw_param() function returns in the
beginning because first substream is enabled, then in end
of first substream, the hw_free() disables the clock.

This patch is to move the clock enablement to the place
before checking of the device enablement in hw_param().
Signed-off-by: NShengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1567012817-12625-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>

Mt8183 tdm out support S16_LE/S24_LE/S32_LE formats. When output S32_LE,
we need set hd_align so that memif can output MSB 24bits. When output
S24_LE, we need reset hd_align so that memif can output LSB 24bits.
Signed-off-by: NJiaxin Yu <jiaxin.yu@mediatek.com>
Link: https://lore.kernel.org/r/1566622726-27113-1-git-send-email-jiaxin.yu@mediatek.comSigned-off-by: NMark Brown <broonie@kernel.org>

The calibration process at booting will reset registers and bypass cache
to make sure the calibration is done.
We add mutex protection to avoid unexpected settings while
the registration process and calibration are interleaved.
Signed-off-by: NShuming Fan <shumingf@realtek.com>
Link: https://lore.kernel.org/r/20190826090052.1875-1-shumingf@realtek.comSigned-off-by: NMark Brown <broonie@kernel.org>

This patch fixes inverted Left-Right channel of headphone mixer
volume by wrong shift_left, shift_right values.
Signed-off-by: NKatsuhiro Suzuki <katsuhiro@katsuster.net>
Reviewed-by: NDaniel Drake <drake@endlessm.com>
Link: https://lore.kernel.org/r/20190826153900.25969-2-katsuhiro@katsuster.netSigned-off-by: NMark Brown <broonie@kernel.org>

This patch fix setting table of Headphone mixer volume.
Current code uses 4 ... 7 values but these values are prohibited.

Correct settings are the following:
  0000 -12dB
  0001 -10.5dB
  0010 -9dB
  0011 -7.5dB
  0100 -6dB
  1000 -4.5dB
  1001 -3dB
  1010 -1.5dB
  1011 0dB
Signed-off-by: NKatsuhiro Suzuki <katsuhiro@katsuster.net>
Reviewed-by: NDaniel Drake <drake@endlessm.com>
Link: https://lore.kernel.org/r/20190826153900.25969-1-katsuhiro@katsuster.netSigned-off-by: NMark Brown <broonie@kernel.org>

oem_table_id is 8 chars long, so we need to limit it, otherwise it
may print some unprintable characters into dmesg.
Signed-off-by: NAmadeusz Sławiński <amadeuszx.slawinski@intel.com>
Link: https://lore.kernel.org/r/20190827141712.21015-7-amadeuszx.slawinski@linux.intel.comReviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

We use snd_soc_dapm_new_control_unlocked for topology and have local
declaration, instead declare it properly in header like already declared
snd_soc_dapm_new_control.
Signed-off-by: NAmadeusz Sławiński <amadeuszx.slawinski@intel.com>
Link: https://lore.kernel.org/r/20190827141712.21015-4-amadeuszx.slawinski@linux.intel.comReviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>

If ipc->ops.reply_msg_match is NULL, we may end up using uninitialized
mask value.

reported by smatch:
sound/soc/intel/common/sst-ipc.c:266 sst_ipc_reply_find_msg() error: uninitialized symbol 'mask'.
Signed-off-by: NAmadeusz Sławiński <amadeuszx.slawinski@intel.com>
Link: https://lore.kernel.org/r/20190827141712.21015-3-amadeuszx.slawinski@linux.intel.comReviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

For copying from __iomem, we should use __ioread32_copy.

reported by sparse:
sound/soc/intel/skylake/skl-debug.c:437:34: warning: incorrect type in argument 1 (different address spaces)
sound/soc/intel/skylake/skl-debug.c:437:34:    expected void [noderef] <asn:2> *to
sound/soc/intel/skylake/skl-debug.c:437:34:    got unsigned char *
sound/soc/intel/skylake/skl-debug.c:437:51: warning: incorrect type in argument 2 (different address spaces)
sound/soc/intel/skylake/skl-debug.c:437:51:    expected void const *from
sound/soc/intel/skylake/skl-debug.c:437:51:    got void [noderef] <asn:2> *[assigned] fw_reg_addr
Signed-off-by: NAmadeusz Sławiński <amadeuszx.slawinski@intel.com>
Link: https://lore.kernel.org/r/20190827141712.21015-2-amadeuszx.slawinski@linux.intel.comReviewed-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
Cc: stable@vger.kernel.org

While do rand build without GPIOLIB, we get Kconfig warning:\

WARNING: unmet direct dependencies detected for SND_SOC_MAX98357A
  Depends on [n]: SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] && GPIOLIB [=n]
  Selected by [m]:
  - SND_SOC_AMD_CZ_DA7219MX98357_MACH [=m] && SOUND [=y] && !UML && SND [=m] && SND_SOC [=m] && SND_SOC_AMD_ACP [=m] && I2C [=y]

Add GPIOLIB dependency to fix this.
Reported-by: NHulk Robot <hulkci@huawei.com>
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190822143007.73644-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

Since hw_free() can be called multiple times and not just after a stop
trigger command, we should check whether the RX or TX ready interrupt was
truly enabled previously. For this, we assure that the condition of the
wait event is always true, except when RX/TX interrupts are enabled.

Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: NCodrin Ciubotariu <codrin.ciubotariu@microchip.com>
Link: https://lore.kernel.org/r/20190820162411.24836-3-codrin.ciubotariu@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

If hw_free() gets called after hw_params(), GCLK remains prepared,
preventing further use of it. This patch fixes this by unpreparing the
clock in hw_free() or if hw_params() gets an error.

Fixes: 7e0cdf545a55 ("ASoC: mchp-i2s-mcc: add driver for I2SC Multi-Channel Controller")
Signed-off-by: NCodrin Ciubotariu <codrin.ciubotariu@microchip.com>
Link: https://lore.kernel.org/r/20190820162411.24836-2-codrin.ciubotariu@microchip.comSigned-off-by: NMark Brown <broonie@kernel.org>

So far the regmap and the dmaengine PCM are registered after our component
has been, which means that our driver isn't properly initialised by then.

Let's fix that.
Signed-off-by: NMaxime Ripard <maxime.ripard@bootlin.com>
Link: https://lore.kernel.org/r/67e303f37f141ef73ce9ed47d7f831b63c694424.1566242458.git-series.maxime.ripard@bootlin.comSigned-off-by: NMark Brown <broonie@kernel.org>

Make '* Capture Mode' a mux. This makes DAPM know that in single-ended
mode only inverting mux paths need to be enabled.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/125cd3c9f298da9b08a4d6002d4c00d70a898950.1566298834.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Trivial fix for typo in "Capture Inverting Mux"es' name.
Signed-off-by: NMichał Mirosław <mirq-linux@rere.qmqm.pl>
Acked-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/f95ae1085f9f3c137a122c4d95728711613c15f7.1566298834.git.mirq-linux@rere.qmqm.plSigned-off-by: NMark Brown <broonie@kernel.org>

Every single baytrail chromebook sets PMC to 0, as can be seeing
below by searching through coreboot source code:
	$ grep -rl "PMC_PLT_CLK\[0\]" .
	./rambi/variants/glimmer/devicetree.cb
	./rambi/variants/clapper/devicetree.cb
	./rambi/variants/swanky/devicetree.cb
	./rambi/variants/enguarde/devicetree.cb
	./rambi/variants/winky/devicetree.cb
	./rambi/variants/kip/devicetree.cb
	./rambi/variants/squawks/devicetree.cb
	./rambi/variants/orco/devicetree.cb
	./rambi/variants/ninja/devicetree.cb
	./rambi/variants/heli/devicetree.cb
	./rambi/variants/sumo/devicetree.cb
	./rambi/variants/banjo/devicetree.cb
	./rambi/variants/candy/devicetree.cb
	./rambi/variants/gnawty/devicetree.cb
	./rambi/variants/rambi/devicetree.cb
	./rambi/variants/quawks/devicetree.cb

Plus, Cyan (only non-baytrail chromebook with max98090) also needs
this patch for audio to work.

Thus, this commit adds all the missing devices to bsw_max98090 quirk
table, implemented by commit a182ecd3 ("ASoC: intel:
cht_bsw_max98090_ti: Add quirk for boards using pmc_plt_clk_0").
Signed-off-by: NDaniel Stuart <daniel.stuart14@gmail.com>
Link: https://lore.kernel.org/r/20190815171300.30126-1-daniel.stuart14@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

The tohdmitx glue uses regmap MMIO so it should require it.

Fixes: c8609f38 ("ASoC: meson: add g12a tohdmitx control")
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20190820123510.22491-1-jbrunet@baylibre.comSigned-off-by: NMark Brown <broonie@kernel.org>

Use the devm variant to get the formatter reset so it is properly freed
on device removal

Fixes: 751bd5db ("ASoC: meson: axg-tdm-formatter: add reset")
Signed-off-by: NJerome Brunet <jbrunet@baylibre.com>
Link: https://lore.kernel.org/r/20190820123413.22249-1-jbrunet@baylibre.comSigned-off-by: NMark Brown <broonie@kernel.org>

When transitioning to supend state, uniphier_aio_dai_suspend() is called
and asserts reset lines and disables clocks.

However, if there are two or more DAIs, uniphier_aio_dai_suspend() are
called multiple times, and double reset assersion will cause.

This patch defines the counter that has the number of DAIs at first, and
whenever uniphier_aio_dai_suspend() are called, it decrements the
counter. And only if the counter is zero, it asserts reset lines and
disables clocks.

In the same way, uniphier_aio_dai_resume() are called, it increments the
counter after deasserting reset lines and enabling clocks.

Fixes: 139a3420 ("ASoC: uniphier: add support for UniPhier AIO CPU DAI driver")
Signed-off-by: NKunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1566281764-14059-1-git-send-email-hayashi.kunihiko@socionext.comSigned-off-by: NMark Brown <broonie@kernel.org>

For i.MX6 SoloX, there is a mode of the SoC to shutdown all power
source of modules during system suspend and resume procedure.
Thus, AUDMUX needs to save all the values of registers before the
system suspend and restore them after the system resume.
Signed-off-by: NShengjiu Wang <shengjiu.wang@nxp.com>
Link: https://lore.kernel.org/r/1565931794-7218-1-git-send-email-shengjiu.wang@nxp.comSigned-off-by: NMark Brown <broonie@kernel.org>

sound/soc/codecs/wm8737.c:112:29: warning:
 high_3d defined but not used [-Wunused-const-variable=]

'high_3d' should be used for 3D High Cut-off.
Reported-by: NHulk Robot <hulkci@huawei.com>
Fixes: 2a9ae13a ("ASoC: Add initial WM8737 driver")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Acked-by: NCharles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20190815091920.64480-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

sound/soc/codecs/cs4349.c:358:32: warning:
 cs4349_runtime_pm defined but not used [-Wunused-const-variable=]

cs4349_runtime_pm ops already defined, it seems
we should enable it.
Reported-by: NHulk Robot <hulkci@huawei.com>
Fixes: e40da86a ("ASoC: cs4349: Add support for Cirrus Logic CS4349")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190815090157.70036-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

It seems 'es8328_rline_enum' should be used
in es8328_right_line_controls

Fixes: 567e4f98 ("ASoC: add es8328 codec driver")
Signed-off-by: NYueHaibing <yuehaibing@huawei.com>
Link: https://lore.kernel.org/r/20190815092300.68712-1-yuehaibing@huawei.comSigned-off-by: NMark Brown <broonie@kernel.org>

From stress testing of arecord, we found that period size
greater than ~900 will bring pl330 to DYING state and
can not recover within 100 iterations.
The result is that arecord will stuck and get I/O error,
and issue can not be recovered until reboot.

This issue does not happen when period size is small.
Set constraint of period size to 240 to prevent such issue.
With the constraint, there will be no issue after 2000 iterations.

We can revert this patch once the root cause is found
in rockchip's pl330 implementation.
Signed-off-by: NCheng-Yi Chiang <cychiang@chromium.org>
Link: https://lore.kernel.org/r/20190813074430.191791-1-cychiang@chromium.orgSigned-off-by: NMark Brown <broonie@kernel.org>

We need add DAPM MIC endpoint widget "SoC DMIC" and route, to enable
DMIC PCM DAPM support.
Signed-off-by: NKeyon Jie <yang.jie@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190809232236.21182-3-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

hdac_hdmi_present_sense() calls the audio component to get ELD update,
then it reports the jack status change and updates DAPM graph
accordingly.  This works when it's called from the normal code paths.

However, it may lead to a dead lock when it's called from the audio
component notifier.  Namely, the DAPM update involves with the runtime
PM, and it eventually calls again the audio component get_power()
ops.  Since i915 driver already takes a mutex around the audio
component ops calls, we'll eventually get the mutex doubly.

As a workaround, in this patch, only the jack state is updated in the
code path from hdac_hdmi_eld_notify_cb(), and the DAPM update is
deferred to a work so that it's processed in another context.
Reported-by: NImre Deak <imre.deak@intel.com>
Signed-off-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190809151531.24359-1-tiwai@suse.deSigned-off-by: NMark Brown <broonie@kernel.org>

There is a race between hda codec device removing and the
jack-detecting work, which will lead to a page fault issue as the
latter work is accessing codec device which could be already removed.

Here add the cancellation of jack-detecting work before codecs are actually
removed to avoid the race and fix the issue.

Bug: https://github.com/thesofproject/linux/issues/1067Signed-off-by: NKeyon Jie <yang.jie@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190807145030.26117-1-pierre-louis.bossart@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

On some platforms, sound card registration fails when a HDMI
monitor is not connected. This is caused by a recent commit
that switched the order in which the HDA controller and the
i915 are initialized. Initializing the i915 before initializing
the HDA controller fixes the problem.

Fixes: be1b577d ("ASoC: SOF: Intel: hda: fix the hda init chip"
Signed-off-by: NRanjani Sridharan <ranjani.sridharan@linux.intel.com>
Signed-off-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: NTakashi Iwai <tiwai@suse.de>
Link: https://lore.kernel.org/r/20190806221958.19180-1-ranjani.sridharan@linux.intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

ADG is using clk_get_rate() under atomic context, thus, we might
have scheduling issue.
To avoid this issue, we need to get/keep clk rate under
non atomic context.

We need to handle ADG as special device at Renesas Sound driver.
From SW point of view, we want to impletent it as
rsnd_mod_ops :: prepare, but it makes code just complicate.

To avoid complicated code/patch, this patch adds new clk_rate[] array,
and keep clk IN rate when rsnd_adg_clk_enable() was called.
Reported-by: NLeon Kong <Leon.KONG@cn.bosch.com>
Signed-off-by: NKuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: NLeon Kong <Leon.KONG@cn.bosch.com>
Link: https://lore.kernel.org/r/87v9vb0xkp.wl-kuninori.morimoto.gx@renesas.comSigned-off-by: NMark Brown <broonie@kernel.org>

Signed-off-by: NMark Brown <broonie@kernel.org>

We shouldn't assume CPU physical address we get from page_to_phys()
is same as DMA address we get from dma_alloc_coherent(). On x86_64,
we won't run into any problem with the assumption when dma_ops is
nommu_dma_ops. However, DMA address is IOVA when IOMMU is enabled.
And it's most likely different from CPU physical address when AMD
IOMMU is not in passthrough mode.

This patch fixes page faults when IOMMU is enabled.
Signed-off-by: NVijendar Mukunda <vijendar.mukunda@amd.com>
Link: https://lore.kernel.org/r/1564753899-17124-2-git-send-email-Vijendar.Mukunda@amd.comSigned-off-by: NMark Brown <broonie@kernel.org>

AMD platform device acp3x_rv_i2s created by parent PCI device
driver. Pass struct device of the parent to
snd_pcm_lib_preallocate_pages() so dma_alloc_coherent() can use
correct dma_ops. Otherwise, it will use default dma_ops which
is nommu_dma_ops on x86_64 even when IOMMU is enabled and
set to non passthrough mode.
Signed-off-by: NVijendar Mukunda <vijendar.mukunda@amd.com>
Link: https://lore.kernel.org/r/1564753899-17124-1-git-send-email-Vijendar.Mukunda@amd.comSigned-off-by: NMark Brown <broonie@kernel.org>

88200 and 96000 sampling rate was not enabled on driver, so can't be played.

The error information:
max98373 3-0031：rate 96000 not supported
max98373 3-0031：ASoC: can't set max98373-aif1 hw params: -22
Signed-off-by: Nfengchunguo <chunguo.feng@amlogic.com>
Link: https://lore.kernel.org/r/20190731074156.5620-1-chunguo.feng@amlogic.comSigned-off-by: NMark Brown <broonie@kernel.org>

The A64 audio codec uses the original I2S block but the SR and
WSS computation currently assigned is for the newer block.

Fixes: 619c15f7 (ASoC: sun4i-i2s: Change SR and WSS computation)
Signed-off-by: NMarcus Cooper <codekipper@gmail.com>
Link: https://lore.kernel.org/r/20190729152130.27955-1-codekipper@gmail.comSigned-off-by: NMark Brown <broonie@kernel.org>

Adding myself to Intel ASoC drivers maintainers list.
Signed-off-by: NCezary Rojewski <cezary.rojewski@intel.com>
Acked-by: NPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Link: https://lore.kernel.org/r/20190726181517.27655-1-cezary.rojewski@intel.comSigned-off-by: NMark Brown <broonie@kernel.org>

The slot_width is a property for the bus while the constraint for
SNDRV_PCM_HW_PARAM_SAMPLE_BITS is for the in memory format.

Applying slot_width constraint to sample_bits works most of the time, but
it will blacklist valid formats in some cases.

With slot_width 24 we can support S24_3LE and S24_LE formats as they both
look the same on the bus, but a a 24 constraint on sample_bits would not
allow S24_LE as it is stored in 32bits in memory.

Implement a simple hw_rule function to allow all formats which require less
or equal number of bits on the bus as slot_width (if configured).
Signed-off-by: NPeter Ujfalusi <peter.ujfalusi@ti.com>
Link: https://lore.kernel.org/r/20190726064244.3762-2-peter.ujfalusi@ti.comSigned-off-by: NMark Brown <broonie@kernel.org>