Skip to content

L
linux

xiphi1978 / linux

通知 2
Star 0
Fork 0
L
linux

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 10 4月, 2013 1 次提交
  3. 09 12月, 2012 1 次提交
  5. 06 8月, 2012 1 次提交
  7. 12 6月, 2012 4 次提交
  9. 09 6月, 2012 1 次提交
  11. 03 6月, 2012 2 次提交
  13. 04 4月, 2012 1 次提交
  15. 02 1月, 2012 1 次提交
  17. 07 12月, 2011 1 次提交
  19. 06 12月, 2011 5 次提交
    • M
      ASoC: Don't fail if we can't read the IRQ type in WM8903 · 6664ee11
      由 Mark Brown 提交于 
      If we fail to read the IRQ type from the interrupt controller don't
fail, just assume a value and solider on - we may fail later when we try
to request the IRQ but it's possible we'll succeed.
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      6664ee11
    • S
      ASoC: WM8903: Add device tree binding · 5d680b3a
      由 Stephen Warren 提交于 
      Document the device tree binding for the WM8903 codec, and modify the
driver to extract platform data from the device tree, if present.

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>
      5d680b3a
    • S
      ASoC: WM8903: Get default irq_active_low from IRQ controller · 9d35f3e1
      由 Stephen Warren 提交于 
      If the WM8903 is hooked up to an interrupt, set the irq_active_low flag
in the default platform data based on the IRQ's IRQ_TYPE. Map IRQ_TYPE_NONE
(a lack of explicit configuration/restriction) to irq_active_low = false;
the previous default.

This code is mainly added to support device tree interrupt bindings,
although will work perfectly well in a non device tree system too.

Any interrupt controller that supports only a single IRQ_TYPE could
set each IRQ's type based on that restriction. This applies equally
with and without device tree. To cater for interrupt controllers
that don't do this, for which irqd_get_trigger_type() will return
IRQ_TYPE_NONE, the platform data irq_active_low field may be used
in systems that don't use device tree.

With device tree, every IRQ must have some IRQ_TYPE set.

Controllers that support DT and multiple IRQ_TYPEs must define the
interrupts property (as used in interrupt source nodes) such that it
defines the IRQ_TYPE to use. When the core DT setup code initializes
wm8903->irq, the interrupts property will be parsed, and as a side-
effect, set the IRQ's IRQ_TYPE for the WM8903 probe() function to read.

Controllers that support DT and a single IRQ_TYPE could arrange to
set the IRQ_TYPE somehow during their initialization, or hard-code
it during the processing of the child interrupts property.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      9d35f3e1
    • S
      ASoC: WM8903: Remove conditionals checking pdata != NULL · db817784
      由 Stephen Warren 提交于 
      The pdata pointer is now always valid. Remove any conditions that check
its validity.

This patch is mostly just removing an indentation level. One variable had
to be moved due to the removal of a scope, and one comment was split into
two. Viewing the patch with git show/diff -b will show that it's actually
very small.

Note that WM8903_MIC_BIAS_CONTROL_0 is now written unconditionally,
whereas it used to be written only if pdata was supplied. Since
defpdata.micdet_cfg = 0, this unconditional write simply echos the HW
defaults in the case where pdata is not supplied.

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>
      db817784
    • S
      ASoC: WM8903: Fix platform data gpio_cfg confusion · a0f203d3
      由 Stephen Warren 提交于 
      wm8903_platform_data.gpio_cfg[] was intended to be interpreted as follows:
0:       Don't touch this GPIO's configuration register
1..7fff: Write that value to the GPIO's configuration register
8000:    Write zero to the GPIO's configuration register
other:   Undefined (invalid)

The rationale is that platform data is usually global data, and a value of
zero means that the field wasn't explicitly set to anything (e.g. because
the field was new to the pdata type, and existing users weren't update to
initialize it) and hence the value zero should be ignored. 0x8000 is an
explicit way to get 0 in the register.

The code worked this way until commit 7cfe5617 "ASoC: wm8903: Expose GPIOs
through gpiolib", where the behaviour was changed due to my lack of
awareness of the above rationale.

This patch reverts to the intended behaviour, and updates all in-tree users
to use the correct scheme. This also makes WM8903 consistent with other
devices that use a similar scheme.

WM8903_GPIO_NO_CONFIG is also renamed to WM8903_GPIO_CONFIG_ZERO so that
its name accurately reflects its purpose.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Cc: Olof Johansson <olof@lixom.net>
Cc: Colin Cross <ccross@android.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      a0f203d3
  21. 03 12月, 2011 8 次提交
  23. 02 12月, 2011 2 次提交
  25. 29 11月, 2011 1 次提交
  27. 27 11月, 2011 1 次提交
  29. 23 11月, 2011 1 次提交
    • L
      ASoC: Constify snd_soc_dai_ops structs · 85e7652d
      由 Lars-Peter Clausen 提交于 
      Commit 1ee46ebd("ASoC: Make the DAI ops constant in the DAI structure")
introduced the possibility to have constant DAI ops structures, yet this is
barley used in both existing drivers and also new drivers being submitted,
although none of them modifies its DAI ops structure. The later is not
surprising since existing drivers are often used as templates for new drivers.
So this patch just constifies all existing snd_soc_dai_ops structs to eliminate
the issue altogether.

The patch was generated with the following coccinelle semantic patch:
// <smpl>
@@
identifier ops;
@@
-struct snd_soc_dai_ops ops =
+const struct snd_soc_dai_ops ops =
{ ... };
// </smpl>
Signed-off-by: NLars-Peter Clausen <lars@metafoo.de>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      85e7652d
  31. 09 8月, 2011 1 次提交
  33. 17 5月, 2011 1 次提交
  35. 10 5月, 2011 1 次提交
  37. 20 4月, 2011 1 次提交
    • S
      ASoC: WM8903: Implement DMIC support · 97945c46
      由 Stephen Warren 提交于 
      In addition to the currently supported analog capture path, the WM8903
also supports digital mics.

The analog and digital capture paths are exclusive; a mux is present to
select the capture source.

Logically, the mux exists to select the decimator's input, from either
the ADC or DMIC block outputs. However, the ADC power domain also
includes the DMIC interface. Consequently, this change represents the
mux as existing immediately before the ADC, and selecting between the
Input PGA and DMIC block outputs.

An alternative might be to represent the mux in its correct location,
and associate the ADC power enable controls with both the real ADC, and
a fake ADC for the DMIC?
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Acked-by: NLiam Girdwood <lrg@ti.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      97945c46
  39. 08 4月, 2011 1 次提交
    • D
      ASoC: WM8903: HP and Line out PGA/mixer DAPM fixes · 1b877cb5
      由 Dilan Lee 提交于 
      Update the headphone and line out mixers and PGAs use the same logical
set of register bits and sequencing as the speaker mixer/PGA.

This allows ALSA controls for mute and volume on headphone and line out
to operate correctly.

Per conversation on alsa-devel, earlier datasheets indicated that the
POWER_MANAGEMENT_* register bits 0 and 1 were aliases to ANALOG_* register
bits 0 and 4, and hence only one copy of those bits was programmed.
However, later datasheets corrected this.

From: Dilan Lee <dilee@nvidia.com>
[swarren: Applied same change to headphone widgets]
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      1b877cb5
  41. 30 3月, 2011 1 次提交
  43. 14 2月, 2011 2 次提交
  45. 11 2月, 2011 1 次提交