Use snd_soc_update_bits for read-modify-write register access instead of
open-coding it using snd_soc_read and snd_soc_write
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
This allows the device to be matched against the device tree using the
compatible flag directly, as is standard, rather than falling back to
matching .id_table against the non-vendor portion of the first compatible
property value.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Currently SND_SOC_JZ4740_CODEC depends on SOC_JZ4740 but SOC_JZ4740 is not
defined in any Kconfig. Thus the codec driver will not be built when select
"Build all ASoC CODEC drivers".
(Unless it is selected by SND_JZ4740_SOC_QI_LB60).
Remove the dependency with SOC_JZ4740, then this code driver can be built when
select "Build all ASoC CODEC drivers".
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Include linux/io.h to fix below build errors:
CC sound/soc/codecs/jz4740.o
sound/soc/codecs/jz4740.c: In function 'jz4740_codec_read':
sound/soc/codecs/jz4740.c:82: error: implicit declaration of function 'readl'
sound/soc/codecs/jz4740.c: In function 'jz4740_codec_write':
sound/soc/codecs/jz4740.c:92: error: implicit declaration of function 'writel'
sound/soc/codecs/jz4740.c: In function 'jz4740_codec_probe':
sound/soc/codecs/jz4740.c:373: error: implicit declaration of function 'ioremap'
sound/soc/codecs/jz4740.c:373: warning: assignment makes pointer from integer without a cast
sound/soc/codecs/jz4740.c:393: error: implicit declaration of function 'iounmap'
make[3]: *** [sound/soc/codecs/jz4740.o] Error 1
make[2]: *** [sound/soc/codecs] Error 2
make[1]: *** [sound/soc] Error 2
make: *** [sound] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If we fail to read the IRQ type from the interrupt controller don't
fail, just assume a value and solider on - we may fail later when we try
to request the IRQ but it's possible we'll succeed.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Document the device tree binding for the WM8903 codec, and modify the
driver to extract platform data from the device tree, if present.
Based on work by John Bonesio, but significantly reworked since then.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
If the WM8903 is hooked up to an interrupt, set the irq_active_low flag
in the default platform data based on the IRQ's IRQ_TYPE. Map IRQ_TYPE_NONE
(a lack of explicit configuration/restriction) to irq_active_low = false;
the previous default.
This code is mainly added to support device tree interrupt bindings,
although will work perfectly well in a non device tree system too.
Any interrupt controller that supports only a single IRQ_TYPE could
set each IRQ's type based on that restriction. This applies equally
with and without device tree. To cater for interrupt controllers
that don't do this, for which irqd_get_trigger_type() will return
IRQ_TYPE_NONE, the platform data irq_active_low field may be used
in systems that don't use device tree.
With device tree, every IRQ must have some IRQ_TYPE set.
Controllers that support DT and multiple IRQ_TYPEs must define the
interrupts property (as used in interrupt source nodes) such that it
defines the IRQ_TYPE to use. When the core DT setup code initializes
wm8903->irq, the interrupts property will be parsed, and as a side-
effect, set the IRQ's IRQ_TYPE for the WM8903 probe() function to read.
Controllers that support DT and a single IRQ_TYPE could arrange to
set the IRQ_TYPE somehow during their initialization, or hard-code
it during the processing of the child interrupts property.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The pdata pointer is now always valid. Remove any conditions that check
its validity.
This patch is mostly just removing an indentation level. One variable had
to be moved due to the removal of a scope, and one comment was split into
two. Viewing the patch with git show/diff -b will show that it's actually
very small.
Note that WM8903_MIC_BIAS_CONTROL_0 is now written unconditionally,
whereas it used to be written only if pdata was supplied. Since
defpdata.micdet_cfg = 0, this unconditional write simply echos the HW
defaults in the case where pdata is not supplied.
Based on work by John Bonesio, but significantly reworked since then.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
wm8903_platform_data.gpio_cfg[] was intended to be interpreted as follows:
0: Don't touch this GPIO's configuration register
1..7fff: Write that value to the GPIO's configuration register
8000: Write zero to the GPIO's configuration register
other: Undefined (invalid)
The rationale is that platform data is usually global data, and a value of
zero means that the field wasn't explicitly set to anything (e.g. because
the field was new to the pdata type, and existing users weren't update to
initialize it) and hence the value zero should be ignored. 0x8000 is an
explicit way to get 0 in the register.
The code worked this way until commit 7cfe561 "ASoC: wm8903: Expose GPIOs
through gpiolib", where the behaviour was changed due to my lack of
awareness of the above rationale.
This patch reverts to the intended behaviour, and updates all in-tree users
to use the correct scheme. This also makes WM8903 consistent with other
devices that use a similar scheme.
WM8903_GPIO_NO_CONFIG is also renamed to WM8903_GPIO_CONFIG_ZERO so that
its name accurately reflects its purpose.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Colin Cross <ccross@android.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
reg_cache_size is supposed to be the number of elements in the register cache,
not the size in bytes.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Using gpio_request_one can make the error handling simpler.
Also remove a redundant "Failed to issue reset" error message.
We already show the error message in uda1380_reset() error path.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Return proper error for uda1380_modinit if i2c_add_driver() fails.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
When no platform data is supplied, point pdata at a default platform
structure. This enables two future changes:
a) Defines the default platform data values in a single place.
b) There is always a valid pdata pointer, so some conditional code can
be simplified by a later patch.
Based on work by John Bonesio, but significantly reworked since then.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Get control of the device earlier and avoid trying to do an ASoC probe
on a card that won't work.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Converting to an rbtree cache as regcache doesn't have a flat cache.
Since the top of the register map is fairly sparse this should be an
overall win.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
We only do this on initial power on so it's at best a waste of time as
the core will have already defaulted to the same values.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
The driver used to use a complicated method to sync the register cache
after having brought the bias level up to standby in resume due to the
use of the write sequencer to manage the initial power up. Now that we
don't use the write sequencer there is no need for this and we can just
use snd_soc_cache_sync() directly.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Tested-by: Stephen Warren <swarren@nvidia.com>
Since they don't actually have power bits but do have events associated
with them it's important that we bootstrap their state properly which
making them virtual does.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The GPIO registers are 15 bits wide. Hence values, higher than 0x7fff are
not legal GPIO register values. Modify the pdata.gpio_cfg handling code
to reject all illegal values, not just WM8903_GPIO_NO_CONFIG (0x8000). This
will allow the later use of 0xffffffff as an invalid value in future device
tree bindings, meaning "don't touch this GPIO's configuration".
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
