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

Re: [alsa-devel] [pulseaudio-discuss] Strange hardware: XFX nForce 780i SLI MCP
by Raymond Yau 02 Aug '15

02 Aug '15

> > Yesterday I got an interesting email related to dcaenc support. > > The person has an "XFX nForce 780i SLI" MCP board: http://www.nvidia.com/object/product_nforce_780i_sli_us.html , http://www.evga.com/support/manuals/files/132-CK-NF78.pdf > > As you see on page 18 of the manual, this board has no HDMI output, but there is an optical SPDIF. Strangely enough, this SPDIF is his "hdmi:CARD=NVidia,DEV=0" device. > > Given the recent discussions related to dynamically creating PCM devices for HDMI, I think you will be interested in this alsa-info output. > > Is there anything here that would need special treatment by ALSA or PulseAudio? Or, is this just a misnumbered/misnamed codec? > This can also be regarded as bug of hda_auto_parser.c which does not determine type of digital pin correctly Those internal spdif connector which can connect to an optional spdif headser or spdif input header of the graphic card for hdmi audio output http://www.intel.com/support/motherboards/desktop/sb/CS-032871.htm But the pincap of these kind of digital pin usually does not support DETECT nor HDMI

1 0

[alsa-devel] [PATCH 0/6] ASoC: Intel: Skylake: Add DSP management routines
by Vinod Koul 01 Aug '15

01 Aug '15

This series adds NHLT table support in the driver. This also adds support for dsp init, modules configuration and messaging support Hardik T Shah (1): ASoC: Intel: Skylake: Add helpers for SRC and converter modules Jeeja KP (5): ASoC: Intel: Skylake: Add NHLT support to get BE config ASoC: Intel: Skylake: Add dsp and ipc init helpers ASoC: Intel: Skylake: Add functions for DSP module configuration ASoC: Intel: Skylake: Add DSP module init and binding routines ASoC: Intel: Skylake: Add pipe management helpers sound/soc/intel/skylake/Makefile | 2 +- sound/soc/intel/skylake/skl-messages.c | 828 +++++++++++++++++++++++++++ sound/soc/intel/skylake/skl-nhlt.c | 141 +++++ sound/soc/intel/skylake/skl-nhlt.h | 116 ++++ sound/soc/intel/skylake/skl-topology.h | 276 +++++++++ sound/soc/intel/skylake/skl-tplg-interface.h | 88 +++ sound/soc/intel/skylake/skl.h | 13 + 7 files changed, 1463 insertions(+), 1 deletion(-) create mode 100644 sound/soc/intel/skylake/skl-messages.c create mode 100644 sound/soc/intel/skylake/skl-nhlt.c create mode 100644 sound/soc/intel/skylake/skl-nhlt.h create mode 100644 sound/soc/intel/skylake/skl-topology.h create mode 100644 sound/soc/intel/skylake/skl-tplg-interface.h -- 1.9.1

2 18

[alsa-devel] [PATCH 00/27] Export I2C and OF module aliases in missing drivers
by Javier Martinez Canillas 01 Aug '15

01 Aug '15

Hello, Short version: This series add the missing MODULE_DEVICE_TABLE() for OF and I2C tables to export that information so modules have the correct aliases built-in and autoloading works correctly. Longer version: Currently it's mandatory for I2C drivers to have an I2C device ID table regardless if the device was registered using platform data or OF. This is because the I2C core needs an I2C device ID table for two reasons: 1) Match the I2C client with a I2C device ID so a struct i2c_device_id is passed to the I2C driver probe() function. 2) Export the module aliases from the I2C device ID table so userspace can auto-load the correct module. This is because i2c_device_uevent always reports a MODALIAS of the form i2c:<client->name>. Lee Jones posted a patch series [0] to solve 1) by allowing the I2C drivers to have a probe() function that does not get a i2c_device_id. The problem is that his series didn't take into account 2) so if that was merged and the I2C ID table is removed from all the drivers that don't needed it, module auto-loading will break for those. But even now there are many I2C drivers were module auto-loading is not working because of the fact that the I2C core always reports the MODALIAS as i2c:<client->name> and many developers didn't expect this. I've identified I2C drivers with 3 types of different issues: a) Those that have an i2c_table but are not exported. The match works and the correct i2c_device_id is passed on probe but since the ID table is not exported, module auto-load won't work. b) Those that have a of_table but are not exported. This is currently not an issue since even when the of_table is used to match the dev with the driver, an OF modalias is not reported by the I2C core. But if the I2C core is changed to report the MODALIAS of the form of:N*T*C as it's made by other subsystems, then module auto-load will break for these drivers. c) Those that don't have a of_table but should since are OF drivers with DT bindings doc for them. Since the I2C core does not report a OF modalias and since i2c_device_match() fallbacks to match the device part of the compatible string with the I2C device ID table, many OF drivers don't have an of_table to match. After all having a I2C device ID table is mandatory so it works without a of_table. So, in order to not make mandatory to have a I2C device ID table, at least a) and b) needs to be addressed, this series does that. c) should be fixed too since it seems wrong that a driver with a DT binding document, does not have a OF table and export it to modules. Also stripping the vendor part from the compatible string to match with the I2C devices ID table and reporting only the device name to user-space doesn't seem to be correct. I've identified at least two drivers that have the same name on their I2C device ID table so the manufacturer prefix is important. But I've not tried to fix c) yet since that is not so easy to automate due drivers not having all the information (i.e: the device name can match a documented compatible string device part but without the vendor prefix is hard to tell). I split the changes so the patches in this series are independent and can be picked individually by subsystem maintainers. Patch #27 changes the logic of i2c_device_uevent() to report an OF modalias if the device was registered using OF. But this patch is included in the series only as an RFC for illustration purposes since changing that without fixing c) will break module auto-loading for the drivers of devices registered with OF but that don't have a of_match_table. Although arguably, those drivers were relying on the assumption that a MODALIAS=i2c:<foo> would always be reported even for the OF case which is not the true on other subsystems. [0]: https://lkml.org/lkml/2014/8/28/283 Best regards, Javier Javier Martinez Canillas (27): mfd: stw481x: Export I2C module alias information spi: xcomm: Export I2C module alias information iio: Export I2C module alias information in missing drivers [media] Export I2C module alias information in missing drivers macintosh: therm_windtunnel: Export I2C module alias information misc: eeprom: Export I2C module alias information in missing drivers Input: Export I2C module alias information in missing drivers power: Export I2C module alias information in missing drivers i2c: core: Export I2C module alias information in dummy driver backlight: tosa: Export I2C module alias information [media] staging: media: lirc: Export I2C module alias information usb: phy: isp1301: Export I2C module alias information ALSA: ppc: keywest: Export I2C module alias information hwmon: (nct7904) Export I2C module alias information regulator: fan53555: Export I2C module alias information mfd: Export OF module alias information in missing drivers iio: Export OF module alias information in missing drivers hwmon: (g762) Export OF module alias information extcon: Export OF module alias information in missing drivers ASoC: Export OF module alias information in missing codec drivers rtc: Export OF module alias information in missing drivers macintosh: therm_windtunnel: Export OF module alias information leds: Export OF module alias information in missing drivers [media] smiapp: Export OF module alias information Input: touchscreen - Export OF module alias information regulator: isl9305: Export OF module alias information i2c: (RFC, don't apply) report OF style modalias when probing using DT drivers/extcon/extcon-rt8973a.c | 1 + drivers/extcon/extcon-sm5502.c | 1 + drivers/hwmon/g762.c | 1 + drivers/hwmon/nct7904.c | 1 + drivers/i2c/i2c-core.c | 9 +++++++++ drivers/iio/accel/mma8452.c | 1 + drivers/iio/accel/stk8312.c | 1 + drivers/iio/accel/stk8ba50.c | 1 + drivers/iio/light/cm32181.c | 1 + drivers/iio/light/cm3232.c | 1 + drivers/iio/light/cm36651.c | 1 + drivers/iio/light/gp2ap020a00f.c | 1 + drivers/iio/light/stk3310.c | 1 + drivers/input/misc/gp2ap002a00f.c | 1 + drivers/input/touchscreen/egalax_ts.c | 1 + drivers/input/touchscreen/goodix.c | 1 + drivers/input/touchscreen/mms114.c | 1 + drivers/leds/leds-pca963x.c | 1 + drivers/leds/leds-tca6507.c | 1 + drivers/macintosh/therm_windtunnel.c | 2 ++ drivers/media/i2c/ir-kbd-i2c.c | 1 + drivers/media/i2c/s5k6a3.c | 1 + drivers/media/i2c/smiapp/smiapp-core.c | 1 + drivers/mfd/rt5033.c | 1 + drivers/mfd/stw481x.c | 1 + drivers/mfd/tps65217.c | 1 + drivers/mfd/tps65218.c | 1 + drivers/misc/eeprom/eeprom.c | 1 + drivers/misc/eeprom/max6875.c | 1 + drivers/power/bq24190_charger.c | 1 + drivers/power/rt5033_battery.c | 2 +- drivers/regulator/fan53555.c | 1 + drivers/regulator/isl9305.c | 1 + drivers/rtc/rtc-ab-b5ze-s3.c | 1 + drivers/rtc/rtc-isl12022.c | 1 + drivers/rtc/rtc-isl12057.c | 1 + drivers/spi/spi-xcomm.c | 1 + drivers/staging/media/lirc/lirc_zilog.c | 1 + drivers/usb/phy/phy-isp1301.c | 1 + drivers/video/backlight/tosa_bl.c | 1 + sound/ppc/keywest.c | 1 + sound/soc/codecs/da9055.c | 1 + sound/soc/codecs/wm8510.c | 1 + sound/soc/codecs/wm8523.c | 1 + sound/soc/codecs/wm8580.c | 1 + 45 files changed, 54 insertions(+), 1 deletion(-) -- 2.4.3

3 7

Re: [alsa-devel] Abouut adv7511 driver
by Lars-Peter Clausen 01 Aug '15

01 Aug '15

Cc: alsa-ml On 07/31/2015 07:38 AM, Kuninori Morimoto wrote: > > Hi Lars > Cc Mark > > I noticed Analog Devices has adv7511 support on > http://wiki.analog.com/resources/tools-software/linux-drivers/drm/adv7511 > > And I tried this driver on my board, and it works. > > if my understanding was correct, latest linux kernel doesn't have > adv7511 "sound" support yet. > Thus, I would like to have it on linux kernel. > According to this driver/file, it is under GPL-2, so it is no problem > from license point of view. > > According to git log Signd-off-by, Lars/Mark are listed on this adv7511 sound driver. > but I wonder why it is not on upstream ? Are there some reason ?? > If you don't mind, I would like to send it to ML. > This is OK ? The reason why the driver is not upstream at the moment is that the way it implements things is definitely not the right way. But there is still a lot of discussion on what actually is the right way to implement audio support for HDMI devices. Once that has been sorted out the driver will hopefully go upstream. - Lars -- To unsubscribe from this list: send the line "unsubscribe alsa-devel" in

4 3

[alsa-devel] AudioFire4 quirk
by Johannes Oertel 01 Aug '15

01 Aug '15

Hi, when I try to use the snd-fireworks driver with my AudioFire4 (see the output of /proc/asound/cardX/firewire/firmware below) on my machine (kernel 4.1), it doesn't work. I am experiencing exactly the same problems as Harry with his AudioFire2 [1]; dmesg was reporting discontinuities. A few days ago, I saw Takashi Sakamoto's most recent patch for making the AudioFire2 work in this case [2]. I adapted his patch (see below) to apply to my situation with the AudioFire4 and now it is working flawlessly! However, according to the README in Takashi's GitHub repository [3], he is testing the driver with an AudioFire4 as well, so I asked him why I need this patch and he does not. He told me he is using firmware version 5.5 while I'm on 5.7.3. He said he is going to test his device with different firmware versions soon and write a patch, if needed. Finally, he asked me to post this whole issue to this list as well and that's what I have just done. :) Best regards, Johannes [1] http://mailman.alsa-project.org/pipermail/alsa-devel/2014-August/080379.html [2] http://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/?id=9c68… [3] https://github.com/takaswie/snd-firewire-improve /proc/asound/cardX/firewire/firmware: guid_hi: 0x148604 guid_lo: 0x5BA8D7BF type: 0xAF4 version: 0x0 vendor_name: Echo Digital Audio model_name: AudioFire4 dsp_version: 0x0 arm_version: 0x5070300 fpga_version: 0x3000200 flags: 0xE1 max_sample_rate: 0x17700 min_sample_rate: 0x7D00 supported_clock: 0x9 phys out: 0x6 phys in: 0x6 phys in grps: 0x2 phys in grp[0]: type 0x0, count 0x4 phys in grp[1]: type 0x1, count 0x2 phys out grps: 0x2 phys out grps[0]: type 0x0, count 0x4 phys out grps[1]: type 0x1, count 0x2 amdtp rx pcm channels 1x: 0x6 amdtp tx pcm channels 1x: 0x6 amdtp rx pcm channels 2x: 0x6 amdtp tx pcm channels 2x: 0x6 amdtp rx pcm channels 4x: 0x6 amdtp tx pcm channels 4x: 0x6 midi out ports: 0x1 midi in ports: 0x1 mixer playback channels: 0x6 mixer capture channels: 0x6 The patch: --- sound/firewire/fireworks/fireworks.c | 2 ++ sound/firewire/fireworks/fireworks.h | 1 + sound/firewire/fireworks/fireworks_stream.c | 4 ++-- 3 files changed, 5 insertions(+), 2 deletions(-) diff --git a/sound/firewire/fireworks/fireworks.c b/sound/firewire/fireworks/fireworks.c index c670db4..544bdbf 100644 --- a/sound/firewire/fireworks/fireworks.c +++ b/sound/firewire/fireworks/fireworks.c @@ -250,6 +250,8 @@ efw_probe(struct fw_unit *unit, goto error; if (entry->model_id == MODEL_ECHO_AUDIOFIRE_2) efw->is_af2 = true; + if (entry->model_id == MODEL_ECHO_AUDIOFIRE_4) + efw->is_af4 = true; if (entry->model_id == MODEL_ECHO_AUDIOFIRE_9) efw->is_af9 = true; diff --git a/sound/firewire/fireworks/fireworks.h b/sound/firewire/fireworks/fireworks.h index 9493122..9a7dcbb 100644 --- a/sound/firewire/fireworks/fireworks.h +++ b/sound/firewire/fireworks/fireworks.h @@ -74,6 +74,7 @@ struct snd_efw { /* for quirks */ bool is_af2; + bool is_af4; bool is_af9; u32 firmware_version; diff --git a/sound/firewire/fireworks/fireworks_stream.c b/sound/firewire/fireworks/fireworks_stream.c index a0762dd..182b96f 100644 --- a/sound/firewire/fireworks/fireworks_stream.c +++ b/sound/firewire/fireworks/fireworks_stream.c @@ -172,8 +172,8 @@ int snd_efw_stream_init_duplex(struct snd_efw *efw) efw->tx_stream.flags |= CIP_DBC_IS_END_EVENT; /* Fireworks reset dbc at bus reset. */ efw->tx_stream.flags |= CIP_SKIP_DBC_ZERO_CHECK; - /* AudioFire2 starts packets with non-zero dbc. */ - if (efw->is_af2) + /* AudioFire2 and AudioFire4 start packets with non-zero dbc. */ + if (efw->is_af2 || efw->is_af4) efw->tx_stream.flags |= CIP_SKIP_INIT_DBC_CHECK; /* AudioFire9 always reports wrong dbs. */ if (efw->is_af9) -- 2.4.6

2 1

[alsa-devel] Laptop internal speaker volume is apparently controlled by the headphone control (Intel HDA Panther Point)
by Dang Sananikone 01 Aug '15

01 Aug '15

Hi, I've just noticed that the internal speaker volume on my laptop is now controlled by the headphone control in alsamixer. I think this may be a recent change although I can't be sure. I'm using Arch Linux with kernel 4.1.3-1. I've uploaded the alsa info here: http://www.alsa-project.org/db/?f=f04e506dad863823b18f8f9e9d0261fdacd72695 Let me know if I can help. Kind Regards, Dang.

2 1