1. 21 7月, 2017 1 次提交
  2. 14 6月, 2017 1 次提交
    • R
      ASoC: sgtl5000: add avc support · a7295267
      Richard Leitner 提交于
      The sgtl5000 features an automatic volume control block (AVC), which
      reduces loud signals and amplifies low level signals for easier
      listening. This patch adds support for this AVC block to the driver.
      
      Apart from the "AVC Switch" control which enables the block following
      controls for the configuration of AVC are added:
      	+ AVC Threshold Volume: threshold where audio is compressed when
      		the measured level is above or expanded when below
      	+ AVC Max Gain Volume: maximum gain which can be applied when
      		the measured audio level is below threshold
      	+ AVC Hard Limiter Switch: when enabled the signal is limited to
      		the programmed threshold.
      	+ AVC Integrator Response: response time of the integrator
      
      The AVC block is enabled and configured using the DAP_AVC_CTRL and
      DAP_AVC_THRESHOLD registers.
      
      Following 2 checkpatch.pl strict checks are ignored because the
      indentation style is different for the struct snd_kcontrol_new
      definition:
      	patch:147: CHECK: Alignment should match open parenthesis
      	patch:150: CHECK: Alignment should match open parenthesis
      Signed-off-by: NRichard Leitner <richard.leitner@skidata.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      a7295267
  3. 11 4月, 2017 1 次提交
  4. 02 9月, 2016 1 次提交
  5. 08 8月, 2016 1 次提交
  6. 12 7月, 2016 1 次提交
  7. 15 6月, 2016 6 次提交
  8. 17 12月, 2015 1 次提交
  9. 01 10月, 2015 1 次提交
  10. 30 9月, 2015 1 次提交
  11. 05 8月, 2015 1 次提交
  12. 15 7月, 2015 1 次提交
  13. 12 5月, 2015 1 次提交
  14. 28 4月, 2015 1 次提交
  15. 27 4月, 2015 2 次提交
  16. 07 3月, 2015 1 次提交
  17. 03 2月, 2015 1 次提交
  18. 30 1月, 2015 1 次提交
  19. 15 1月, 2015 1 次提交
  20. 28 11月, 2014 2 次提交
    • 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
  21. 14 11月, 2014 1 次提交
    • F
      ASoC: sgtl5000: Fix SMALL_POP bit definition · c251ea7b
      Fabio Estevam 提交于
      On a mx28evk with a sgtl5000 codec we notice a loud 'click' sound  to happen
      5 seconds after the end of a playback.
      
      The SMALL_POP bit should fix this, but its definition is incorrect:
      according to the sgtl5000 manual it is bit 0 of CHIP_REF_CTRL register, not
      bit 1.
      
      Fix the definition accordingly and enable the bit as intended per the code
      comment.
      
      After applying this change, no loud 'click' sound is heard after playback
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      c251ea7b
  22. 28 10月, 2014 1 次提交
  23. 20 10月, 2014 3 次提交
  24. 03 10月, 2014 2 次提交
  25. 06 9月, 2014 1 次提交
    • L
      ASoC: sgtl5000: Cleanup bias level transitions · e649057a
      Lars-Peter Clausen 提交于
      Set the CODEC driver's suspend_bias_off flag rather than manually going to
      SND_SOC_BIAS_OFF in suspend and SND_SOC_BIAS_STANDBY in resume. This makes
      the code a bit shorter and cleaner.
      
      Since the ASoC core now takes care of setting the bias level to
      SND_SOC_BIAS_OFF when removing the CODEC there is no need to do it manually
      anymore either.
      
      The manual transition to SND_SOC_BIAS_STANDBY at the end of CODEC probe()
      can also be removed as the core will automatically do this after the CODEC
      has been probed.
      Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
      Signed-off-by: NMark Brown <broonie@kernel.org>
      e649057a
  26. 31 7月, 2014 1 次提交
  27. 09 7月, 2014 1 次提交
    • F
      ASoC: sgtl5000: Fix driver unbound · e42be7e1
      Fabio Estevam 提交于
      Using the sgtl5000 codec driver as a module and trying to remove it causes the
      followig kernel oops:
      
      root@freescale /$ rmmod snd-soc-imx-sgtl5000
      [  117.122920] ------------[ cut here ]------------
      [  117.127609] WARNING: CPU: 0 PID: 631 at drivers/regulator/core.c:3604 regula)
      [  117.137046] Modules linked in: snd_soc_imx_sgtl5000(-) snd_soc_sgtl5000 evbug
      [  117.144315] CPU: 0 PID: 631 Comm: rmmod Not tainted 3.16.0-rc3-next-201407043
      [  117.153366] Backtrace:
      [  117.155865] [<80011e5c>] (dump_backtrace) from [<80011ff8>] (show_stack+0x18)
      [  117.163484]  r6:802fcc48 r5:00000000 r4:00000000 r3:00000000
      [  117.169228] [<80011fe0>] (show_stack) from [<80668cc0>] (dump_stack+0x88/0xa)
      [  117.176508] [<80668c38>] (dump_stack) from [<80029a38>] (warn_slowpath_commo)
      [  117.184696]  r5:00000009 r4:00000000
      [  117.188322] [<800299c8>] (warn_slowpath_common) from [<80029a80>] (warn_slow)
      [  117.197150]  r8:dd60d600 r7:ddfa6d00 r6:dd5d9064 r5:dd5e0f90 r4:dd5d9400
      [  117.203983] [<80029a5c>] (warn_slowpath_null) from [<802fcc48>] (regulator_u)
      [  117.212828] [<802fcb74>] (regulator_unregister) from [<7f0047c4>] (ldo_regul)
      [  117.223475]  r4:dd59e300 r3:dd5e0f90
      [  117.227100] [<7f00479c>] (ldo_regulator_remove [snd_soc_sgtl5000]) from [<7f)
      [  117.238959]  r4:dd5d8000 r3:ddd51420
      [  117.242623] [<7f0047dc>] (sgtl5000_remove [snd_soc_sgtl5000]) from [<804e5b1)
      [  117.252489]  r5:00000000 r4:dd5d8000
      [  117.256111] [<804e5af8>] (soc_remove_codec) from [<804e5ed4>] (soc_remove_da)
      [  117.264933]  r4:ddfb640c r3:00000000
      [  117.268555] [<804e5c10>] (soc_remove_dai_links) from [<804e5fbc>] (snd_soc_u)
      [  117.277810]  r10:80359e48 r9:dd684000 r8:dd5ca800 r7:dd685e60 r6:00000001 r5c
      [  117.285761]  r4:dd5d9064
      [  117.288329] [<804e5f28>] (snd_soc_unregister_card) from [<804f29f0>] (devm_c)
      [  117.297324]  r6:00000004 r5:ddd0fc10 r4:dd5a7980 r3:804f29dc
      [  117.303095] [<804f29dc>] (devm_card_release) from [<8035a418>] (release_node)
      [  117.311369] [<8035a2a8>] (release_nodes) from [<8035aab4>] (devres_release_a)
      [  117.319583]  r10:00000000 r9:dd684000 r8:8000ed64 r7:00000081 r6:ddd0fc44 r54
      [  117.327543]  r4:ddd0fc10
      [  117.330108] [<8035aa7c>] (devres_release_all) from [<803571c8>] (__device_re)
      [  117.339214]  r4:ddd0fc10 r3:dd5d9010
      [  117.342989] [<80357148>] (__device_release_driver) from [<80357a48>] (driver)
      [  117.351607]  r5:7f00c9e4 r4:ddd0fc10
      [  117.355285] [<8035798c>] (driver_detach) from [<80357030>] (bus_remove_drive)
      [  117.363454]  r6:00000880 r5:00000000 r4:7f00c9e4 r3:dd6c3a80
      [  117.369195] [<80356fdc>] (bus_remove_driver) from [<803580b8>] (driver_unreg)
      [  117.377683]  r4:7f00c9e4 r3:dd60d480
      [  117.381305] [<80358088>] (driver_unregister) from [<80358bb4>] (platform_dri)
      [  117.390642]  r4:7f00ca28 r3:7f00c35c
      [  117.394309] [<80358ba0>] (platform_driver_unregister) from [<7f00c370>] (imx)
      [  117.406188] [<7f00c35c>] (imx_sgtl5000_driver_exit [snd_soc_imx_sgtl5000]) f)
      [  117.417452] [<8008c2b8>] (SyS_delete_module) from [<8000eba0>] (ret_fast_sys)
      [  117.425753]  r6:5f636f73 r5:5f646e73 r4:00016f40
      [  117.430428] ---[ end trace 8fd8a5cb39e46d0e ]---
      
      This problem is well explained by Russell King:
      
      "The sgtl5000 uses a two-stage initialisation process.  The first stage
      is when the platform driver is probed, where some resources are found
      and initialised.  The second stage is via the codec driver's probe
      function, where regulators are found and initialised using the managed
      resource support.
      
      The problem here is that this works fine until the codec driver is
      unbound.  When this occurs, sgtl5000_remove() is called which is a no-op
      as far as the managed resource code is concerned.  The regulators remain
      allocated, and their pointers in sgtl5000_priv remain valid.
      
      If the codec is now re-probed, it will again try and find the regulators,
      which will now be busy.  This will fail.
      
      That's not the only problem - if using the LDO regulator, the regulator
      is unregistered from the regulator core code, but it still has a user.
      When the user is cleaned up (eg, by removing the module) it hits the
      free'd regulator, and this can oops the kernel.
      
      This bug was originally introduced by 63e54cd9 ("ASoC: sgtl5000:
      Use devm_regulator_bulk_get()")."
      
      This reverts commit 63e54cd9.
      
      Tested on a imx53-qsb board.
      Reported-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NFabio Estevam <fabio.estevam@freescale.com>
      Signed-off-by: NMark Brown <broonie@linaro.org>
      e42be7e1
  28. 27 6月, 2014 1 次提交
  29. 27 5月, 2014 1 次提交
  30. 25 4月, 2014 1 次提交