Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 12 12月, 2014 1 次提交
  3. 08 12月, 2014 2 次提交
    • M
      ASoC: wm5102: Initialize dac_comp_lock mutex · 47370022
      由 Mark Brown 提交于 
      Commit d74bcaae (ASoC: wm5102: Move ultrasonic response settings
lock to the driver level) created a driver local mutex for protecting
the ultrasonic response settings but neglected to initialize that mutex,
causing loud complaints from lockep and potential runtime failures. Fix
this by initializing the mutex.
Signed-off-by: NMark Brown <broonie@kernel.org>
Acked-by: NCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      47370022
    • M
      ASoC: samsung: Fix non-DT use of I2S controller · 3f024980
      由 Mark Brown 提交于 
      The changes in commit a5a56871 (ASoC: samsung: add support for exynos7
I2S controller) introduce a new variant_regs structure in the driver data
which is now mandatory for accessing registers. Unfortunately this is only
hooked up for DT platforms so non-DT platforms like my primary development
platform for audio are broken by this change and crash on boot.

Since the only non-DT user of these device is s3c64xx fix this by making
the standard samsung-i2s device be of type I2Sv3 and add a new I2Sv4 name
to the platform data section, currently using the I2Sv5 information which
should be about right.
Signed-off-by: NMark Brown <broonie@kernel.org>
      3f024980
  5. 07 12月, 2014 2 次提交
  7. 06 12月, 2014 1 次提交
  9. 05 12月, 2014 5 次提交
    • D
      ASoC: rt5677: make volume TLV closer to reality · 40e3262e
      由 Dylan Reid 提交于 
      The volume blocks have an step of 0.375dB, but TLV uses 0.01dB for
units.  Only use the resolution supported, ignoring the LSB of the
volume register.  This results in half the steps and 0.75dB per step,
but reports accurate levels through TLV.  Update the masks to reflect
that these are registers have the LSB ignored.
Signed-off-by: NDylan Reid <dgreid@chromium.org>
Signed-off-by: NMark Brown <broonie@kernel.org>
      40e3262e
    • J
      ASoC: fsl_ssi: fix error path in probe · 4c9a8845
      由 Jiada Wang 提交于 
      SSI component isn't unregistered if fsl_ssi_debugfs_create() fails
in probe phase.

To fix it, this commit replaces label error_asoc_register with
error_irq.
Signed-off-by: NJiada Wang <jiada_wang@mentor.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      4c9a8845
    • F
      ASoC: fsl_ssi: Fix module unbound · 2ffa5310
      由 Fabio Estevam 提交于 
      Trying to remove the snd-soc-fsl-ssi module leads to the following warning:

[   31.515336] ------------[ cut here ]------------
[   31.520091] WARNING: CPU: 2 PID: 434 at fs/proc/generic.c:521 remove_proc_entry+0x14c/0x16c()
[   31.528708] remove_proc_entry: removing non-empty directory 'irq/79', leaking at least '202c000.ss'
[   31.537911] Modules linked in: snd_soc_wm8962 snd_soc_imx_wm8962 snd_soc_fsl_ssi(-) evbug
[   31.546249] CPU: 2 PID: 434 Comm: rmmod Not tainted 3.18.0-rc6-00028-g3314bf6b-dirty #1
[   31.554235] Backtrace:
[   31.556816] [<80011ea8>] (dump_backtrace) from [<80012044>] (show_stack+0x18/0x1c)
[   31.564416]  r6:80142c88 r5:00000000 r4:00000000 r3:00000000
[   31.570267] [<8001202c>] (show_stack) from [<806980ec>] (dump_stack+0x88/0xa4)
[   31.577588] [<80698064>] (dump_stack) from [<80029d78>] (warn_slowpath_common+0x70/0x94)
[   31.585711]  r5:00000009 r4:bb61fd90
[   31.589423] [<80029d08>] (warn_slowpath_common) from [<80029e40>] (warn_slowpath_fmt+0x38/0x40)
[   31.598187]  r8:bb61fdfe r7:be05d76d r6:be05d9a8 r5:00000002 r4:be05d700
[   31.605054] [<80029e0c>] (warn_slowpath_fmt) from [<80142c88>] (remove_proc_entry+0x14c/0x16c)
[   31.613709]  r3:806a79c0 r2:808229a0
[   31.617371] [<80142b3c>] (remove_proc_entry) from [<80070380>] (unregister_irq_proc+0x94/0xb8)
[   31.625989]  r10:00000000 r8:8000ede4 r7:80955f2c r6:0000004f r5:8118e738 r4:be00af00
[   31.633952] [<800702ec>] (unregister_irq_proc) from [<80069dac>] (free_desc+0x2c/0x64)
[   31.641898]  r6:0000004f r5:80955f38 r4:be00af00
[   31.646604] [<80069d80>] (free_desc) from [<80069e68>] (irq_free_descs+0x4c/0x8c)
[   31.654092]  r7:00000081 r6:00000001 r5:0000004f r4:00000001
[   31.659863] [<80069e1c>] (irq_free_descs) from [<8006fc3c>] (irq_dispose_mapping+0x40/0x5c)
[   31.668247]  r6:be17b844 r5:be17b800 r4:0000004f r3:802c5ec0
[   31.673998] [<8006fbfc>] (irq_dispose_mapping) from [<7f004ea4>] (fsl_ssi_remove+0x58/0x70 [snd_so)
[   31.683948]  r4:bb5bba10 r3:00000001
[   31.687618] [<7f004e4c>] (fsl_ssi_remove [snd_soc_fsl_ssi]) from [<803720a0>] (platform_drv_remove)
[   31.697564]  r5:7f0064f8 r4:be17b810
[   31.701195] [<80372080>] (platform_drv_remove) from [<80370494>] (__device_release_driver+0x78/0xc)
[   31.710361]  r5:7f0064f8 r4:be17b810
[   31.713987] [<8037041c>] (__device_release_driver) from [<80370d20>] (driver_detach+0xbc/0xc0)
[   31.722631]  r5:7f0064f8 r4:be17b810
[   31.726259] [<80370c64>] (driver_detach) from [<80370304>] (bus_remove_driver+0x54/0x98)
[   31.734382]  r6:00000800 r5:00000000 r4:7f0064f8 r3:bb67f500
[   31.740149] [<803702b0>] (bus_remove_driver) from [<80371398>] (driver_unregister+0x30/0x50)
[   31.748617]  r4:7f0064f8 r3:bd9f7080
[   31.752245] [<80371368>] (driver_unregister) from [<80371f3c>] (platform_driver_unregister+0x14/0x)
[   31.761498]  r4:7f00655c r3:7f005a70
[   31.765130] [<80371f28>] (platform_driver_unregister) from [<7f005a84>] (fsl_ssi_driver_exit+0x14/)
[   31.776147] [<7f005a70>] (fsl_ssi_driver_exit [snd_soc_fsl_ssi]) from [<8008ed80>] (SyS_delete_mod)
[   31.786553] [<8008ec64>] (SyS_delete_module) from [<8000ec20>] (ret_fast_syscall+0x0/0x48)
[   31.794824]  r6:00c46d18 r5:00000800 r4:00c46d18
[   31.799530] ---[ end trace 954e8a3a15379e52 ]---

The cause of problem and solution are well explained by Lars-Peter:

"The driver creates the mapping by calling irq_of_parse_and_map(), so it also
has to dispose the mapping. But the easy way out is to simply use
platform_get_irq() instead of irq_of_parse_map(). In this case the mapping is
not managed by the device but by the of core, so the device has not to dispose
the mapping."

Tested on a imx6q-sabresd board.
Reported-by: NJiada Wang <jiada_wang@mentor.com>
Suggested-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      2ffa5310
    • Q
      ASoC: soc-pcm: do not hw_free BE if it's still used · 36fba62c
      由 Qiao Zhou 提交于 
      Do not free BE hw if it's still used by other FE during dpcm runtime
shutdown. Otherwise the BE runtime state will be STATE_HW_FREE and
won't be updated to STATE_CLOSE when shutdown ends, because BE dai
shutdown function won't close pcm when detecting BE is still under
use. With STATE_HW_FREE, BE can't be triggered start again.

This corner case can easily appear when one BE is used by two FE,
without this patch "ASoC: dpcm: Fix race between FE/BE updates and
trigger"(ea9d0d77). One FE tries to
shutdown but it's raced against xrun on another FE. It improves the
be dai hw_free logic.
Signed-off-by: NQiao Zhou <zhouqiao@marvell.com>
Acked-by: NLiam Girdwood <liam.r.girdwood@linux.intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      36fba62c
    • P
      ASoC: Augment existing card DAPM routes in snd_soc_of_parse_audio_routing · f8781db8
      由 Peter Rosin 提交于 
      If a snd_soc_card has any DAPM routes when it calls
snd_soc_of_parse_audio_routing, those are clobbered without this change.
Signed-off-by: NPeter Rosin <peda@axentia.se>
Signed-off-by: NMark Brown <broonie@kernel.org>
      f8781db8
  11. 04 12月, 2014 19 次提交
  13. 02 12月, 2014 2 次提交
  15. 28 11月, 2014 5 次提交
    • J
      ASoC: Intel: Move capture PCM pin to PCM0 for Broadwell/Haswell · 7bb73cbd
      由 Jie Yang 提交于 
      Move capture PCM pin from PCM4 to PCM0 for Broadwell/Haswell.
This will allow us to integrate with pulseaudio better for
usually default device is set to 0.
Signed-off-by: NJie Yang <yang.jie@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      7bb73cbd
    • J
      ASoC: Intel: Correct the xmax volume · c5f0406b
      由 Jie Yang 提交于 
      The xmax volume should be corrected to ARRAY_SIZE(volume_map)-1, otherwise,
the xmax value will be mapped to 0 wrongly.
Signed-off-by: NJie Yang <yang.jie@intel.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      c5f0406b
    • F
      ASoC: mxs-sgtl5000: Remove MCLK restriction · d206f661
      由 Fabio Estevam 提交于 
      According to the sgtl5000 datasheet the MCLK frequency range restriction of
8 to 27 MHz only applies when the PLL is used - synchronous SYS_MCLK input mode.

mxs-sgtl5000 machine sets the codec as slave, and mx28 generates MCLK in the
range of 256*fs, 384*fs or 512*fs, which is called asynchronous SYS_MCLK
input.

In asynchronous SYS_MCLK we cannot have the 8 to 27 MHz check because if we
want to play a 8KHz sample rate track, with a MCLK of 8k * 512 = 4.096MHz the
current check would return -EINVAL, which is not correct.

Remove the 8 to 27MHz frequency check, since this only applies to the
synchronous SYS_MCLK input case.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      d206f661
    • F
      ASoC: sgtl5000: Allow 8kHz playback in codec slave mode · 2a4cfd10
      由 Fabio Estevam 提交于 
      When trying to play a 8kHz file with codec in slave mode we get the following
error on a mx28evk:

$ aplay -Dhw:0,0 stereo_8k.wav
Playing WAVE 'stereo_8k.wav' : Signed 16 bit Little Endian, Rate 8000 Hz, Stereo
[   21.218647] sgtl5000 0-000a: PLL not supported in slave mode
[   21.224559] sgtl5000 0-000a: 128 ratio is not supported. SYS_MCLK needs to be 256, 384 or 512 * fs
[   21.233687] sgtl5000 0-000a: ASoC: can't set sgtl5000 hw params: -22
aplay: set_params:1123: Unable to install hw params:

This error happens because we are using 'sys_fs' instead of 'frame_rate' in the
valid ratio check.

Use the real'frame_rate' so that the ratio is correctly calculated and the
playback can run.

sgtl5000 codec manual states that in 'Synchronous SYS_MCLK input' mode that the
following SYS_CLK frequencies are allowed: 256*fs, 384*fs, 512*fs.

, where fs is the sampling frequency, which can be in the range of:
8, 11.025, 16, 22.5, 32, 44.1, 48, 96 kHz.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      2a4cfd10
    • F
      ASoC: sgtl5000: Remove MCLK restriction · d819ce96
      由 Fabio Estevam 提交于 
      According to the sgtl5000 datasheet the MCLK frequency range restriction of
8 to 27 MHz only applies when the PLL is used - synchronous SYS_MCLK input mode.

When running the codec as slave, the master should generate MCLK in the range of
256*fs, 384*fs or 512*fs, which is called asynchronous SYS_MCLK input mode.

In asynchronous SYS_MCLK we cannot have the 8 to 27 MHz check because if we
want to play a 8KHz sample rate track, with a MCLK of 8k * 512 = 4.096MHz the
current check would return -EINVAL, which is not correct.

Remove the 8 to 27MHz frequency check, since this only applies to the
synchronous SYS_MCLK input case.
Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: NMark Brown <broonie@kernel.org>
      d819ce96
  17. 27 11月, 2014 3 次提交