summaryrefslogtreecommitdiff
path: root/sound/soc/codecs/rt5514.c
AgeCommit message (Collapse)AuthorFilesLines
2017-07-03Merge remote-tracking branches 'asoc/topic/rt5614', 'asoc/topic/rt5645', ↵Mark Brown1-2/+2
'asoc/topic/rt5651', 'asoc/topic/rt5665' and 'asoc/topic/rt5670' into asoc-next
2017-05-17ASoC: rt5514: Add ACPI match IDOder Chiou1-0/+10
This patch adds the ACPI match ID for rt5514 codec. Signed-off-by: Hsin-Yu Chao <hychao@chromium.org> Signed-off-by: Oder Chiou <oder_chiou@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-05-14ASoC: rt5514: Add more width and channels support in the TDM modeOder Chiou1-2/+21
This patch adds more width and channels support in the TDM mode. Signed-off-by: Oder Chiou <oder_chiou@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-05-14ASoC: rt5514: fix gcc-7 warningArnd Bergmann1-2/+2
gcc-7 warns that there is a duplicate 'const' specifier in some variables that are declared using the SOC_ENUM_SINGLE_DECL macro: sound/soc/codecs/rt5514.c:398:14: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier] static const SOC_ENUM_SINGLE_DECL( sound/soc/codecs/rt5514.c:405:14: error: duplicate 'const' declaration specifier [-Werror=duplicate-decl-specifier] static const SOC_ENUM_SINGLE_DECL( This removes one to fix the warning. Fixes: 4a6180ea7399 ("ASoC: rt5514: add rt5514 codec driver") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-04-14ASoC: rt5514: Unconfuse the rt5514 at probe / resume timeDouglas Anderson1-0/+28
The rt5514 can get confused and incorrectly detect a start bit if the SCL/SDA lines happen to both go low and then high again. This situation has been seen to happen at reboot time and is also theoretically possible during suspend/resume if the rt5514 keeps power but we shut down the i2c connection. When this happens the rt5514 is confused about the state of the i2c bus and won't recognize its own address. That will lead to the rt5514 incorrectly NAKing the first transfer. A single i2c transfer to any address should be enough to get the rt5514 out of this funky state. It is currently believed that this problem should be fixed in the rt5514 driver itself because it seems that the i2c controller in the rt5514 is easily confused. Most i2c devices wouldn't detect a start bit in this case. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-04-14ASoC: rt5514: Avoid relying on uninitialized "val" valueDouglas Anderson1-3/+3
In rt5514_i2c_probe() if the regmap_read(RT5514_VENDOR_ID2) fails then "val" may be left as uninitialized. Current code relies on "val" not being RT5514_DEVICE_ID, but that's potentially unsafe. Let's check for errors from regmap_read() and also explicitly init the value do we're not passing a possibly uninitialized int to printk. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2017-04-14ASoC: rt5514: Mark rt5514_i2c_driver as staticDouglas Anderson1-1/+1
There's no reason for rt5514_i2c_driver to be non-static. Signed-off-by: Douglas Anderson <dianders@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-10-25ASoC: rt5514: Add the DMIC initial delay to wait it ready.Oder Chiou1-0/+17
Due to the DMIC that needs time to initial after the MCLK is provided, the field of delay time is implemented by the platform data. Signed-off-by: Oder Chiou <oder_chiou@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-09-29Merge remote-tracking branches 'asoc/topic/ac97', 'asoc/topic/ak4104', ↵Mark Brown1-6/+8
'asoc/topic/arizona', 'asoc/topic/atmel' and 'asoc/topic/codec-component' into asoc-next
2016-09-12ASoC: rt5514: make the volume TLV to match the units 0.01dBOder Chiou1-3/+3
The volume have a step of 0.375dB, but TLV uses the units 0.01dB. It should be changed to a step of 0.75dB to match the units of TLV. Signed-off-by: Oder Chiou <oder_chiou@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-08-08ASoC: codec duplicated callback function goes to component on rt5514Kuninori Morimoto1-6/+8
codec driver and component driver has duplicated callback functions, and codec side functions are just copied to component side when register timing. This was quick-hack, but no longer needed. This patch moves these functions from codec driver to component driver. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-07-25Merge remote-tracking branches 'asoc/topic/rt5514', 'asoc/topic/rt5614', ↵Mark Brown1-2/+166
'asoc/topic/rt5670' and 'asoc/topic/s8' into asoc-next
2016-06-22ASoC: rt5514: Add the MCLK handlingOder Chiou1-0/+32
The patch adds the control of MCLK that depends on the status of DAPM. Signed-off-by: Oder Chiou <oder_chiou@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-06-07ASoC: rt5514: add rt5514 SPI driverOder Chiou1-2/+134
The device has multiple control interfaces, I2C and SPI. The I2C interface mainly controls the register settings of codec. The SPI interface is in order to provide the high speed transmission of data. For example, high bandwidth memory read/write of DSP. The patch adds the rt5514 SPI driver for loading the firmware of DSP and retrieving the voice data from DSP after the system is waked up by specific voice. Signed-off-by: Oder Chiou <oder_chiou@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-03ASoC: rt5514: add rt5514 codec driverOder Chiou1-0/+982
This is the initial codec driver for rt5514. The codec includes a low power DSP for voice wake up. The register address is incremental by 4 in the DSP memory map. In order to recover the codec settings in the codec mode and manipulate the DSP mode for voice wake up, we use the multi-level register map. One is for ALSA API in codec mode that can be recovered by cache before recording. Another is for DSP related settings that can be accessed with 32bit address of the DSP in the application of voice wake up. Signed-off-by: Oder Chiou <oder_chiou@realtek.com> Signed-off-by: Mark Brown <broonie@kernel.org>