History log of /openbmc/linux/sound/soc/codecs/rt5651.h (Results 26 – 36 of 36)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# e6eb0207 04-Mar-2018 Hans de Goede <hdegoede@redhat.com>

ASoC: rt5651: Allow specifying the OVCD scale-factor through a device-property

OVer-Current-Detection (OVCD) for the micbias current is used to detect if
an inserted jack is a headset or

ASoC: rt5651: Allow specifying the OVCD scale-factor through a device-property

OVer-Current-Detection (OVCD) for the micbias current is used to detect if
an inserted jack is a headset or headphones (mic shorted to ground).

The threshold for at which current the OVCD triggers on the rt5651 is not
only controlled by setting the absolute current limit, but also by setting
a scale factor which applies to the limit. Testing has shown that we need
to set both (depending on the board).

This commit adds support for the sofar unused OVCD scale-factor register
and adds support for specifying non-default values for it through the
"realtek,over-current-scale-factor" device-property.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 583a9deb 04-Mar-2018 Hans de Goede <hdegoede@redhat.com>

ASoC: rt5651: Allow specifying over-current threshold through a device-property

OVer-Current-Detection (OVCD) for the micbias current is used to detect
if an inserted jack is a headset o

ASoC: rt5651: Allow specifying over-current threshold through a device-property

OVer-Current-Detection (OVCD) for the micbias current is used to detect
if an inserted jack is a headset or headphones (mic shorted to ground).

Some boards may need different values for the OVCD current threshold
because of a resistor on the board in serial with or parallel to the
jack mic contact.

This commit adds support for configuring the OCVD current threshold
through the "realtek,over-current-threshold-microamp" device-property.

Note this commit changes the default value from 600uA to 2000uA,
because testing has shown 600uA to be a poor default.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 1cf5b504 04-Mar-2018 Hans de Goede <hdegoede@redhat.com>

ASoC: rt5651: Make rt5651_apply_properties() private

The idea behind exporting rt5651_apply_properties(), was for it to be used
on platforms where the platform code may need to add devic

ASoC: rt5651: Make rt5651_apply_properties() private

The idea behind exporting rt5651_apply_properties(), was for it to be used
on platforms where the platform code may need to add device-properties,
rather then relying only on properties set by the firmware. The platform
code could then call rt5651_apply_properties() after adding properties to
make sure that the codec driver was aware of the new properties.

But this is not necessary, as long as we do all property parsing from
the codec component-driver's probe function (or later) then the machine
driver can attach properties before calling snd_soc_register_card and
calling rt5651_apply_properties() for ordering reasons is not necessary.

This commit makes rt5651_apply_properties() private and adds 2 comments
documenting that all property parsing must be done from the codec
component-driver's probe function.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 5f293d43 25-Feb-2018 Hans de Goede <hdegoede@redhat.com>

ASoC: rt5651: Add rt5651_apply_properties() helper function

Move the applying of the differential input and dmic properties to a new
rt5651_apply_properties() helper function. This new f

ASoC: rt5651: Add rt5651_apply_properties() helper function

Move the applying of the differential input and dmic properties to a new
rt5651_apply_properties() helper function. This new function can be called
by platform code which attaches properties after probe() has run to apply
these new properties.

Note this also moves the time when we apply these properties for DT
platforms from i2c-probe to snd-component-probe time, this should not
result in any functional difference.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 6f0b819a 25-Feb-2018 Hans de Goede <hdegoede@redhat.com>

ASoC: rt5651: Use standard component set_jack callback

Use the standard component set_jack callback instead of defining a codec
private API for this.

Tested-by: Carlo Caione <ca

ASoC: rt5651: Use standard component set_jack callback

Use the standard component set_jack callback instead of defining a codec
private API for this.

Tested-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# f06da4fd 25-Feb-2018 Hans de Goede <hdegoede@redhat.com>

ASoC: rt5651: Move all jack-detect initialization to rt5651_set_jack_detect

Move all jack-detect initialization to rt5651_set_jack_detect. The main
reason to do this is so that platform

ASoC: rt5651: Move all jack-detect initialization to rt5651_set_jack_detect

Move all jack-detect initialization to rt5651_set_jack_detect. The main
reason to do this is so that platform code can setup jack-detect properties
after the device has been probed, which unfortunately is necessary on some
platforms.

This has 2 additional advantages:
1) Grouping all jack-detect init together makes it easier to follow what
is happening and results in a small reduction in the number of loc.
2) Before we would register the irq handler before rt5651->hp_jack was
assigned, leading to a potential NULL deref if the jack_detect work runs
before the machine driver has called set_jack.

Tested-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 54e3a3a1 25-Feb-2018 Hans de Goede <hdegoede@redhat.com>

ASoC: rt5651: Remove unused rt5651_platform_data

There are no in tree users of platform-data for the rt5651 codec driver,
so lets remove support for it.

Signed-off-by: Hans de G

ASoC: rt5651: Remove unused rt5651_platform_data

There are no in tree users of platform-data for the rt5651 codec driver,
so lets remove support for it.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 17b52010 28-Jan-2018 Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>

ASoC: rt5651: replace codec to component

Now we can replace Codec to Component. Let's do it.

Note:
xxx_codec_xxx() -> xxx_component_xxx()
.idle_

ASoC: rt5651: replace codec to component

Now we can replace Codec to Component. Let's do it.

Note:
xxx_codec_xxx() -> xxx_component_xxx()
.idle_bias_off = 1 -> .idle_bias_on = 0
.ignore_pmdown_time = 0 -> .use_pmdown_time = 1
- -> .endianness = 1
- -> .non_legacy_dai_naming = 1

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


# 80bbe4a3 20-Oct-2017 Carlo Caione <carlo@endlessm.com>

ASoC: rt5651: Enable jack detection on JD* pins

Enable jack detection for the RT5651 codec on the JD* pins.

Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Mark

ASoC: rt5651: Enable jack detection on JD* pins

Enable jack detection for the RT5651 codec on the JD* pins.

Signed-off-by: Carlo Caione <carlo@endlessm.com>
Signed-off-by: Mark Brown <broonie@kernel.org>

show more ...


Revision tags: v4.13.5, v4.13, v4.12, v4.10.17, v4.10.16, v4.10.15, v4.10.14, v4.10.13, v4.10.12, v4.10.11, v4.10.10, v4.10.9, v4.10.8, v4.10.7, v4.10.6, v4.10.5, v4.10.4, v4.10.3, v4.10.2, v4.10.1, v4.10, v4.9, openbmc-4.4-20161121-1, v4.4.33, v4.4.32, v4.4.31, v4.4.30, v4.4.29, v4.4.28, v4.4.27, v4.7.10, openbmc-4.4-20161021-1, v4.7.9, v4.4.26, v4.7.8, v4.4.25, v4.4.24, v4.7.7, v4.8, v4.4.23, v4.7.6, v4.7.5, v4.4.22, v4.4.21, v4.7.4, v4.7.3, v4.4.20, v4.7.2, v4.4.19, openbmc-4.4-20160819-1, v4.7.1, v4.4.18, v4.4.17, openbmc-4.4-20160804-1, v4.4.16, v4.7, openbmc-4.4-20160722-1, openbmc-20160722-1, openbmc-20160713-1, v4.4.15, v4.6.4, v4.6.3, v4.4.14, v4.6.2, v4.4.13, openbmc-20160606-1, v4.6.1, v4.4.12, openbmc-20160521-1, v4.4.11, openbmc-20160518-1, v4.6, v4.4.10, openbmc-20160511-1, openbmc-20160505-1, v4.4.9, v4.4.8, v4.4.7, openbmc-20160329-2, openbmc-20160329-1, openbmc-20160321-1, v4.4.6, v4.5, v4.4.5, v4.4.4, v4.4.3, openbmc-20160222-1, v4.4.2, openbmc-20160212-1, openbmc-20160210-1, openbmc-20160202-2, openbmc-20160202-1, v4.4.1, openbmc-20160127-1, openbmc-20160120-1, v4.4, openbmc-20151217-1, openbmc-20151210-1, openbmc-20151202-1, openbmc-20151123-1, openbmc-20151118-1, openbmc-20151104-1, v4.3, openbmc-20151102-1, openbmc-20151028-1, v4.3-rc1, v4.2, v4.2-rc8, v4.2-rc7, v4.2-rc6, v4.2-rc5, v4.2-rc4, v4.2-rc3, v4.2-rc2, v4.2-rc1, v4.1, v4.1-rc8, v4.1-rc7, v4.1-rc6, v4.1-rc5, v4.1-rc4, v4.1-rc3, v4.1-rc2, v4.1-rc1, v4.0, v4.0-rc7, v4.0-rc6, v4.0-rc5, v4.0-rc4, v4.0-rc3, v4.0-rc2, v4.0-rc1, v3.19, v3.19-rc7, v3.19-rc6, v3.19-rc5, v3.19-rc4, v3.19-rc3, v3.19-rc2, v3.19-rc1, v3.18, v3.18-rc7, v3.18-rc6, v3.18-rc5, v3.18-rc4, v3.18-rc3, v3.18-rc2, v3.18-rc1, v3.17, v3.17-rc7, v3.17-rc6, v3.17-rc5, v3.17-rc4, v3.17-rc3, v3.17-rc2, v3.17-rc1, v3.16, v3.16-rc7, v3.16-rc6, v3.16-rc5, v3.16-rc4, v3.16-rc3, v3.16-rc2, v3.16-rc1, v3.15, v3.15-rc8, v3.15-rc7, v3.15-rc6
# 71c7a2d6 20-May-2014 Oder Chiou <oder_chiou@realtek.com>

ASoC: rt5640: Add the function of the PLL clock calculation to RL6231 shared support

The patch adds the function of the PLL clock calculation to RL6231 shared
support.

Signed-of

ASoC: rt5640: Add the function of the PLL clock calculation to RL6231 shared support

The patch adds the function of the PLL clock calculation to RL6231 shared
support.

Signed-off-by: Oder Chiou <oder_chiou@realtek.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

show more ...


Revision tags: v3.15-rc5, v3.15-rc4, v3.15-rc3, v3.15-rc2
# 40bc18a2 16-Apr-2014 Bard Liao <bardliao@realtek.com>

ASoC: add RT5651 CODEC driver

This patch adds the Realtek ALC5651 codec driver.

Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@linaro.org>


12