- 20 Oct, 2015 13 commits
-
-
Takashi Sakamoto authored
When MIDI buffer stores two or more MIDI messages, TASCAM driver transfers asynchronous transactions including one MIDI message and extra bytes from second MIDI message. This commit fixes this bug by clearing needless bytes in the buffer. The consumed bytes are already calculated correctly, thus the sequence of transactions is already correct. Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In transactions for MIDI messages, the first byte is used for label and the rest is for MIDI bytes. In current code, these are handled correctly, while there's a small mistake for loop condition to include meaningless statement. This commit adds two local variables for them and improve the loop condition. Signed-off-by:
-
Takashi Sakamoto authored
In the callback function of asynchronous MIDI port, the intension of some local variables are not clear. This commit improves them. The 'len' variable is used to calculate the number of MIDI bytes including in the transaction. The 'consume' variable is used to return the actual number of consumed bytes in ALSA MIDI buffer. Signed-off-by:
-
Takashi Sakamoto authored
In the callback function of asynchronous MIDI port, some local variables are declared 'unsigned int', while they're assigned to int value of return from snd_rawmidi_transmit_peek(). This commit fixes the type. Signed-off-by:
-
Takashi Sakamoto authored
The given buffer to callback function is cleared in caller side. This commit removes buffer initialization in callee side. Signed-off-by:
-
Takashi Iwai authored
-
Subhransu S. Prusty authored
With the new modalias infrastructure support added for hda, create a macro for ext devices similar to legacy to add the device entry. Signed-off-by:
Subhransu S. Prusty <subhransu.s.prusty@intel.com> Signed-off-by:
Vinod Koul <vinod.koul@intel.com> Signed-off-by:
-
Thierry Reding authored
By setting the MODALIAS variable in uevents, userspace helpers will be enabled to load modules via the module alias associated with a device. This information is required to automatically load HDA codec drivers instead of having to explicitly request the various modules in the HDA core code. [Note that currently the legacy HDA controller driver tries to bind codec modules manually. It's for supporting the fallback generic drivers. This new udev modalias support was added rather for ASoC HDA ext drivers, since this addition itself won't hurt the legacy HDA -- tiwai] [Use the common helper function to generate the modalias -- tiwai] Signed-off-by:
Thierry Reding <treding@nvidia.com> Reviewed-by:
-
Takashi Iwai authored
Finally we have a proper infrastructure to generate the modaliases automatically, let's move to hda_device_id from the legacy hda_codec_preset that contains basically the same information. The patch function hook is stored in driver_data field, which is long, and we need an explicit cast. Other than that, the conversion is mostly straightforward. Each entry is even simplified using a macro, and the lengthy (and error-prone) manual modaliases got removed. As a result, we achieved a quite good diet: 14 files changed, 407 insertions(+), 595 deletions(-) Reviewed-by:
-
Subhransu S. Prusty authored
This patch just adds modalias sysfs entry to each hdaudio bus entry. [rewritten to call the common helper function by tiwai] Signed-off-by:
-
Takashi Iwai authored
This patch provide a new common helper function, snd_hdac_codec_modalias(), to give the codec modalias name string. This function will be used by multiple places in the later patches. Reviewed-by:
-
Subhransu S. Prusty authored
For generating modalias entries automatically, move the definition of struct hda_device_id to linux/mod_devicetable.h and add the handling of this record in file2alias helper. The new modalias is represented with combination of vendor id, device id, and api version as "hdaudio:vNrNaN". This patch itself doesn't convert the existing modaliases. Since they were added manually, this patch won't give any regression by itself at this point. [Modified the modalias format to adapt the api_version field, and drop invalid ANY_ID definition by tiwai] Signed-off-by:
-
Takashi Iwai authored
For distinguishing the difference between HDA legacy and ext codec driver entries, we need to expose the value corresponding to type field. This patch adds a new field, api_version, to hda_device_id struct, so that this information is embedded in modalias string. Although the information is basically redundant (struct hdac_device already has type field), the helper that extracts from MODULE_DEVICE_TABLE() won't take it account except for the exported table entries themselves. So we need to put the same information in the table, too. Reviewed-by:
-
- 19 Oct, 2015 17 commits
-
-
Dan Carpenter authored
Let's leave space for the NUL char otherwise the static checkers complain that we go beyond the end of the array. Fixes: 53b3ffee ('ALSA: firewire-tascam: change device probing processing') Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Reviewed-by:
-
Ricard Wanderlof authored
The device has no mixer (and identifies itself as such), so just skip the mixer definition. Signed-off-by:
Ricard Wanderlof <ricardw@axis.com> Signed-off-by:
-
Ricard Wanderlof authored
For the Zoom R16/24 (tx_length_quirk set), when calculating the maximum sample frequency, consideration must be made for the fact that four bytes of the packet contain a length descriptor and consequently must not be counted as part of the audio data. This is corroborated by the wMaxPacketSize for this device, which is 108 bytes according for the USB playback endpoint descriptor. The frame size is 8 bytes (2 channels of 4 bytes each), and the 108 bytes thus work out as 13 * 8 + 4, i.e. corresponding to 13 frames plus the additional 4 byte length descriptor. Signed-off-by:
-
Ricard Wanderlof authored
The Zoom R16/24 have a nonstandard playback format where each isochronous packet contains a length descriptor in the first four bytes. (Curiously, capture data does not contain this and requires no quirk.) The quirk involves adding the extra length descriptor whenever outgoing isochronous packets are generated, both in pcm.c (outgoing audio) and endpoint.c (silent data). In order to make the quirk as unintrusive as possible, for pcm.c:prepare_playback_urb(), the isochronous packet descriptors are initially set up in the same way no matter if the quirk is enabled or not. Once it is time to actually copy the data into the outgoing packet buffer (together with the added length descriptors) the isochronous descriptors are adjusted in order take the increased payload length into account. For endpoint.c:prepare_silent_urb() it makes more sense to modify the actual function, partly because the function is less complex to start with and partly because it is not as time-critical as prepare_playback_urb() (whose bulk is run with interrupts disabled), so the (minute) additional time spent in the non-quirk case is motivated by the simplicity of having a single function for all cases. The quirk is controlled by the new tx_length_quirk member in struct snd_usb_substream and struct snd_usb_audio, which is conveyed to pcm.c and endpoint.c from quirks.c in a similar manner to the txfr_quirk member in the same structs. In contrast to txfr_quirk however, the quirk is enabled directly in quirks.c:create_standard_audio_quirk() by checking the USB ID in that function. Another option would be to introduce a new QUIRK_AUDIO_ZOOM_INTERFACE or somesuch, which would have made the quirk very plain to see in the quirk table, but it was felt that the additional code needed to implement it this way would just make the implementation more complex with no real gain. Tested with a Zoom R16, both by doing capture and playback separately using arecord and aplay (8 channel capture and 2 channel playback, respectively), as well as capture and playback together using Ardour, as well as Audacity and Qtractor together with jackd. The R24 is reportedly compatible with the R16 when used as an audio interface. Both devices share the same USB ID and have the same number of inputs (8) and outputs (2). Therefore "R16/24" is mentioned throughout the patch. Regression tested using an Edirol UA-5 in both class compliant (16-bit) and "advanced" (24 bit, forces the use of quirks) modes. Signed-off-by:
Panu Matilainen <pmatilai@laiskiainen.org> Signed-off-by:
-
Ricard Wanderlof authored
Preparation for adding Zoom R16/24 quirk. No functional change. Signed-off-by:
-
Ricard Wanderlof authored
Refactoring in preparation for adding Zoom R16/24 quirk. No functional change. Signed-off-by:
-
Ricard Wanderlof authored
Refactoring in preparation for adding Zoom R16/24 quirk. No functional change. Signed-off-by:
-
Ricard Wanderlof authored
Refactoring in preparation for adding Zoom R16/24 quirk. No functional change. Signed-off-by:
-
Takashi Sakamoto authored
TASCAM FireOne is based on OXFW971 and ALSA OXFW driver can support it. These are values of identical registers. $ ./firewire-request /dev/fw1 read 0xfffff0050000 result: 97100105 $ ./firewire-request /dev/fw1 read 0xfffff0090020 result: 39373100 This commit adds an entry for this model. This model has physical controls and its MIDI control messages are transferred to second MIDI data stream multiplexed in one MIDI conformant data channel. Signed-off-by:
-
Takashi Sakamoto authored
In IEC 61883-6, sequence multiplexing is applied to MIDI conformant data channel. As a result, eight MIDI data streams are included in the channel. Although ALSA AM824 data block processing layer implements this multiplexing, current OXFW driver doesn't utilize it due to wrong calculation of MIDI ports. This commit fixes this bug to add proper calculation. Although this commit allows to use 8 MIDI data streams, the number of available MIDI ports is limited by the number of ALSA MIDI ports added by the driver. Fixes: df075fee('ALSA: firewire-lib: complete AM824 data block processing layer') Signed-off-by:
-
Takashi Sakamoto authored
Current OXFW driver calculates the number of MIDI ports just before adding ALSA MIDI ports. It's convenient for some devices with quirks to move these codes before handling quirks. This commit implements this idea. Signed-off-by:
-
Takashi Sakamoto authored
When asynchronous MIDI port is closed before callbacked, the callback function causes NULL pointer dereference to missing MIDI substream. This commit fixes this bug. Fixes: e8a40d9b('ALSA: firewire-lib: schedule work again when MIDI substream has rest of MIDI messages') Reported-by:
-
Takashi Sakamoto authored
The contents of Config ROM in firewire device structure are already aligned to CPU-endianness. Thus, no need to convert it again. This commit removes needless conversions Fixes: 9edf723f('ALSA: firewire-digi00x: add skeleton for Digi 002/003 family') Fixes: c0949b27('ALSA: firewire-tascam: add skeleton for TASCAM FireWire series') Reported-by:
Stefan Richter <stefanr@s5r6.in-berlin.de> Signed-off-by:
-
Takashi Sakamoto authored
In former commit, metering is supported for BeBoB based models customized by M-Audio. The data in transaction is aligned to big-endianness, while in the driver code u16 typed variable is assigned to the data. This causes sparse warnings. bebob_maudio.c:651:31: warning: cast to restricted __be16 bebob_maudio.c:651:31: warning: cast to restricted __be16 bebob_maudio.c:651:31: warning: cast to restricted __be16 bebob_maudio.c:651:31: warning: cast to restricted __be16 This commit fixes this bug by using __be16 variable for the data. Fixes: 3149ac48('ALSA: bebob: Add support for M-Audio special Firewire series') Signed-off-by:
-
Takashi Sakamoto authored
In former commit, snd_efw_command_get_phys_meters() was added to handle metering data. The given buffer is used to save transaction result and to convert between endianness. But this causes sparse warnings. fireworks_command.c:269:25: warning: incorrect type in argument 1 (different base types) fireworks_command.c:269:25: expected unsigned int [usertype] *p fireworks_command.c:269:25: got restricted __be32 [usertype] * This commit fixes this bug. Fixes: bde8a8f2('ALSA: fireworks: Add transaction and some commands') Signed-off-by:
-
Takashi Sakamoto authored
In former commit, u32 data was assigned to __be32 variable instead of an int variable. This is not enough solution because it still causes sparse warnings. dice.c:80:23: warning: incorrect type in assignment (different base types) dice.c:80:23: expected restricted __be32 [usertype] value dice.c:80:23: got unsigned int dice.c:81:21: warning: restricted __be32 degrades to integer dice.c:81:46: warning: restricted __be32 degrades to integer This commit fixes this bug. Fixes: 7c2d4c0c('ALSA: dice: Split transaction functionality into a file') Signed-off-by:
-
Takashi Sakamoto authored
Some local variables in some functions are typed as unsigned int, while __be32 value is assigned to them. This causes sparse warnings. dice-stream.c:50:17: warning: incorrect type in assignment (different base types) dice-stream.c:50:17: expected unsigned int [unsigned] channel dice-stream.c:50:17: got restricted __be32 [usertype] <noident> dice-stream.c:74:17: warning: incorrect type in assignment (different base types) dice-stream.c:74:17: expected unsigned int [unsigned] channel dice-stream.c:74:17: got restricted __be32 [usertype] <noident> This commit fixes this bug. Fixes: 288a8d0c('ALSA: dice: Change the way to start stream') Signed-off-by:
-
- 18 Oct, 2015 2 commits
-
-
Takashi Sakamoto authored
A former commit moves oxfw-related codes to a sub-directory, while it forgot to remove an entry from Makefile in parent directory. Fixes: 1a4e39c2('ALSA: oxfw: Move to its own directory') Signed-off-by:
-
Takashi Sakamoto authored
When committed to upstream, these four modules had wrong entries for Makefile. This forces them to be loadable modules even if they're set as built-in. This commit fixes this bug. Fixes: b5b04336('ALSA: fireworks: Add skelton for Fireworks based devices') Fixes: fd6f4b0d('ALSA: bebob: Add skelton for BeBoB based devices') Fixes: 1a4e39c2('ALSA: oxfw: Move to its own directory') Fixes: 14ff6a09('ALSA: dice: Move file to its own directory') Signed-off-by:
-
- 17 Oct, 2015 5 commits
-
-
Takashi Iwai authored
It's totally outdated. We need a revised version later, maybe better integrated into kernel doc. Signed-off-by: -
Takashi Iwai authored
It was forgotten to be removed. Signed-off-by: -
Takashi Iwai authored
The recent commit [7fbe824a: ALSA: hda - Update mixer name for the lower codec address] tried to improve the mixer chip name assignment in the order of codec address. However, this fix was utterly bogus; it checks the field set in each codec, thus this value is reset at each codec creation, of course. For really handling this priority, the assignment has to be remembered in the common place, namely in hda_bus, instead of hda_codec. Fixes: 7fbe824a ('ALSA: hda - Update mixer name for the lower codec address') Signed-off-by:
-
Dan Carpenter authored
My static checker complains because tscm->spec->midi_capture_ports is either 2 or 4 but the tscm->tx_midi_substreams[] array has 4 elements so this is possibly off by one. I have looked at the code and I think it should be >= instead of > as well. Fixes: 107cc012 ('ALSA: firewire-tascam: add support for incoming MIDI messages by asynchronous transaction') Signed-off-by:
-
Dan Carpenter authored
We recently tried to add some new code to support turning the LED on and off but the code in snd_tscm_transaction_reregister() is unreachable. Fixes: e65e2cb9 ('ALSA: firewire-tascam: Turn on/off FireWire LED') Signed-off-by:
-
- 16 Oct, 2015 2 commits
-
-
Jie Yang authored
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:
Jie Yang <yang.jie@intel.com> Signed-off-by:
-
Ricard Wanderlof authored
The Nocturn needs the MIDI_RAW_BYTES quirk, like other Novation devices. Tested that the Nocturn shows up in aconnect, and that it can be used as a control surface (using the xtor synthesizer patch editor). Signed-off-by:
-
- 15 Oct, 2015 1 commit
-
-
Takashi Iwai authored
In most cases, we prefer the onboard codec as the primary device, thus it's better to set it as the mixer name. Currently, however, the mixer name is updated per the device instantiation order, and user gets often HDMI/DP or other seen as a mixer chip name. Also, if a codec name is renamed by the driver, the old chip name might be left still as the mixer name. This patch addresses these issues by remembering the chip address that was referred as the mixer name. When a codec with the same or lower address gives its name, renew the mixer name accordingly, as it's either the update of the codec name or we get likely the more appropriate chip as the reference. Signed-off-by:
-
