September 2011 - Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] [PATCH v5] drm/i915: pass ELD to HDMI/DP audio driver
by Wu Fengguang 05 Sep '11

05 Sep '11

On Sun, Sep 04, 2011 at 08:08:37PM +0800, Chris Wilson wrote: > On Sun, 4 Sep 2011 05:15:10 +0800, Wu Fengguang <fengguang.wu(a)intel.com> wrote: > > Changes from v4: remove a debug call to dump_stack(). > > Thanks to Bossart for catching this! > > --- > > > > Add ELD support for Intel Eaglelake, IbexPeak/Ironlake, > > SandyBridge/CougarPoint and IvyBridge/PantherPoint chips. > > > > ELD (EDID-Like Data) describes to the HDMI/DP audio driver the audio > > capabilities of the plugged monitor. It's built and passed to audio > > driver in 2 steps: > > > > (1) at get_modes time, parse EDID and save ELD to drm_connector.eld[] > > > > (2) at mode_set time, write drm_connector.eld[] to the Transcoder's hw > > ELD buffer and set the ELD_valid bit to inform HDMI/DP audio driver > > > > ELD selection policy: it's possible for one encoder to be associated > > with multiple connectors (ie. monitors), in which case the first found > > ELD will be used. This policy may not be suitable for all users, but > > let's start it simple first. > > > > The impact of ELD selection policy: assume there are two monitors, one > > supports stereo playback and the other has 8-channel output; cloned > > display mode is used, so that the two monitors are associated with the > > same internal encoder. If only the stereo playback capability is reported, > > the user won't be able to start 8-channel playback; if the 8-channel ELD > > is reported, then user space applications may send 8-channel samples > > down, however the user may actually be listening to the 2-channel > > monitor and not connecting speakers to the 8-channel monitor. Overall, > > it's more safe to report maximum profiles to the user space, so that > > the user can at least be able to do 8-channel playback if he want to. > > > > This patch is tested OK on G45/HDMI, IbexPeak/HDMI and IvyBridge/HDMI+DP. > > > > Minor imperfection: the GEN6_AUD_CNTL_ST/DIP_Port_Select field always > > reads 0 (reserved). Without knowing the port number, I worked it around > > by setting the ELD_valid bit for ALL the three ports. It's tested to not > > be a problem, because the audio driver will find invalid ELD data and > > hence rightfully abort, even when it sees the ELD_valid indicator. > > > > > --- linux-next.orig/drivers/gpu/drm/i915/intel_display.c 2011-09-02 15:59:31.000000000 +0800 > > +++ linux-next/drivers/gpu/drm/i915/intel_display.c 2011-09-04 05:11:44.000000000 +0800 > > +static void ironlake_write_eld(struct drm_connector *connector, > > + struct drm_crtc *crtc) > > +{ > > + struct drm_i915_private *dev_priv = connector->dev->dev_private; > > + uint8_t *eld = connector->eld; > > + uint32_t eldv; > > + uint32_t i; > > + int len; > > + int hdmiw_hdmiedid; > > + int aud_cntl_st; > > + int aud_cntrl_st2; > > + > > + if (IS_IVYBRIDGE(connector->dev)) { > > + hdmiw_hdmiedid = GEN7_HDMIW_HDMIEDID_A; > > + aud_cntl_st = GEN7_AUD_CNTRL_ST_A; > > + aud_cntrl_st2 = GEN7_AUD_CNTRL_ST2; > > + } else { > > + hdmiw_hdmiedid = GEN6_HDMIW_HDMIEDID_A; > > + aud_cntl_st = GEN6_AUD_CNTL_ST_A; > > + aud_cntrl_st2 = GEN6_AUD_CNTL_ST2; > > + } > > This register naming is inconsistent with its intent. If these registers > were indeed introduced on Ironlake as you seem to imply by using them > with Ironlake, you should label them as GEN5 and not GEN6. Yeah, I admit that I'm a bit confused in choosing the exact names. I'll fix that. > This patch should be split between adding the core drm functionality to > build the ELD and the introduction of i915 support. OK. I didn't do this because I was not sure if it's OK to just add the drm_*() functions without any code to call them.. Thanks, Fengguang

1 0

Re: [alsa-devel] [PATCH] ASoC: rt5631: first commit
by Mark Brown 04 Sep '11

04 Sep '11

On Thu, Sep 01, 2011 at 08:21:14PM +0800, johnnyhsu(a)realtek.com wrote: > Subject: [PATCH] ASoC: rt5631: first commit "Add driver for..." or something. > +static int rt5631_volatile_register(struct snd_soc_codec *codec, > + unsigned int reg) > +{ > + switch (reg) { > + case RT5631_VENDOR_ID: > + case RT5631_VENDOR_ID1: > + case RT5631_VENDOR_ID2: > + return 0; > + default: > + return 1; > + } > +} This looks to be exactly the wrong way round - the only registers we can cache are the ID registers. > +/* MIC Boost Volume */ > +static const char *rt5631_mic_boost[] = {"Bypass", "+20db", "+24db", "+30db", > + "+35db", "+40db", "+44db", "+50db", "+52db"}; TLV for volume information. > + rt5631->bclk_rate = snd_soc_params_to_bclk(params); > + if (rt5631->bclk_rate < 0) { > + dev_err(codec->dev, "Unsupported BCLK rate: %d\n", > + rt5631->bclk_rate); > + return rt5631->bclk_rate; > + } The error message here is inacurate, there was an error obtaining the BCLK rate rather than a problem supporting it. > +static int rt5631_codec_set_dai_pll(struct snd_soc_dai *codec_dai, int pll_id, > + int source, unsigned int freq_in, unsigned int freq_out) > +{ > + struct snd_soc_codec *codec = codec_dai->codec; > + struct rt5631_priv *rt5631 = snd_soc_codec_get_drvdata(codec); > + int i, ret = -EINVAL; > + > + dev_dbg(codec->dev, "enter %s\n", __func__); > + > + if (!freq_in || !freq_out) { > + dev_dbg(codec->dev, "PLL disabled\n"); > + return -EINVAL; > + } This shouldn't be an error condition, disabling the PLL is a perfectly normal thing to do. > + if (rt5631->master) { > + for (i = 0; i < ARRAY_SIZE(codec_master_pll_div); i++) > + if (freq_in == codec_master_pll_div[i].pll_in && Since the PLL configuration depends on the master/slave configuration you should either warn or reconfigure if the PLL is set up and the user changes master/slave configuration. > +/** > + * rt5631_index_reg_show - sysfs file for dumping index registers of 2nd layer > + */ > +static ssize_t rt5631_index_reg_show(struct device *dev, > + struct device_attribute *attr, char *buf) > +{ No, use the standard facilities. Please don't ignore review comments, it's not helpful.

1 0

Re: [alsa-devel] [PATCH] ASoC: sn95031: Fix the logic to find free channel
by Mark Brown 04 Sep '11

04 Sep '11

On Sat, Sep 03, 2011 at 01:41:47PM +0800, Axel Lin wrote: > In the case of no free channel available, > current implementation returns 0 instead of negative errno. > > This patch fixes the logic to return -EINVAL if no free channel available. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: codecs: Remove unused mutex
by Mark Brown 04 Sep '11

04 Sep '11

On Sun, Sep 04, 2011 at 10:48:09PM +0800, Axel Lin wrote: > 2011/9/4 Mark Brown <broonie(a)opensource.wolfsonmicro.com>: > > This has already been done for wm9090, can you resubmit with just the > > alc5623 change please? > Ok. A new patch "ASoC: alc5623: Remove unused mutex" is on the way. Thanks. The patch has been sitting there for a little while but it's not on kernel.org due to the lockdown after the compromise - until we can start pushing updates again there's a risk of overlaps like this.

1 0

[alsa-devel] [3.1-rc4] sound regression on Realtek ALC260
by Alessandro Guido 04 Sep '11

04 Sep '11

With 3.1-rc4 Skype makes very unpleasant noises when playing event sounds or voice. Sometimes a reboot may be able to fix it, but with with 3.0 it always worked fine. Some new warnings are shown in dmesg for 3.1-rc4 related to alsa: hda-intel: Invalid position buffer, using LPIB read method instead. hda-intel: Invalid position buffer, using LPIB read method instead. hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj. I'm attaching the output of alsa-info utility.

1 0

Re: [alsa-devel] [PATCH] ASoC: codecs: Remove unused mutex
by Mark Brown 04 Sep '11

04 Sep '11

On Sun, Sep 04, 2011 at 08:52:31PM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> > Cc: Arnaud Patard <arnaud.patard(a)rtp-net.org> > Cc: Mark Brown <broonie(a)opensource.wolfsonmicro.com> > --- > sound/soc/codecs/alc5623.c | 2 -- > sound/soc/codecs/wm9090.c | 2 -- This has already been done for wm9090, can you resubmit with just the alc5623 change please?

1 0

Re: [alsa-devel] [PATCH] ASoC: sn95031: Fix the logic to find free channel
by Girdwood, Liam 03 Sep '11

03 Sep '11

On 3 September 2011 06:41, Axel Lin <axel.lin(a)gmail.com> wrote: > In the case of no free channel available, > current implementation returns 0 instead of negative errno. > > This patch fixes the logic to return -EINVAL if no free channel available. > > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> > --- > sound/soc/codecs/sn95031.c | 8 +++----- > 1 files changed, 3 insertions(+), 5 deletions(-) > > diff --git a/sound/soc/codecs/sn95031.c b/sound/soc/codecs/sn95031.c > index 84ffdeb..b4f1cb4 100644 > --- a/sound/soc/codecs/sn95031.c > +++ b/sound/soc/codecs/sn95031.c > @@ -79,7 +79,7 @@ static void configure_adc(struct snd_soc_codec > *sn95031_codec, int val) > */ > static int find_free_channel(struct snd_soc_codec *sn95031_codec) > { > - int ret = 0, i, value; > + int i, value; > > /* check whether ADC is enabled */ > value = snd_soc_read(sn95031_codec, SN95031_ADC1CNTL1); > @@ -91,12 +91,10 @@ static int find_free_channel(struct snd_soc_codec > *sn95031_codec) > for (i = 0; i < SN95031_ADC_CHANLS_MAX; i++) { > value = snd_soc_read(sn95031_codec, > SN95031_ADC_CHNL_START_ADDR + i); > - if (value & SN95031_STOPBIT_MASK) { > - ret = i; > + if (value & SN95031_STOPBIT_MASK) > break; > - } > } > - return (ret > SN95031_ADC_LOOP_MAX) ? (-EINVAL) : ret; > + return (i == SN95031_ADC_CHANLS_MAX) ? (-EINVAL) : i; > } > > /* Initialize the ADC for reading micbias values. Can sleep. */ > -- > 1.7.4.1 > > > > Acked-by: Liam Girdwood <lrg(a)ti.com> Btw, this should be posted to alsa-devel.

2 1

[alsa-devel] Lost dB volumes on USB headset between 2.6.38 and 3.0
by David Henningsson 03 Sep '11

03 Sep '11

Hmm, I and Colin Guthrie have found a regression between kernels 2.6.38 and 3.0. When running "amixer -D hw:handset" for this device under 2.6.38, the attached file is returned. Under 3.0, the dB information is missing. This can't be intentional, can it? -- David Henningsson http://launchpad.net/~diwic

5 13

[alsa-devel] A debug version of the ALSA lib?
by Olivier Guillion - Myriad 02 Sep '11

02 Sep '11

Hi, I have a problem with the ALSA library. Calling snd_device_name_hint() crashes sometimes, and I can't understand why. It might be due to a previous memory corruption in my program, a problem with my sound card driver, or a bug in the library, I don't know. I tried to debug it in assembler, and found that the library is browsing a list of devices, gets the pointer to each device name, and in the 2nd device, I get the four letters "Play" instead of a valid pointer. To be able to go further, I'd need a debug version of the ALSA library, including variable names and source lines, which could let me find more easily what goes wrong and when. Is it possible to build such a library from the alsa-lib-1.0.24.1 sources? Or should I download and install another specific package? Thank you, Olivier

6 15

Re: [alsa-devel] Can ALSA invoke a Callback ?
by Clemens Ladisch 02 Sep '11

02 Sep '11

Ru Vuott wrote: > hData = OPEN "/dev/snd/midiC2D0" for READ Watch > > Do you think this solution could interfere and give problems to ALSA ? Yes; this opens the device exclusively. The ALSA sequencer would be able to allow multiple applications. > The rest of my program (for sending midi event, etcetera) continue to use ALSA. How are you using ALSA from Gambas? Is there some ALSA module that could be extended to ALSA watches? Regards, Clemens

1 0