1. 10 4月, 2012 1 次提交
  2. 24 3月, 2012 1 次提交
  3. 19 3月, 2012 1 次提交
    • H
      [media] tea575x-tuner: update to latest V4L2 framework requirements · d4ecc83b
      Hans Verkuil 提交于
      The tea575x-tuner module has been updated to use the latest V4L2 framework
      functionality. This also required changes in the drivers that rely on it.
      
      The tea575x changes are:
      
      - The drivers must provide a v4l2_device struct to the tea module.
      - The radio_nr module parameter must be part of the actual radio driver,
        and not of the tea module.
      - Changed the frequency range to the normal 76-108 MHz range instead of
        50-150.
      - Add hardware frequency seek support.
      - Fix broken rxsubchans/audmode handling.
      - The application can now select between stereo and mono.
      - Support polling for control events.
      - Add V4L2 priority handling.
      
      And radio-sf16fmr2.c now uses the isa bus kernel framework.
      Signed-off-by: NHans Verkuil <hans.verkuil@cisco.com>
      Thanks-to: Ondrej Zary <linux@rainbow-software.org>
      Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      d4ecc83b
  4. 16 3月, 2012 1 次提交
    • P
      device.h: audit and cleanup users in main include dir · 313162d0
      Paul Gortmaker 提交于
      The <linux/device.h> header includes a lot of stuff, and
      it in turn gets a lot of use just for the basic "struct device"
      which appears so often.
      
      Clean up the users as follows:
      
      1) For those headers only needing "struct device" as a pointer
      in fcn args, replace the include with exactly that.
      
      2) For headers not really using anything from device.h, simply
      delete the include altogether.
      
      3) For headers relying on getting device.h implicitly before
      being included themselves, now explicitly include device.h
      
      4) For files in which doing #1 or #2 uncovers an implicit
      dependency on some other header, fix by explicitly adding
      the required header(s).
      
      Any C files that were implicitly relying on device.h to be
      present have already been dealt with in advance.
      
      Total removals from #1 and #2: 51.  Total additions coming
      from #3: 9.  Total other implicit dependencies from #4: 7.
      
      As of 3.3-rc1, there were 110, so a net removal of 42 gives
      about a 38% reduction in device.h presence in include/*
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      313162d0
  5. 15 3月, 2012 1 次提交
  6. 13 3月, 2012 1 次提交
  7. 12 3月, 2012 1 次提交
  8. 07 3月, 2012 1 次提交
  9. 04 3月, 2012 1 次提交
  10. 02 3月, 2012 1 次提交
  11. 28 2月, 2012 1 次提交
  12. 22 2月, 2012 2 次提交
    • M
      ASoC: core: Add support for masking out parts of coefficient blocks · f831b055
      Mark Brown 提交于
      Chip designers frequently include things like the enable and disable
      controls for algorithms in the register blocks which also hold the
      coefficients. Since it's desirable to split out the enable/disable
      control from userspace the plain SND_SOC_BYTES() isn't optimal for
      these devices.
      
      Add a SND_SOC_BYTES_MASK() which allows a bitmask from the first word
      of the block to be excluded from the control. This supports the needs
      of devices I've looked at and lets us have a reasonably simple API.
      Further controls can be added in future if that's needed.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      f831b055
    • M
      ASoC: core: Add SND_SOC_BYTES control for coefficient blocks · 71d08516
      Mark Brown 提交于
      Allow devices to export blocks of registers to the application layer,
      intended for use for reading and writing coefficient data which can't
      usefully be worked with by the kernel at runtime (for example, due to
      requiring complex and expensive calculations or being the results of
      callibration procedures). Currently drivers are using platform data to
      provide configurations for coefficient blocks which isn't at all
      convenient for runtime management or configuration development.
      
      Currently only devices using regmap are supported, an error will be
      generated for any attempt to work with a byte control on a non-regmap
      device. There's no fundamental block to other devices so support could
      be added if required.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      71d08516
  13. 20 2月, 2012 1 次提交
  14. 18 2月, 2012 5 次提交
  15. 16 2月, 2012 1 次提交
  16. 09 2月, 2012 2 次提交
    • M
      ASoC: core: Allow CODECs to set ignore_pmdown_time in the driver struct · 5124e69e
      Mark Brown 提交于
      This is usually not a use case dependant flag anyway.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      5124e69e
    • L
      ALSA: PCM - Add PCM creation API for internal PCMs. · 945e5038
      Liam Girdwood 提交于
      The new ASoC dynamic PCM core needs to create PCMs and substreams that are
      for use by internal ASoC drivers only and not visible to userspace for
      direct IO. These new PCMs are similar to regular PCMs expect they have no
      device nodes or procfs entries. The ASoC component drivers use them in exactly
      the same way as regular PCMs for PCM and DAI operations.
      
      The intention is that a dynamic PCM based driver will register both regular
      PCMs and internal PCMs. The regular PCMs will be used for all IO with userspace
      however the internal PCMs will be used by the driver to route digital audio
      through numerous back end DAI links (with potentially a DSP providing different
      hw_params, DAI formats based on the regular front end PCM params) to devices
      like CODECs, MODEMs, Bluetooth, FM, DMICs, etc
      
      This patch adds a new snd_pcm_new_internal() API call to create the internal PCM
      without device nodes or procfs. It also adds adds a new internal flag to snd_pcm.
      
      [fixed minor coding-style issues by tiwai]
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      945e5038
  17. 07 2月, 2012 1 次提交
  18. 04 2月, 2012 1 次提交
    • L
      ASoC: core: Add support for DAI and machine kcontrols. · 022658be
      Liam Girdwood 提交于
      Currently ASoC can only add kcontrols using codec and platform component device
      handles. It's also desirable to add kcontrols for DAIs (i.e. McBSP) and for
      SoC card machine drivers too. This allows the kcontrol to have a direct handle to
      the parent ASoC component DAI/SoC Card/Platform/Codec device and hence easily
      get it's private data.
      
      This change makes snd_soc_add_controls() static and wraps it in the folowing
      calls (card and dai are new) :-
      
      snd_soc_add_card_controls()
      snd_soc_add_codec_controls()
      snd_soc_add_dai_controls()
      snd_soc_add_platform_controls()
      
      This patch also does a lot of small mechanical changes in individual codec drivers
      to replace snd_soc_add_controls() with snd_soc_add_codec_controls().
      
      It also updates the McBSP DAI driver to use snd_soc_add_dai_controls().
      
      Finally, it updates the existing machine drivers that register controls to either :-
      
      1) Use snd_soc_add_card_controls() where no direct codec control is required.
      2) Use snd_soc_add_codec_controls() where there is direct codec control.
      
      In the case of 1) above we also update the machine drivers to get the correct
      component data pointers from the kcontrol (rather than getting the machine pointer
      via the codec pointer).
      Signed-off-by: NLiam Girdwood <lrg@ti.com>
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      022658be
  19. 03 2月, 2012 1 次提交
  20. 31 1月, 2012 1 次提交
  21. 30 1月, 2012 1 次提交
  22. 27 1月, 2012 2 次提交
  23. 25 1月, 2012 2 次提交
  24. 22 1月, 2012 1 次提交
  25. 20 1月, 2012 1 次提交
    • M
      ASoC: Allow drivers to specify how many bits are significant on a DAI · 58ba9b25
      Mark Brown 提交于
      Most devices accept data in formats that don't correspond directly to
      their internal format. ALSA allows us to set a msbits constraint which
      tells userspace about this in case it finds it useful (for example, in
      order to avoid wasting effort dithering bits that will be ignored when
      raising the sample size of data) so provide a mechanism for drivers to
      specify the number of bits that are actually significant on a DAI and
      add the appropriate constraints along with all the others.
      
      This is done slightly awkwardly as the constraint is specified per sample
      size - we loop over every possible sample size, including ones that the
      device doesn't support and including ones that have fewer bits than are
      actually used, but this is harmless as the upper layers do the right thing
      in these cases.
      Signed-off-by: NMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: NLiam Girdwood <lrg@ti.com>
      58ba9b25
  26. 11 1月, 2012 1 次提交
  27. 04 1月, 2012 1 次提交
  28. 01 1月, 2012 1 次提交
  29. 23 12月, 2011 4 次提交