Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 12 6月, 2012 1 次提交
  3. 07 4月, 2012 1 次提交
  5. 01 4月, 2012 2 次提交
  7. 23 12月, 2011 1 次提交
  9. 20 12月, 2011 1 次提交
    • S
      ASoC: Tegra+WM8903 machine: Add device tree binding · 07cdf36d
      由 Stephen Warren 提交于 
      This driver is parameterized in two ways:

a) Platform data, which supplies the set of GPIOs used by the driver.
   These GPIOs can now be parsed out of device tree.

b) Machine-specific DAPM route arrays embedded into the ASoC machine
   driver itself. Historically, the driver picks the appropriate array
   to use using machine_is_*(). The driver now requires this array to
   be parsed from device tree when instantiated through device tree,
   using the core ASoC support for this parsing.

Based on work by John Bonesio, but significantly reworked since then.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      07cdf36d
  11. 08 12月, 2011 1 次提交
    • S
      ASoC: Tegra: Move DAS configuration into DAS driver · 7b9b5e11
      由 Stephen Warren 提交于 
      Move DAS routing setup into the DAS driver itself. This removes the need
to duplicate this in each machine driver, of which we'll soon have three.

An added advantage is that the machine drivers no longer call the Tegra20-
specific DAS functions by name, so the machine driver no longer needs to
be split up into Tegra20 and Tegra30 versions.

If individual machine drivers need a different routing setup to this
default, they can still call the DAS functions to set that up.

Long-term, DAS will be a codec driver, and user-space will be able to
control its routing, possibly within constraints that the machine driver
sets up. Configuring the DAS routing from the DAS driver is a very slight
move in that direction.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      7b9b5e11
  13. 29 11月, 2011 1 次提交
  15. 24 11月, 2011 1 次提交
  17. 23 11月, 2011 2 次提交
  19. 08 10月, 2011 1 次提交
  21. 24 8月, 2011 1 次提交
    • S
      ASoC: Tegra: wm8903 machine driver: Drop Ventana support · ee1a4d4b
      由 Stephen Warren 提交于 
      Board file support for Ventana is not yet mainlined, and probably won't
ever be given the move to Device-Tree. Consequently, the Ventana entry
is being removed from arch/arm/tools/mach-types in the next merge window,
since it was registered over a year ago.

This will also remove function machine_is_ventana(), which is used by
the ASoC Tegra WM8903 machine driver. This will cause compilation
failures. Drop Ventana support to resolve this.

Hopefully, in the not-too-distant future, tegra_wm8903.c will be able to
configure itself from Device-Tree, and hence we'll be able to re-instate
Ventana support just by creating a .dts file for the board.

Also note that Aebl support is in a similar boat. However, that board
isn't scheduled for deprecation for at least another 5 months, and
perhaps we will have completely removed non-Device-Tree support from
tegra_wm8903.c by then and/or adjusted mach-types policy.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      ee1a4d4b
  23. 09 8月, 2011 1 次提交
    • S
      ASoC: Tegra: wm8903 machine driver: Allow re-insertion of module · 29591ed4
      由 Stephen Warren 提交于 
      Two issues were preventing module snd-soc-tegra-wm8903.ko from being
removed and re-inserted:

a) The speaker-enable GPIO is hosted by the WM8903 chip. This GPIO must
   be freed before snd_soc_unregister_card() is called, because that
   triggers wm8903.c:wm8903_remove(), which calls gpiochip_remove(), which
   then fails if any of the GPIOs are in use. To solve this, free all GPIOs
   first, so the code doesn't care where they come from.

b) We need to call snd_soc_jack_free_gpios() to match the call to
   snd_soc_jack_add_gpios() during initialization. Without this, the
   call to snd_soc_jack_add_gpios() fails during any subsequent modprobe
   and initialization, since the GPIO and IRQ are already registered. In
   turn, this causes the headphone state not to be monitored, so the
   headphone is assumed not to be plugged in, and the audio path to it is
   never enabled.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Cc: stable@kernel.org
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      29591ed4
  25. 27 5月, 2011 1 次提交
  27. 20 4月, 2011 5 次提交
  29. 19 4月, 2011 5 次提交
  31. 06 4月, 2011 1 次提交
  33. 14 2月, 2011 4 次提交
  35. 10 2月, 2011 1 次提交
  37. 09 2月, 2011 2 次提交
  39. 01 2月, 2011 1 次提交
  41. 31 1月, 2011 5 次提交
  43. 14 1月, 2011 1 次提交