January 2015 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [PATCH v3] ALSA: sound/atmel/ac97c.c: Add device tree support
by Alexander Stein 06 Jan '15

06 Jan '15

This adds device tree support for the AC97 controller. It uses the soc-ac97link bindings, but actually only ac97-reset is used. Signed-off-by: Alexander Stein <alexanders83(a)web.de> Acked-By Alexandre Belloni <alexandre.belloni(a)free-electrons.com> --- Changes in v3: * Renamed the compatible string to atmel,at91sam9263-ac97c * Added 'Acked-By Alexandre Belloni <alexandre.belloni(a)free-electrons.com>' Changes in v2: * It now uses the soc-ac97link bindings (partly) instead of defining its own. This should ease the transition to ASoC once a new driver has been written. sound/atmel/ac97c.c | 45 ++++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 42 insertions(+), 3 deletions(-) diff --git a/sound/atmel/ac97c.c b/sound/atmel/ac97c.c index 4f6b14d..a0df1b1 100644 --- a/sound/atmel/ac97c.c +++ b/sound/atmel/ac97c.c @@ -22,6 +22,9 @@ #include <linux/gpio.h> #include <linux/types.h> #include <linux/io.h> +#include <linux/of.h> +#include <linux/of_gpio.h> +#include <linux/of_device.h> #include <sound/core.h> #include <sound/initval.h> @@ -902,6 +905,40 @@ static void atmel_ac97c_reset(struct atmel_ac97c *chip) } } +#ifdef CONFIG_OF +static const struct of_device_id atmel_ac97c_dt_ids[] = { + { .compatible = "atmel,at91sam9263-ac97c", }, + { } +}; +MODULE_DEVICE_TABLE(of, atmel_ac97c_dt_ids); + +static struct ac97c_platform_data *atmel_ac97c_probe_dt(struct device *dev) +{ + struct ac97c_platform_data *pdata; + struct device_node *node = dev->of_node; + const struct of_device_id *match; + + if (!node) { + dev_err(dev, "Device does not have associated DT data\n"); + return ERR_PTR(-EINVAL); + } + + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); + if (!pdata) + return ERR_PTR(-ENOMEM); + + pdata->reset_pin = of_get_named_gpio(dev->of_node, "ac97-gpios", 2); + + return pdata; +} +#else +static struct ac97c_platform_data *atmel_ac97c_probe_dt(struct device *dev) +{ + dev_err(dev, "no platform data defined\n"); + return ERR_PTR(-ENXIO); +} +#endif + static int atmel_ac97c_probe(struct platform_device *pdev) { struct snd_card *card; @@ -922,10 +959,11 @@ static int atmel_ac97c_probe(struct platform_device *pdev) return -ENXIO; } - pdata = pdev->dev.platform_data; + pdata = dev_get_platdata(&pdev->dev); if (!pdata) { - dev_dbg(&pdev->dev, "no platform data\n"); - return -ENXIO; + pdata = atmel_ac97c_probe_dt(&pdev->dev); + if (IS_ERR(pdata)) + return PTR_ERR(pdata); } irq = platform_get_irq(pdev, 0); @@ -1204,6 +1242,7 @@ static struct platform_driver atmel_ac97c_driver = { .driver = { .name = "atmel_ac97c", .pm = ATMEL_AC97C_PM_OPS, + .of_match_table = of_match_ptr(atmel_ac97c_dt_ids), }, }; module_platform_driver(atmel_ac97c_driver); -- 2.2.1

2 1

[alsa-devel] [PATCH 1/8] ASoC: alc5632: Constify struct regmap_config and snd_soc_codec_driver
by Krzysztof Kozlowski 06 Jan '15

06 Jan '15

The regmap_config struct may be const because it is not modified by the driver and regmap_init() accepts pointer to const. Make struct snd_soc_codec_driver const as well (snd_soc_register_codec() accepts pointer to const). Signed-off-by: Krzysztof Kozlowski <k.kozlowski(a)samsung.com> --- sound/soc/codecs/alc5632.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/alc5632.c b/sound/soc/codecs/alc5632.c index d1fdbc266631..07630260e1ba 100644 --- a/sound/soc/codecs/alc5632.c +++ b/sound/soc/codecs/alc5632.c @@ -1066,7 +1066,7 @@ static int alc5632_probe(struct snd_soc_codec *codec) return 0; } -static struct snd_soc_codec_driver soc_codec_device_alc5632 = { +static const struct snd_soc_codec_driver soc_codec_device_alc5632 = { .probe = alc5632_probe, .resume = alc5632_resume, .set_bias_level = alc5632_set_bias_level, @@ -1080,7 +1080,7 @@ static struct snd_soc_codec_driver soc_codec_device_alc5632 = { .num_dapm_routes = ARRAY_SIZE(alc5632_dapm_routes), }; -static struct regmap_config alc5632_regmap = { +static const struct regmap_config alc5632_regmap = { .reg_bits = 8, .val_bits = 16, -- 1.9.1

4 12

Re: [alsa-devel] DSD over HDMI: audio data packetization
by Anssi Hannula 06 Jan '15

06 Jan '15

06.01.2015, 06:33, Andrej Falout kirjoitti: > Hi Anssi, Hi, > Just wondering how Microsoft documentation fits into this discussion: > > "Representing Formats for IEC 61937 Transmissions" > > http://msdn.microsoft.com/en-us/library/windows/desktop/dd316761%28v=vs.85%… > > > "Microsoft-provided HD Audio class driver supports PCM, AC3, DTS, AAC, > Dolby Digital Plus, WMA Pro, MAT(MLP) formats. The GUIDs for the > compressed audio formats that are not supported by the HD audio class > driver and can be implemented by third-party solutions are listed in the > following table. " > > CEA 861 Type SubFormat GUID Description > 0x08 > > 00000008-0cea-0010-8000-00aa00389b71 > > KSDATAFORMAT_SUBTYPE_IEC61937_ATRAC > > Adaptive Transform Acoustic Coding (ATRAC) > 0x09 > > 00000009-0cea-0010-8000-00aa00389b71 > > KSDATAFORMAT_SUBTYPE_IEC61937_ONE_BIT_AUDIO > > One-Bit Audio > 0x0d > > 0000000d-0cea-0010-8000-00aa00389b71 > > KSDATAFORMAT_SUBTYPE_IEC61937_DST > > Direct Stream Transport (DST)—lossless compressed DSD (Direct Stream > Digital). > > > And knowing that IEC 61937 from HDMI 1.3 also supports above 6.144 Mbps... > > Is there a doubt that above information is correct, and that DST/DST can > be carried over 61937 in Microsoft HDA class driver, in this example, by > "implementing a third-party solution" as described in this table? I think the One-Bit Audio and DST formats are just misnamed here and can't be carried over IEC 61937 (ATRAC can be) - the IEC 61937 specification does not cover One-Bit Audio or DST. I think the "third-party solution" refers to a driver implementing support for a non-HDA-spec HW feature which allows One-Bit audio / DST / raw packets to be transmitted (in a similar way "EPT" (Encoded Packet Type field in Pin Widget Control 7.3.3.13) allows setting HBR or ASP packet transmission). > Thanks, > Andrej Falout > > On Mon, Jan 5, 2015 at 4:46 PM, Anssi Hannula <anssi.hannula(a)iki.fi > <mailto:anssi.hannula@iki.fi>> wrote: > > 04.01.2015, 05:10, Xuebing Wang kirjoitti: > > Anssi, Libin, > > > > Thanks for your help. > > > > After a little bit of research, I do think it is possible to stream DSD > > over HDMI (the mechanism is as Anssi mentioned, similar way as HBR). > > > > Please see HDA spec: > > 3.7.1 Stream Format Structure > > (If the TYPE is set to Non-PCM, the controller just pushes data over the > > link and is not concerned > > with formatting. The base rate, data type, and number of Words (MULT) to > > send each valid frame > > are specified to control the rate at which the non-PCM data is sent.) > > > > 7.3.3.8 Converter Format > > > > What do you think? In order to implement this similiar mechanism > > (similar to HBR), I still have some detailed questions that I will write > > in another email. Thanks. > > That setting will still not allow you to send One-bit audio or DST > packets. The stream will still be encapsulated in either ASP or HBR > packets, depending on the value of the EPT field (Encoded Packet Type, > 7.3.3.13). > > > > > > On Thu, 2015-01-01 at 06:37 +0200, Anssi Hannula wrote: > >> 01.01.2015, 04:07, Yang, Libin kirjoitti: > >>> Hi, > >>> > >>>> -----Original Message----- > >>>> From: Anssi Hannula [mailto:anssi.hannula@iki.fi > <mailto:anssi.hannula@iki.fi>] > >>>> Sent: Wednesday, December 31, 2014 11:45 PM > >>>> To: Xuebing Wang > >>>> Cc: Yang, Libin; alsa-devel(a)alsa-project.org > <mailto:alsa-devel@alsa-project.org>; Lin, Mengdong; ; Takashi Iwai; ; > >>>> Wu Fengguang > >>>> Subject: Re: [alsa-devel] DSD over HDMI: audio data packetization > >>>> > >>>> 31.12.2014, 17:38, Xuebing Wang kirjoitti: > >>>>> Anssi, Libin, > >>>>> > >>>>> Thank you very much for your help. > >>>>> > >>>>> If L-PCM audio data packetization is done by hardware, is it > possible > >>>>> to implement DSD over HDMI on Intel integrated graphics? > Thanks again. > >>>> > >>>> I don't think so, unless: > >>>> > >>>> (a) It is possible to somehow encapsulate the stream in Audio > Sample > >>>> Packets and be accepted by the receiver (like e.g. AC3, DTS). > I'm not aware of > >>>> such a way. > >>>> > >>>> or: > >>>> (b) There is some undocumented feature in the Intel HDMI codecs > allowing > >>>> the driver to switch to DSD or driver-constructed packets > (instead of > >>>> ASP) in similar way as there is a way to switch to HBR packets. > >>>> > >>> > >>> Yes, I agree. And I'm not sure whether HDMI spec supports DSD. > >> > >> It does, via the "One Bit Audio" and "DST" formats (spec 5.3.9, > 5.3.10 > >> in 1.3a/1.4a). > > > > > > > -- > Anssi Hannula > > -- Anssi Hannula

2 2

Re: [alsa-devel] DSD over HDMI: audio data packetization
by Xuebing Wang 06 Jan '15

06 Jan '15

Andrej, I have a slight doubt about "KSDATAFORMAT_SUBTYPE_IEC61937_ONE_BIT_AUDIO". To be concise "IEC61937_ONE_BIT_AUDIO" I do not have all IEC 61937 specs, I can not find "IEC61937_ONE_BIT_AUDIO" in the list below. Part 1: General Part 2: Burst-info Part 3: Non-linear PCM bitstreams according to the AC-3 format Part 4: Non-linear PCM bitstreams according to the MPEG audio format Part 5: Non-linear PCM bitstreams according to the DTS (Digital Theater Systems) format(s) Part 6: Non-linear PCM bitstreams according to the MPEG-2 AAC and MPEG-4 AAC audio formats Part 7: Non-linear PCM bitstreams according to the ATRAC, ATRAC2/3 and ATRAC-X formats Part 8: Non-linear PCM bitstreams according to the Windows Media Audio (WMA) Professional format Part 9: Non-linear PCM bitstreams according to the MAT format Part 10: Non-linear PCM bitstreams according to the MPEG-4 audio lossless coding (ALS) format - Edition 1.0 Part 11: MPEG-4 AAC and its extensions in LATM/LOAS Part 12: Non-linear PCM bitstreams according to the DRA formats Thanks. On Tue, 2015-01-06 at 17:33 +1300, Andrej Falout wrote: > Hi Anssi, > > > Just wondering how Microsoft documentation fits into this discussion: > > "Representing Formats for IEC 61937 Transmissions" > > http://msdn.microsoft.com/en-us/library/windows/desktop/dd316761% > 28v=vs.85%29.aspx > > > "Microsoft-provided HD Audio class driver supports PCM, AC3, DTS, AAC, > Dolby Digital Plus, WMA Pro, MAT(MLP) formats. The GUIDs for the > compressed audio formats that are not supported by the HD audio class > driver and can be implemented by third-party solutions are listed in > the following table. " > > CEA 861 Type > SubFormat GUID > Description > 0x08 > 00000008-0cea-0010-8000-00aa00389b71 > > KSDATAFORMAT_SUBTYPE_IEC61937_ATRAC > > > Adaptive Transform > Acoustic Coding (ATRAC) > 0x09 > 00000009-0cea-0010-8000-00aa00389b71 > > KSDATAFORMAT_SUBTYPE_IEC61937_ONE_BIT_AUDIO > > > One-Bit Audio > 0x0d > 0000000d-0cea-0010-8000-00aa00389b71 > > KSDATAFORMAT_SUBTYPE_IEC61937_DST > > > Direct Stream Transport > (DST)—lossless > compressed DSD (Direct > Stream Digital). > > > And knowing that IEC 61937 from HDMI 1.3 also supports above 6.144 > Mbps... > > > Is there a doubt that above information is correct, and that DST/DST > can be carried over 61937 in Microsoft HDA class driver, in this > example, by "implementing a third-party solution" as described in this > table? > > > Thanks, > > Andrej Falout > > > On Mon, Jan 5, 2015 at 4:46 PM, Anssi Hannula <anssi.hannula(a)iki.fi> > wrote: > 04.01.2015, 05:10, Xuebing Wang kirjoitti: > > Anssi, Libin, > > > > Thanks for your help. > > > > After a little bit of research, I do think it is possible to > stream DSD > > over HDMI (the mechanism is as Anssi mentioned, similar way > as HBR). > > > > Please see HDA spec: > > 3.7.1 Stream Format Structure > > (If the TYPE is set to Non-PCM, the controller just pushes > data over the > > link and is not concerned > > with formatting. The base rate, data type, and number of > Words (MULT) to > > send each valid frame > > are specified to control the rate at which the non-PCM data > is sent.) > > > > 7.3.3.8 Converter Format > > > > What do you think? In order to implement this similiar > mechanism > > (similar to HBR), I still have some detailed questions that > I will write > > in another email. Thanks. > > That setting will still not allow you to send One-bit audio or > DST > packets. The stream will still be encapsulated in either ASP > or HBR > packets, depending on the value of the EPT field (Encoded > Packet Type, > 7.3.3.13). > > > > > > On Thu, 2015-01-01 at 06:37 +0200, Anssi Hannula wrote: > >> 01.01.2015, 04:07, Yang, Libin kirjoitti: > >>> Hi, > >>> > >>>> -----Original Message----- > >>>> From: Anssi Hannula [mailto:anssi.hannula@iki.fi] > >>>> Sent: Wednesday, December 31, 2014 11:45 PM > >>>> To: Xuebing Wang > >>>> Cc: Yang, Libin; alsa-devel(a)alsa-project.org; Lin, > Mengdong; ; Takashi Iwai; ; > >>>> Wu Fengguang > >>>> Subject: Re: [alsa-devel] DSD over HDMI: audio data > packetization > >>>> > >>>> 31.12.2014, 17:38, Xuebing Wang kirjoitti: > >>>>> Anssi, Libin, > >>>>> > >>>>> Thank you very much for your help. > >>>>> > >>>>> If L-PCM audio data packetization is done by hardware, > is it possible > >>>>> to implement DSD over HDMI on Intel integrated graphics? > Thanks again. > >>>> > >>>> I don't think so, unless: > >>>> > >>>> (a) It is possible to somehow encapsulate the stream in > Audio Sample > >>>> Packets and be accepted by the receiver (like e.g. AC3, > DTS). I'm not aware of > >>>> such a way. > >>>> > >>>> or: > >>>> (b) There is some undocumented feature in the Intel HDMI > codecs allowing > >>>> the driver to switch to DSD or driver-constructed packets > (instead of > >>>> ASP) in similar way as there is a way to switch to HBR > packets. > >>>> > >>> > >>> Yes, I agree. And I'm not sure whether HDMI spec supports > DSD. > >> > >> It does, via the "One Bit Audio" and "DST" formats (spec > 5.3.9, 5.3.10 > >> in 1.3a/1.4a). > > > > > > > > -- > Anssi Hannula > >

1 0

[alsa-devel] [PATCH 1/7] ASoC: dmaengine: Remove unnecessary snd_pcm_lib_preallocate_free_for_all()
by Lars-Peter Clausen 05 Jan '15

05 Jan '15

The ALSA core takes care that all preallocated memory is freed when the PCM itself is freed. There is no need to do this manually in the driver. Similarly there is also no need to do it on the pcm_new() error path as the PCM will be freed if a error is returned. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/soc-generic-dmaengine-pcm.c | 15 ++------------- 1 file changed, 2 insertions(+), 13 deletions(-) diff --git a/sound/soc/soc-generic-dmaengine-pcm.c b/sound/soc/soc-generic-dmaengine-pcm.c index b329b84..4864392 100644 --- a/sound/soc/soc-generic-dmaengine-pcm.c +++ b/sound/soc/soc-generic-dmaengine-pcm.c @@ -200,11 +200,6 @@ static int dmaengine_pcm_open(struct snd_pcm_substream *substream) return snd_dmaengine_pcm_open(substream, chan); } -static void dmaengine_pcm_free(struct snd_pcm *pcm) -{ - snd_pcm_lib_preallocate_free_for_all(pcm); -} - static struct dma_chan *dmaengine_pcm_compat_request_channel( struct snd_soc_pcm_runtime *rtd, struct snd_pcm_substream *substream) @@ -283,8 +278,7 @@ static int dmaengine_pcm_new(struct snd_soc_pcm_runtime *rtd) if (!pcm->chan[i]) { dev_err(rtd->platform->dev, "Missing dma channel for stream: %d\n", i); - ret = -EINVAL; - goto err_free; + return -EINVAL; } ret = snd_pcm_lib_preallocate_pages(substream, @@ -293,7 +287,7 @@ static int dmaengine_pcm_new(struct snd_soc_pcm_runtime *rtd) prealloc_buffer_size, max_buffer_size); if (ret) - goto err_free; + return ret; /* * This will only return false if we know for sure that at least @@ -307,10 +301,6 @@ static int dmaengine_pcm_new(struct snd_soc_pcm_runtime *rtd) } return 0; - -err_free: - dmaengine_pcm_free(rtd->pcm); - return ret; } static snd_pcm_uframes_t dmaengine_pcm_pointer( @@ -341,7 +331,6 @@ static const struct snd_soc_platform_driver dmaengine_pcm_platform = { }, .ops = &dmaengine_pcm_ops, .pcm_new = dmaengine_pcm_new, - .pcm_free = dmaengine_pcm_free, }; static const char * const dmaengine_pcm_dma_channel_names[] = { -- 1.8.0

3 8

[alsa-devel] [PATCH v2 00/10] audio timestamping evolutions
by Pierre-Louis Bossart 05 Jan '15

05 Jan '15

This series of patches was inspired by recent threads on the alsa mailing list, as well issues detected with existing and upcoming hardware: 1. there was a request from the PulseAudio community to get more information from drivers to make rewinds safer. While the conclusion was that it's nearly impossible for a driver developer to provide this information, there are however ways to assess the granularity of the hw_ptr updates using timestamping capabilities, and indirectly understand how safe rewinds might be. 2. There was also a request to add a start_at capability based either on system hr timers or a wall clock, which requires a means to expose both types of information to applications. Rather than adding new sets of timestamps, it is suggested the new start_at functionality relies on the new definition provides by these patches 3. For new hardware, there is a neeed to let low-level drivers handle timestamping instead of having the ALSA core do it. Similarly there is a need to let the low-level driver update the initial estimate for the trigger timestamp if there are delays to start a stream (eg. with USB) These patches try to provide an answer to these multiple needs by building on the work done two years ago to expose wall clock information to applications. The evolution is to let application select which audio timestamp they are interested in, track the delay and drifts between recurring measurements and get, when possible, an idea of the accuracy of the underlying hardware. A backwards compatible mode is provided in case userspace doesn't provide any timestamp selection (results based on HDAudio wallclock for playback, hw_ptr in all other cases). The first 4 patches are corrections for misses in the way the system and trigger timestamps are handled, and the last 6 provide the additional audio timestamping selection. A second batch is planned to enable hardware capabilities in a low-level drivers. A corresponding set of patches is available for alsa-lib. V2 changes: trigger_tstamp: trigger_tstamp_latched, pending redefined as bool trigger_tstamp_latched reset in snd_pcm_pre_start() audio_ts_config, report: keep separate structure but use different bitfields for in and out. use u32 instead of __u32, add comments that these structures are internal COMPAT backwards compatible mode, uses WALL_CLOCK/LINK for HDAudio playback and DEFAULT (hw_ptr) everywhere else INFO bits: reclaimed 32-bits from hw_params, renamed as info_ext moved all timestamp info to info_ext snd_pcm_status: read only 32-bit audio_tstamp_data, ignore all other fields Pierre-Louis Bossart (10): ALSA: core: don't override timestamp unconditionally ALSA: core: allow for trigger_tstamp snapshot in .trigger ALSA: hda: read trigger_timestamp immediately after starting DMA ALSA: usb: update trigger timestamp on first non-zero URB submitted ALSA: core: add info_ext field in hw_params and pcm_hardware ALSA: core: selection of audio_tstamp type and accuracy reports ALSA: core: pass audio tstamp config from userspace ALSA: core: pass audio tstamp config from userspace in compat mode ALSA: core: replace .wall_clock by .get_time_info ALSA: hda: replace .wallclock by .get_time_info Documentation/sound/alsa/timestamping.txt | 176 ++++++++++++++++++++++++++++++ include/sound/pcm.h | 71 +++++++++++- include/uapi/sound/asound.h | 31 +++++- sound/core/pcm_compat.c | 15 ++- sound/core/pcm_lib.c | 81 +++++++++----- sound/core/pcm_native.c | 41 ++++++- sound/pci/hda/hda_controller.c | 44 ++++++-- sound/usb/pcm.c | 9 ++ 8 files changed, 417 insertions(+), 51 deletions(-) create mode 100644 Documentation/sound/alsa/timestamping.txt -- 1.9.1

4 17

[alsa-devel] [PATCH] ASoC: adi: Add missing return statement.
by Andrew Jackson 05 Jan '15

05 Jan '15

From: Andrew Jackson <Andrew.Jackson(a)arm.com> The probe routine was disabling the clock even if the system was configured successfully. Add a return statement to leave clocks enabled. Signed-off-by: Andrew Jackson <Andrew.Jackson(a)arm.com> --- Spotted while reviewing clock preparation sound/soc/adi/axi-i2s.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/sound/soc/adi/axi-i2s.c b/sound/soc/adi/axi-i2s.c index 7752860..4c23381 100644 --- a/sound/soc/adi/axi-i2s.c +++ b/sound/soc/adi/axi-i2s.c @@ -240,6 +240,8 @@ static int axi_i2s_probe(struct platform_device *pdev) if (ret) goto err_clk_disable; + return 0; + err_clk_disable: clk_disable_unprepare(i2s->clk); return ret; -- 1.7.1

3 2

[alsa-devel] [PATCH 1/2] ASoC: byt-rt5640: Fix snd_soc_dapm_ignore_suspend() calls
by Lars-Peter Clausen 05 Jan '15

05 Jan '15

To work properly snd_soc_dapm_ignore_suspend() needs to be called on endpoint widgets. In this case those are the board level Speaker and Headphone widgets and not the CODEC output widgets that are connected to them. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/intel/byt-rt5640.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/sound/soc/intel/byt-rt5640.c b/sound/soc/intel/byt-rt5640.c index 0cba783..a51856e 100644 --- a/sound/soc/intel/byt-rt5640.c +++ b/sound/soc/intel/byt-rt5640.c @@ -171,13 +171,8 @@ static int byt_rt5640_init(struct snd_soc_pcm_runtime *runtime) return ret; } - snd_soc_dapm_ignore_suspend(dapm, "HPOL"); - snd_soc_dapm_ignore_suspend(dapm, "HPOR"); - - snd_soc_dapm_ignore_suspend(dapm, "SPOLP"); - snd_soc_dapm_ignore_suspend(dapm, "SPOLN"); - snd_soc_dapm_ignore_suspend(dapm, "SPORP"); - snd_soc_dapm_ignore_suspend(dapm, "SPORN"); + snd_soc_dapm_ignore_suspend(&card->dapm, "Headphone"); + snd_soc_dapm_ignore_suspend(&card->dapm, "Speaker"); return ret; } -- 1.8.0

3 3

[alsa-devel] [PATCH] ASoC: boardwell: Drop unnecessary snd_soc_dapm_enable() calls
by Lars-Peter Clausen 05 Jan '15

05 Jan '15

DAPM widgets are enabled by default, there is no need to enable them unless they have previously been explicitly disabled. Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- sound/soc/intel/broadwell.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/sound/soc/intel/broadwell.c b/sound/soc/intel/broadwell.c index 7cf95d5..9cf7d01 100644 --- a/sound/soc/intel/broadwell.c +++ b/sound/soc/intel/broadwell.c @@ -140,8 +140,6 @@ static struct snd_soc_ops broadwell_rt286_ops = { static int broadwell_rtd_init(struct snd_soc_pcm_runtime *rtd) { - struct snd_soc_codec *codec = rtd->codec; - struct snd_soc_dapm_context *dapm = &codec->dapm; struct sst_pdata *pdata = dev_get_platdata(rtd->platform->dev); struct sst_hsw *broadwell = pdata->dsp; int ret; @@ -155,14 +153,6 @@ static int broadwell_rtd_init(struct snd_soc_pcm_runtime *rtd) return ret; } - /* always connected - check HP for jack detect */ - snd_soc_dapm_enable_pin(dapm, "Headphone Jack"); - snd_soc_dapm_enable_pin(dapm, "Speaker"); - snd_soc_dapm_enable_pin(dapm, "Mic Jack"); - snd_soc_dapm_enable_pin(dapm, "Line Jack"); - snd_soc_dapm_enable_pin(dapm, "DMIC1"); - snd_soc_dapm_enable_pin(dapm, "DMIC2"); - return 0; } -- 1.8.0

2 1

[alsa-devel] [PATCH] ASoC: ts3a227e: Check and report jack status at probe
by Cheng-Yi Chiang 05 Jan '15

05 Jan '15

ts3a227e does not trigger interrupt to report jack status when system boots from warm reset because ts3a227e's power remains on during warm reset. Read jack status at probe to get current jack status. Note that if system boots from EC reset, then this issue will not happen. Signed-off-by: Cheng-Yi Chiang <cychiang(a)chromium.org> --- sound/soc/codecs/ts3a227e.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/sound/soc/codecs/ts3a227e.c b/sound/soc/codecs/ts3a227e.c index 1d12057..9f2dced 100644 --- a/sound/soc/codecs/ts3a227e.c +++ b/sound/soc/codecs/ts3a227e.c @@ -254,6 +254,7 @@ static int ts3a227e_i2c_probe(struct i2c_client *i2c, struct ts3a227e *ts3a227e; struct device *dev = &i2c->dev; int ret; + unsigned int acc_reg; ts3a227e = devm_kzalloc(&i2c->dev, sizeof(*ts3a227e), GFP_KERNEL); if (ts3a227e == NULL) @@ -283,6 +284,11 @@ static int ts3a227e_i2c_probe(struct i2c_client *i2c, INTB_DISABLE | ADC_COMPLETE_INT_DISABLE, ADC_COMPLETE_INT_DISABLE); + /* Read jack status because chip might not trigger interrupt at boot. */ + regmap_read(ts3a227e->regmap, TS3A227E_REG_ACCESSORY_STATUS, &acc_reg); + ts3a227e_new_jack_state(ts3a227e, acc_reg); + ts3a227e_jack_report(ts3a227e); + return 0; } -- 2.1.2

2 1