The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over an I2S DAI and as such should
have endianness applied.
A fixup is also required to use the width directly rather than relying
on the format in hw_params, now both little and big endian would be
supported.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-25-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over an I2S DAI and as such should
have endianness applied.
As the core will now expand the formats to cover both endian types,
remove the redundant manual specification of both.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-20-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over an I2S DAI and as such should
have endianness applied.
As the core will now expand the formats to cover both endian types,
remove the redundant manual specification of both.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-19-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The endianness flag is used on the CODEC side to specify an
ambivalence to endian, typically because it is lost over the hardware
link. This device receives audio over an I2S DAI and as such should
have endianness applied.
As the core will now expand the formats to cover both endian types,
remove the redundant manual specification of both.
Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20220504170905.332415-18-ckeepax@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
The i2c id table is moved up before the probe function, as suggested
by Wolfram Sang.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220501171009.45060-1-steve@sk2.org
Signed-off-by: Mark Brown <broonie@kernel.org>
During probe, determine if the chip is in fact an ADAU1761
even though an ADAU1361 is specified, and perform additional
operations to enable the ADAU1761 to behave as an ADAU1361,
i.e. disregarding the DSP and setting up routing and PM
transparently.
This enables either chip to be mounted when an ADAU1361 is specified.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Link: https://lore.kernel.org/r/alpine.DEB.2.21.2204281841290.5574@lnxricardw1.se.axis.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The previous fix for event generation for custom controls compared the
value already in the register with the value being written, missing the
logic that only applies the value to the register when the control is
already enabled. Fix this, compare the value cached in the driver data
rather than the register.
This should really be an autodisable control rather than open coded.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220428113221.15326-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
This series of patches adds support for Analog Devices MAX98396
mono amplifier with IV sense. The device provides a PCM interface
for audio data and a standard I2C interface for control data
communication. This driver also supports MAX98397 which is
a variant of MAX98396 with wide input supply range.
Signed-off-by: Ryan Lee <ryan.lee.analog@gmail.com>
Reported-by: kernel test robot <lkp@intel.com>
Link: https://lore.kernel.org/r/20220423021558.1773598-1-ryan.lee.analog@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The only effect of returning an error code in an i2c remove callback
(compared to returning zero) is that the i2c core emits a generic
warning. The device is still removed.
So even if disabling the regulators fails it's sensible to return zero
to suppress the additional generic and little helpful error message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Link: https://lore.kernel.org/r/20220425193206.61710-1-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
In the context of an i2c probe, i2c_match_id with the module id table
and the probed client never returns null, so removing the null check
on the i2c_device_id pointer is safe.
The i2c id tables are moved up before the probe function, as
suggested by Wolfram Sang, except where the existing code already had
a declaration for the of_device_id table.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220415160613.148882-7-steve@sk2.org
Signed-off-by: Mark Brown <broonie@kernel.org>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
The i2c id tables are moved up before the probe function, as
suggested by Wolfram Sang, except where the existing code already had
a declaration for the of_device_id table.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220415160613.148882-6-steve@sk2.org
Signed-off-by: Mark Brown <broonie@kernel.org>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
The i2c id table is moved up before the probe function, as suggested
by Wolfram Sang.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220415160613.148882-5-steve@sk2.org
Signed-off-by: Mark Brown <broonie@kernel.org>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
In the context of an i2c probe, i2c_match_id with the module id table
and the probed client never returns null, so removing the null check
on the i2c_device_id pointer is safe.
The i2c id tables are moved up before the probe function, as
suggested by Wolfram Sang.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220415160613.148882-4-steve@sk2.org
Signed-off-by: Mark Brown <broonie@kernel.org>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
The i2c id tables are moved up before the probe function, as
suggested by Wolfram Sang.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220415160613.148882-3-steve@sk2.org
Signed-off-by: Mark Brown <broonie@kernel.org>
As part of the ongoing i2c transition to the simple probe
("probe_new"), this patch uses i2c_match_id to retrieve the
driver_data for the probed device. The id parameter is thus no longer
necessary and the simple probe can be used instead.
Signed-off-by: Stephen Kitt <steve@sk2.org>
Link: https://lore.kernel.org/r/20220415160613.148882-2-steve@sk2.org
Signed-off-by: Mark Brown <broonie@kernel.org>
The max98090 driver has a custom put function for some controls which can
only be updated in certain circumstances which makes no effort to validate
that input is suitable for the control, allowing out of spec values to be
written to the hardware and presented to userspace. Fix this by returning
an error when invalid values are written.
Signed-off-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20220420193454.2647908-1-broonie@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
snd_soc_card_jack_new() allowed to create jack kcontrol without pins,
but did not create kcontrols. The jack would not have kcontrols if pins
were not going to be added.
This renames the old snd_soc_card_jack_new() to
snd_soc_card_jack_new_pins() for use when pins are provided or will be
added later. The new snd_soc_card_jack_new() appropriately creates a
jack for use without pins and adds a kcontrol.
Signed-off-by: Akihiko Odaki <akihiko.odaki@gmail.com>
Link: https://lore.kernel.org/r/20220408041114.6024-1-akihiko.odaki@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
