02 Nov, 2017

1 commit

  • Many source files in the tree are missing licensing information, which
    makes it harder for compliance tools to determine the correct license.

    By default all files without license information are under the default
    license of the kernel, which is GPL version 2.

    Update the files which contain no license information with the 'GPL-2.0'
    SPDX license identifier. The SPDX identifier is a legally binding
    shorthand, which can be used instead of the full boiler plate text.

    This patch is based on work done by Thomas Gleixner and Kate Stewart and
    Philippe Ombredanne.

    How this work was done:

    Patches were generated and checked against linux-4.14-rc6 for a subset of
    the use cases:
    - file had no licensing information it it.
    - file was a */uapi/* one with no licensing information in it,
    - file was a */uapi/* one with existing licensing information,

    Further patches will be generated in subsequent months to fix up cases
    where non-standard license headers were used, and references to license
    had to be inferred by heuristics based on keywords.

    The analysis to determine which SPDX License Identifier to be applied to
    a file was done in a spreadsheet of side by side results from of the
    output of two independent scanners (ScanCode & Windriver) producing SPDX
    tag:value files created by Philippe Ombredanne. Philippe prepared the
    base worksheet, and did an initial spot review of a few 1000 files.

    The 4.13 kernel was the starting point of the analysis with 60,537 files
    assessed. Kate Stewart did a file by file comparison of the scanner
    results in the spreadsheet to determine which SPDX license identifier(s)
    to be applied to the file. She confirmed any determination that was not
    immediately clear with lawyers working with the Linux Foundation.

    Criteria used to select files for SPDX license identifier tagging was:
    - Files considered eligible had to be source code files.
    - Make and config files were included as candidates if they contained >5
    lines of source
    - File already had some variant of a license header in it (even if
    Reviewed-by: Philippe Ombredanne
    Reviewed-by: Thomas Gleixner
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

12 Jun, 2017

1 commit

  • Many drivers bind the sequencer stuff in off-load by another driver
    module, so that it's loaded only on demand. In the current code, this
    mechanism doesn't work when the driver is built-in while the sequencer
    is module. We check with IS_REACHABLE() and enable only when the
    sequencer is in the same level of build.

    However, this is basically a overshoot. The binder code
    (snd-seq-device) is an individual module from the sequencer core
    (snd-seq), and we just have to make the former a built-in while
    keeping the latter a module for allowing the scenario like the above.

    This patch achieves that by rewriting Kconfig slightly. Now, a driver
    that provides the manual sequencer device binding should select
    CONFIG_SND_SEQ_DEVICE in a way as
    select SND_SEQ_DEVICE if SND_SEQUENCER != n

    Note that the "!=n" is needed here to avoid the influence of the
    sequencer core is module while the driver is built-in.

    Also, since rawmidi.o may be linked with snd_seq_device.o when
    built-in, we have to shuffle the code to make the linker happy.
    (the kernel linker isn't smart enough yet to handle such a case.)
    That is, snd_seq_device.c is moved to sound/core from sound/core/seq,
    as well as Makefile.

    Last but not least, the patch replaces the code using IS_REACHABLE()
    with IS_ENABLED(), since now the condition meets always when enabled.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

07 Jun, 2017

1 commit

  • When working for devices which support configurable modes for its data
    transmission or which consists of several components, developers are
    likely to use rules of parameters of PCM substream. However, there's no
    infrastructure to assist their work.

    In old days, ALSA PCM core got a local 'RULES_DEBUG' macro to debug
    refinement of parameters for PCM substream. Although this is merely a
    makeshift. With some modifications, we get the infrastructure.

    This commit is for the purpose. Refinement of mask/interval type of
    PCM parameters is probed as tracepoint events as 'hw_mask_param' and
    'hw_interval_param' on existent 'snd_pcm' subsystem.

    Signed-off-by: Takashi Sakamoto
    Signed-off-by: Takashi Iwai

    Takashi Sakamoto
     

25 Apr, 2016

1 commit


16 Oct, 2015

1 commit

  • PCM timer is not always used. For embedded device, we need an interface
    to disable it when it is not needed, to shrink the kernel size and
    memory footprint, here add CONFIG_SND_PCM_TIMER for it.

    When both CONFIG_SND_PCM_TIMER and CONFIG_SND_TIMER is unselected,
    about 25KB saving bonus we can get.

    Please be noted that when disabled, those stubs who using pcm timer
    (e.g. dmix, dsnoop & co) may work incorrectlly.

    Suggested-by: Takashi Iwai
    Signed-off-by: Jie Yang
    Signed-off-by: Takashi Iwai

    Jie Yang
     

28 May, 2015

1 commit

  • We may disable proc fs only for sound part, to reduce ALSA
    memory footprint. So add CONFIG_SND_PROC_FS and replace the
    old CONFIG_PROC_FSs in alsa code.

    With sound proc fs disabled, we can save about 9KB memory
    size on X86_64 platform.

    Signed-off-by: Jie Yang
    Reviewed-by: Mark Brown
    Signed-off-by: Takashi Iwai

    Jie Yang
     

22 May, 2015

3 commits


28 Apr, 2015

2 commits

  • Takashi Iwai
     
  • Currently the ALSA jack core registers only input devices for each jack
    registered. These jack input devices are not readable by userspace devices
    that run as non root. This patch series will implement kctls inside the
    core jack part, including kctls creating, status changing report, for both
    HD-Audio and ASoC jack. This allows non root userspace to read jack status
    and act on it.

    This patch adds a new API called snd_jack_add_new_kctl(), which will create
    a kcontrol, add it to the card, and also attach it to the jack kctl list.

    This patch also initialises the jack kctl list after jack is newed, and
    reports kctl status when jack insertion/removal events occur.

    snd_jack_new() is updated in the following patches to also support creating
    phantom jacks and jack kcontrols. We then remove these duplicated features
    from HDA jack and have jack kctls handled by core throughout HDA and ASoC.

    Signed-off-by: Liam Girdwood
    Modified-by: Jie Yang
    Signed-off-by: Jie Yang
    Reveiwed-by: Mark Brown
    Signed-off-by: Takashi Iwai

    Jie Yang
     

24 Apr, 2015

1 commit


04 Nov, 2014

1 commit

  • ALSA PCM core has a mechanism tracking the PCM hwptr updates for
    analyzing XRUNs. But its log is limited (up to 10) and its log output
    is a kernel message, which is hard to handle.

    In this patch, the hwptr logging is moved to the tracing
    infrastructure instead of its own. Not only the hwptr updates but
    also XRUN and hwptr errors are recorded on the trace log, so that user
    can see such events at the exact timing.

    The new "snd_pcm" entry will appear in the tracing events:
    # ls -F /sys/kernel/debug/tracing/events/snd_pcm
    enable filter hw_ptr_error/ hwptr/ xrun/

    The hwptr is for the regular hwptr update events. An event trace
    looks like:

    aplay-26187 [004] d..3 4012.834761: hwptr: pcmC0D0p/sub0: POS: pos=488, old=0, base=0, period=1024, buf=16384

    "POS" shows the hwptr update by the explicit position update call and
    "IRQ" means the hwptr update by the interrupt,
    i.e. snd_pcm_period_elapsed() call. The "pos" is the passed
    ring-buffer offset by the caller, "old" is the previous hwptr, "base"
    is the hwptr base position, "period" and "buf" are period- and
    buffer-size of the target PCM substream.
    (Note that the hwptr position displayed here isn't the ring-buffer
    offset. It increments up to the PCM position boundary.)

    The XRUN event appears similarly, but without "pos" field.
    The hwptr error events appear with the PCM identifier and its reason
    string, such as "Lost interrupt?".

    The XRUN and hwptr error reports on kernel message are still left, can
    be turned on/off via xrun_debug proc like before. But the bit 3, 4, 5
    and 6 bits of xrun_debug proc are dropped by this patch. Also, along
    with the change, the message strings have been reformatted to be a bit
    more consistent.

    Last but not least, the hwptr reporting is enabled only when
    CONFIG_SND_PCM_XRUN_DEBUG is set.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

09 Jan, 2014

1 commit


15 Aug, 2013

1 commit


12 Jan, 2012

1 commit


23 Dec, 2011

1 commit


16 Nov, 2011

1 commit


08 Jul, 2009

1 commit

  • Using SG-buffers with dma_alloc_coherent() is often very inefficient
    on non-coherent architectures because a tracking record could be
    allocated in addition for each dma_alloc_coherent() call.
    Instead, simply disable SG-buffers but just allocate normal continuous
    buffers on non-supported (currently all but x86) architectures.

    Signed-off-by: Takashi Iwai

    Takashi Iwai
     

25 Oct, 2008

1 commit


30 Jul, 2008

1 commit

  • Since jack detection requires the input subsystem which may not be
    desired on small systems it is not built unless required by a driver
    that is being built. Drivers using jack detection should use a pattern
    like this:

    config SND_FOO
    tristate "..."
    ...
    select SND_JACK if INPUT=y || INPUT=SND

    to ensure that the jack detection API is enabled if the input subsystem
    is. If the input subsystem is not enabled then a stub version of the
    API is provided.

    Signed-off-by: Mark Brown
    Signed-off-by: Takashi Iwai
    Signed-off-by: Jaroslav Kysela

    Mark Brown
     

24 Apr, 2008

1 commit


16 Oct, 2007

3 commits


04 Nov, 2005

1 commit


24 Aug, 2005

1 commit


17 Apr, 2005

1 commit

  • Initial git repository build. I'm not bothering with the full history,
    even though we have it. We can create a separate "historical" git
    archive of that later if we want to, and in the meantime it's about
    3.2GB when imported into git - space that would just make the early
    git days unnecessarily complicated, when we don't have a lot of good
    infrastructure for it.

    Let it rip!

    Linus Torvalds