1. 27 11月, 2009 1 次提交
  2. 23 11月, 2009 2 次提交
  3. 22 11月, 2009 1 次提交
  4. 19 11月, 2009 1 次提交
  5. 18 11月, 2009 3 次提交
  6. 08 11月, 2009 1 次提交
    • K
      ALSA: es18xx: code improvements · faa1242c
      Krzysztof Helt 提交于
      1. Set the third argument of the snd_device_new to not NULL, so there is
         no warning about bug during chip detection. The third argument is not
         used in this driver. It was changed in my previous patch.
      
      2. Remove the fm_port and mpu_port fields from the snd_es18xx structure.
         They can be converted to function arguments.
      
      3. Remove the dmaN_size fields from the snd_es18xx structure. These
         values are used only in pointer functions and can be easily calculated.
      
      4. Remove the ctrl_lock spinlock which is used only in one read function
         which is called once during chip initialization. There are many
         writes to the same register and they are not protected on purpose
         (see the comment ina the snd_es18xx_config_write()).
      
      5. Use the first part of the text5Sources string table as the text4Soruces
         table (they are the same).
      
      6. Merge the same cases for the ES1887 and ES1888 when setting chip's caps.
      
      7. Move the snd_es18xx_reset() to __devinit section.
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      faa1242c
  7. 06 11月, 2009 1 次提交
    • K
      ALSA: cs4236: detect chip in one pass · d114cd84
      Krzysztof Helt 提交于
      The cs4236 was two step detection with call to the snd_wss_free()
      between two steps. The snd_wss_free() did not free a sound device
      created in the snd_wss_create(). This caused an OOPS during module
      removal as the same sound device was released twice. The same OOPS
      happened if the cs4236 module loading failed.
      
      Fix this by adapting the snd_cs4236_create() to correctly work with
      chips less capable then cs4236. The snd_cs4236_create() behaves the
      same as the snd_wss_create() if the chip is less capable than the cs4236.
      Signed-off-by: NKrzysztof Helt <krzysztof.h1@wp.pl>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      d114cd84
  8. 30 10月, 2009 2 次提交
  9. 12 10月, 2009 1 次提交
  10. 10 10月, 2009 2 次提交
  11. 06 10月, 2009 2 次提交
  12. 04 10月, 2009 1 次提交
  13. 01 10月, 2009 1 次提交
  14. 28 9月, 2009 1 次提交
  15. 19 7月, 2009 1 次提交
  16. 08 7月, 2009 1 次提交
  17. 07 7月, 2009 1 次提交
    • O
      ALSA: cmi8330: find OPL3 port automatically · 0b959167
      Ondrej Zary 提交于
      My CMI8329 had OPL3 port specified in SB16 resources. But now I found out that
      it was my modification of the card's PnP EEPROM a couple of years ago (can be
      done using C9SETROM.EXE utility). I did it because the OPL3 port was
      completely missing from PnP data. It seems to be hardwired to 0x388 on
      CMI8329.
      
      Find OPL3 port automatically by searching in WSS and SB16 resources. If not
      found, assume that it's hardwired to 0x388.
      Signed-off-by: NOndrej Zary <linux@rainbow-software.org>
      Signed-off-by: NTakashi Iwai <tiwai@suse.de>
      0b959167
  18. 05 7月, 2009 1 次提交
  19. 29 6月, 2009 2 次提交
  20. 04 6月, 2009 1 次提交
  21. 29 5月, 2009 1 次提交
  22. 04 5月, 2009 1 次提交
  23. 28 4月, 2009 1 次提交
  24. 24 4月, 2009 1 次提交
  25. 14 4月, 2009 2 次提交
  26. 07 4月, 2009 1 次提交
  27. 06 4月, 2009 1 次提交
  28. 17 3月, 2009 1 次提交
  29. 02 3月, 2009 1 次提交
  30. 23 2月, 2009 1 次提交
  31. 17 2月, 2009 2 次提交