19 Dec, 2011

1 commit

  • module_param(bool) used to counter-intuitively take an int. In
    fddd5201 (mid-2009) we allowed bool or int/unsigned int using a messy
    trick.

    It's time to remove the int/unsigned int option. For this version
    it'll simply give a warning, but it'll break next kernel version.

    Signed-off-by: Rusty Russell
    Signed-off-by: Takashi Iwai

    Rusty Russell
     

01 Nov, 2011

4 commits


22 Sep, 2011

1 commit

  • Since commit [e58aa3d2: genirq: Run irq handlers with interrupts disabled],
    We run all interrupt handlers with interrupts disabled
    and we even check and yell when an interrupt handler
    returns with interrupts enabled (see commit [b738a50a:
    genirq: Warn when handler enables interrupts]).

    So now this flag is a NOOP and can be removed.

    Signed-off-by: Yong Zhang
    Acked-by: Peter Ujfalusi
    Acked-by: Mark Brown
    Signed-off-by: Takashi Iwai

    Yong Zhang
     

14 Sep, 2011

1 commit

  • The semantics of snd_mpu401_uart_new()'s interrupt parameters are
    somewhat counterintuitive: To prevent the function from allocating its
    own interrupt, either the irq number must be invalid, or the irq_flags
    parameter must be zero. At the same time, the irq parameter being
    invalid specifies that the mpu401 code has to work without an interrupt
    allocated by the caller. This implies that, if there is an interrupt
    and it is allocated by the caller, the irq parameter must be set to
    a valid-looking number which then isn't actually used.

    With the removal of IRQF_DISABLED, zero becomes a valid irq_flags value,
    which forces us to handle the parameters differently.

    This patch introduces a new flag MPU401_INFO_IRQ_HOOK for when the
    device interrupt is handled by the caller, and makes the allocation of
    the interrupt to depend only on the irq parameter. As suggested by
    Takashi, the irq_flags parameter was dropped because, when used, it had
    the constant value IRQF_DISABLED.

    Signed-off-by: Clemens Ladisch
    Signed-off-by: Takashi Iwai

    Clemens Ladisch
     

27 Jul, 2011

1 commit


31 Mar, 2011

1 commit


02 Nov, 2010

1 commit

  • "gadget", "through", "command", "maintain", "maintain", "controller", "address",
    "between", "initiali[zs]e", "instead", "function", "select", "already",
    "equal", "access", "management", "hierarchy", "registration", "interest",
    "relative", "memory", "offset", "already",

    Signed-off-by: Uwe Kleine-König
    Signed-off-by: Jiri Kosina

    Uwe Kleine-König
     

09 Sep, 2010

1 commit


08 Sep, 2010

1 commit


07 Sep, 2010

1 commit


13 Aug, 2010

2 commits

  • Its hardware is handled more fully by the new azt1605/azt2316 drivers.

    Signed-off-by: Rene Herman
    Signed-off-by: Takashi Iwai

    René Herman
     
  • This is a new driver for Aztech Sound Galaxy ISA soundcards based on the
    AZT1605 and AZT2316 chipsets. It's constructed as two seperate drivers
    for either chipset generated from the same source file, with (very)
    minimal ifdeffery.

    The drivers check the SB DSP version to decide if they are being loaded
    for the right chip. AZT1605 returns 2.1 by default and AZT2316 3.1.
    This isn't full-proof as the DSP version can actually be set through
    software but it's close enough -- as far as I've been able to see, the
    DSP version can not be stored in the EEPROM and the cards will therefore
    startup with the defaults.

    This distinction could (with the same success rate) also be used to
    decide which chip we're looking at at runtime meaning a single, merged
    driver is also an option but I feel it's actually nicer this way. A
    merged driver would have to postpone translating the passed in resource
    values to the card configuration until it knew which one it was looking
    at and would need to postpone erring out on mpu_irq=10 for azt1605 and
    mpu_irq=3 for azt2316.

    The drivers have been tested on various cards. For snd-azt1605:

    FCC-ID I38-MMSN811: Aztech Sound Galaxy Nova 16 Extra
    FCC-ID I38-MMSN822: Aztech Sound Galaxy Pro 16 II

    and for snd-azt2316:

    FCC-ID I38-MMSN824: Aztech Sound Galaxy Pro 16 AB
    FCC-ID I38-MMSN826: Trust Sound Expert DeLuxe Wave 32 (05201)
    FCC-ID I38-MMSN830: Trust Sound Expert DeLuxe 16+ (05202)
    FCC-ID I38-MMSN837: Packard Bell ISA Soundcard 030069
    FCC-ID I38-MMSN846: Trust Sound Expert DeLuxe 16-3D (06300)
    FCC-ID I38-MMSN847: Trust Sound Expert DeLuxe Wave 32-3D (06301)
    FCC-ID I38-MMSN852: Aztech Sound Galaxy Waverider Pro 32-3D

    826 and 846 were also marketed directly by Aztech and then known as:

    FCC-ID I38-MMSN826: Aztech Sound Galaxy Waverider 32+
    FCC-ID I38-MMSN846: Aztech Sound Galaxy Nova 16 Extra II-3D

    Together, these cover the AZT1605 and AT2316A, AZT2316R and AZT2316-S
    chipsets. All cards work fully -- full-duplex PCM, MIDI and FM. Full
    duplex is a little flaky on some.

    I38-MSN811 tends to not work in full-duplex but sometimes does with the
    highest success rate being achieved when you first start the capture and
    then a playback instead of the other way around (it's a CS4231-KL
    codec).

    The cards with an AD1845XP codec (my I38-MMSN826 and one of my
    I38-MMSN830s) are also somewhat duplex-challenged. Sometimes full-duplex
    works, sometimes not and this varies from try to try. This seems likely
    to be a timing problem somewhere inside wss-lib.

    I38-MMSN826 has an additional "ICS2115 WaveFront" wavetable synth
    onboard that isn't supported yet. The wavetable synths on I38-MMSN847
    and I38-MMSN852 are wired directly to the standard MPU-401 UART and the
    AUX1 input on the codec and work without problem.

    CD-ROM audio on the cards is routed to the codec "Line" input, Line-In
    to its Aux input, and FM/Wavetable to its AUX1 input. I did not rename
    the controls due to the capture source enumeration: I see that
    capture-source overrides are hardcoded in wss-lib and this is just too
    ugly to live.

    Versus the old snd-sgalaxy driver these drivers add support for the
    models without a configuration EEPROM (which are common), full-duplex,
    MPU-401 UART and OPL3. In the future they might grow support for that
    ICS2115 WaveFront synth on 826 and an hwdep interface to write to the
    EEPROM on the models that have one.

    Signed-off-by: Rene Herman
    Signed-off-by: Takashi Iwai

    René Herman
     

29 Jul, 2010

2 commits


20 May, 2010

2 commits


17 May, 2010

1 commit

  • Smatch complains that if (dev == SNDRV_CARDS) we're one past the end of
    the array. That's unlikely to happen in real life, I suppose.

    Also smatch complains about "strcpy(card->shortname, pcm->name);"
    The "pcm->name" buffer is 80 characters and "card->shortname" is 32
    characters. If you follow the call paths it turns out we never actually
    use more than 16 characters so it's not a problem. But anyway, let's
    make it easy for people auditing this in the future.

    Signed-off-by: Dan Carpenter
    Signed-off-by: Takashi Iwai

    Dan Carpenter
     

10 May, 2010

2 commits

  • The ESS ES968 chip is nothing more then a PnP companion
    for a non-PnP audio chip. It was paired with non-PnP ESS' chips:
    ES688 and ES1688. The ESS' audio chips are handled by the es1688
    driver in native mode. The PnP cards are handled by the ES968
    driver in SB compatible mode.

    Move the ES968 chip handling to the es1688 driver so the driver
    can handle both PnP and non-PnP cards. The es968 is removed.

    Also, a new PnP id is added for the card I acquired (the change
    was tested on this card).

    Signed-off-by: Krzysztof Helt
    Signed-off-by: Takashi Iwai

    Krzysztof Helt
     
  • Allocate the snd_es1688 during the snd_card allocation.
    This allows to remove the card pointer from the snd_es1688 structure.

    Signed-off-by: Krzysztof Helt
    Signed-off-by: Takashi Iwai

    Krzysztof Helt
     

26 Apr, 2010

1 commit


13 Apr, 2010

3 commits


30 Mar, 2010

1 commit

  • …it slab.h inclusion from percpu.h

    percpu.h is included by sched.h and module.h and thus ends up being
    included when building most .c files. percpu.h includes slab.h which
    in turn includes gfp.h making everything defined by the two files
    universally available and complicating inclusion dependencies.

    percpu.h -> slab.h dependency is about to be removed. Prepare for
    this change by updating users of gfp and slab facilities include those
    headers directly instead of assuming availability. As this conversion
    needs to touch large number of source files, the following script is
    used as the basis of conversion.

    http://userweb.kernel.org/~tj/misc/slabh-sweep.py

    The script does the followings.

    * Scan files for gfp and slab usages and update includes such that
    only the necessary includes are there. ie. if only gfp is used,
    gfp.h, if slab is used, slab.h.

    * When the script inserts a new include, it looks at the include
    blocks and try to put the new include such that its order conforms
    to its surrounding. It's put in the include block which contains
    core kernel includes, in the same order that the rest are ordered -
    alphabetical, Christmas tree, rev-Xmas-tree or at the end if there
    doesn't seem to be any matching order.

    * If the script can't find a place to put a new include (mostly
    because the file doesn't have fitting include block), it prints out
    an error message indicating which .h file needs to be added to the
    file.

    The conversion was done in the following steps.

    1. The initial automatic conversion of all .c files updated slightly
    over 4000 files, deleting around 700 includes and adding ~480 gfp.h
    and ~3000 slab.h inclusions. The script emitted errors for ~400
    files.

    2. Each error was manually checked. Some didn't need the inclusion,
    some needed manual addition while adding it to implementation .h or
    embedding .c file was more appropriate for others. This step added
    inclusions to around 150 files.

    3. The script was run again and the output was compared to the edits
    from #2 to make sure no file was left behind.

    4. Several build tests were done and a couple of problems were fixed.
    e.g. lib/decompress_*.c used malloc/free() wrappers around slab
    APIs requiring slab.h to be added manually.

    5. The script was run on all .h files but without automatically
    editing them as sprinkling gfp.h and slab.h inclusions around .h
    files could easily lead to inclusion dependency hell. Most gfp.h
    inclusion directives were ignored as stuff from gfp.h was usually
    wildly available and often used in preprocessor macros. Each
    slab.h inclusion directive was examined and added manually as
    necessary.

    6. percpu.h was updated not to include slab.h.

    7. Build test were done on the following configurations and failures
    were fixed. CONFIG_GCOV_KERNEL was turned off for all tests (as my
    distributed build env didn't work with gcov compiles) and a few
    more options had to be turned off depending on archs to make things
    build (like ipr on powerpc/64 which failed due to missing writeq).

    * x86 and x86_64 UP and SMP allmodconfig and a custom test config.
    * powerpc and powerpc64 SMP allmodconfig
    * sparc and sparc64 SMP allmodconfig
    * ia64 SMP allmodconfig
    * s390 SMP allmodconfig
    * alpha SMP allmodconfig
    * um on x86_64 SMP allmodconfig

    8. percpu.h modifications were reverted so that it could be applied as
    a separate patch and serve as bisection point.

    Given the fact that I had only a couple of failures from tests on step
    6, I'm fairly confident about the coverage of this conversion patch.
    If there is a breakage, it's likely to be something in one of the arch
    headers which should be easily discoverable easily on most builds of
    the specific arch.

    Signed-off-by: Tejun Heo <tj@kernel.org>
    Guess-its-ok-by: Christoph Lameter <cl@linux-foundation.org>
    Cc: Ingo Molnar <mingo@redhat.com>
    Cc: Lee Schermerhorn <Lee.Schermerhorn@hp.com>

    Tejun Heo
     

09 Mar, 2010

1 commit


05 Mar, 2010

1 commit

  • While trying to compile jazz16 isa sound driver on alpha (2.6.33+git), I
    found a compile failure in jazz16.c (udelay is unknown). Fix it by
    including delay.h.

    Signed-foo-by: Meelis Roos
    Signed-off-by: Takashi Iwai

    Meelis Roos
     

04 Mar, 2010

1 commit


16 Feb, 2010

1 commit


08 Jan, 2010

1 commit

  • The patch "sbawe: fix memory detection" fixed detection
    for memoryless SB32 cards but broke detection of memory
    above 512KB. This patch fixes the regression.

    The patch has been tested on the SB32 card (CT3670) with
    0MB, 2MB and 8MB memory installed.

    Signed-off-by: Krzysztof Helt
    Signed-off-by: Jaroslav Kysela

    Krzysztof Helt
     

25 Dec, 2009

1 commit


22 Dec, 2009

1 commit


21 Dec, 2009

2 commits

  • This is one of Sound Blaster Pro compatible chipsets which is supported
    by Linux OSS driver and was missing native supoort for ALSA.

    The Jazz16 audio codec is Crystal CS4216 which is capable
    of playback and recording up to 48 kHz stereo.

    Signed-off-by: Krzysztof Helt
    Signed-off-by: Takashi Iwai

    Krzysztof Helt
     
  • Memory amount is increased before a successful write-read
    sequence is done. Thus, 512 kB of onboard memory is detected
    on memoryless cards like SB32.

    Move the increasing of memory counter after successful read
    is done.

    Signed-off-by: Krzysztof Helt
    Signed-off-by: Takashi Iwai

    Krzysztof Helt
     

19 Dec, 2009

1 commit


15 Dec, 2009

2 commits


14 Dec, 2009

1 commit