- 20 Oct, 2015 3 commits
-
-
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:
Vinod Koul <vinod.koul@intel.com> Tested-by:
Subhransu S Prusty <subhransu.s.prusty@intel.com> Signed-off-by:
Takashi Iwai <tiwai@suse.de>
-
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:
-
- 15 Oct, 2015 6 commits
-
-
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: -
Takashi Iwai authored
A few multiple codec drivers do renaming the chip_name string but all these are open-coded and some of them have even no error check. Let's make common helpers to do it properly. Signed-off-by: -
Takashi Iwai authored
Cirrus codecs have also fine power controls on each widget, thus it gets benefit from the recent widget power-saving feature. As we haven't seen any obvious regressions with tests on some MacBooks, let's try to enable it. Signed-off-by: -
Mikko Rapeli authored
Kernel headers should use linux/types.h based definitions. Signed-off-by:
Mikko Rapeli <mikko.rapeli@iki.fi> Signed-off-by:
-
Mikko Rapeli authored
Fixes userspace compilation error: error: expected specifier-qualifier-list before ‘DECLARE_BITMAP’ DECLARE_BITMAP(gpr_valid, 0x200); /* bitmask of valid initializers */ DECLARE_BITMAP macro is not meant for userspace headers and thus added here as private copy for emu10k.h. Fix was suggested by Arnd Bergmann <arnd@arndb.de> in message <2168807.4Yxh5gl11Q@wuerfel> and Takashi Iwai <tiwai@suse.de> in message <s5h1thx88tk.wl-tiwai@suse.de> on lkml. Signed-off-by:
-
Dan Carpenter authored
We cap the upper bound of "idx" but not the negative side. Let's make it unsigned to fix this. Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
- 13 Oct, 2015 4 commits
-
-
Ricard Wanderlof authored
Rounding must take place before multiplication with the frame size, since each packet contains a whole number of frames. We must also properly consider the data interval, as a larger data interval will result in larger packets, which, depending on the sampling frequency, can result in packet sizes that are less than integral multiples of the packet size for a lower data interval. Detailed explanation and rationale: The code before this commit had the following expression on line 613 to calculate the maximum isochronous packet size: maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3)) >> (16 - ep->datainterval); Here, ep->freqmax is the maximum assumed sample frequency, calculated from the nominal sample frequency plus 25%. It is ultimately derived from ep->freqn, which is in the units of frames per packet, from get_usb_full_speed_rate() or usb_high_speed_rate(), as applicable, in Q16.16 format. The expression essentially adds the Q16.16 equivalent of 0.999... (i.e. the largest number less than one) to the sample rate, in order to get a rate whose integer part is rounded up from the fractional value. The multiplication with (frame_bits >> 3) yields the number of bytes in a packet, and the (16 >> ep->datainterval) then converts it from Q16.16 back to an integer, taking into consideration the bDataInterval field of the endpoint descriptor (which describes how often isochronous packets are transmitted relative to the (micro)frame rate (125us or 1ms, for USB high speed and full speed, respectively)). For this discussion we will initially assume a bDataInterval of 0, so the second line of the expression just converts the Q16.16 value to an integer. In order to illustrate the problem, we will set frame_bits 64, which corresponds to a frame size of 8 bytes. The problem here is twofold. First, the rounding operation consists of the addition of 0x0.ffff and subsequent conversion to integer, but as the expression stands, the conversion to integer is done after multiplication with the frame size, rather than before. This results in the resulting maxsize becoming too large. Let's take an example. We have a sample rate of 96 kHz, so our ep->freqn is 0xc0000 (see usb_high_speed_rate()). Add 25% (line 612) and we get 0xf0000. The calculated maxsize is then ((0xf0000 + 0x0ffff) * 8) >> 16 = 127 . However, if we do the number of bytes calculation in a less obscure way it's more apparent what the true corresponding packet size is: we get ceil(96000 * 1.25 / 8000) * 8 = 120, where 1.25 is the 25% from line 612, and the 8000 is the number of isochronous packets per second on a high speed USB connection (125 us microframe interval). This is fixed by performing the complete rounding operation prior to multiplication with the frame rate. The second problem is that when considering the ep->datainterval, this must be done before rounding, in order to take the advantage of the fact that if the number of bytes per packet is not an integer, the resulting rounded-up integer is not necessarily a factor of two when the data interval is increased by the same factor. For instance, assuming a freqency of 41 kHz, the resulting bytes-per-packet value for USB high speed is 41 kHz / 8000 = 5.125, or 0x52000 in Q16.16 format. With a data interval of 1 (ep->datainterval = 0), this means that 6 frames per packet are needed, whereas with a data interval of 2 we need 10.25, i.e. 11 frames needed. Rephrasing the maxsize expression to: maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) * (frame_bits >> 3); for the above 96 kHz example we instead get ((0xf0000 + 0xffff) >> 16) * 8 = 120 which is the correct value. We can also do the calculation with a non-integer sample rate which is when rounding comes into effect: say we have 44.1 kHz (resulting ep->freqn = 0x58333, and resulting ep->freqmax 0x58333 * 1.25 = 0x6e3ff (rounded down)): Original maxsize = ((0x6e3ff + 0xffff) * 8) << 16 = 63 (63.124.. rounded down) True maxsize = ceil(44100 * 1.25 / 8000) * 8 = 7 * 8 = 56 New maxsize = ((0x6e3ff + 0xffff) >> 16) * 8 = 7 * 8 = 56 This is also corroborated by the wMaxPacketSize check on line 616. Assume that wMaxPacketSize = 104, with ep->maxpacksize then having the same value. As 104 < 127, we get maxsize = 104. ep->freqmax is then recalculated to (104 / 8) << 16 = 0xd0000 . Putting that rate into the original maxsize calculation yields a maxsize of ((0xd0000 + 0xffff) * 8) >> 16 = 111 (with decimals 111.99988). Clearly, we should get back the 104 here, which we would with the new expression: ((0xd0000 + 0xffff) >> 16) * 8 = 104 . (The error has not been a problem because it only results in maxsize being a bit too big which just wastes a couple of bytes, either as a result of the first maxsize calculation, or because the resulting calculation will hit the wMaxPacketSize value before the packet is too big, resulting in fixing the size to wMaxPacketSize even though the packet is actually not too long.) Tested with an Edirol UA-5 both at 44.1 kHz and 96 kHz. Signed-off-by:
Ricard Wanderlof <ricardw@axis.com> Signed-off-by:
-
Takashi Iwai authored
-
David Henningsson authored
Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo mic input where one channel has reverse polarity. Alsa-info available at: https://launchpadlibrarian.net/220846272/AlsaInfo.txt Cc: stable@vger.kernel.org BugLink: https://bugs.launchpad.net/bugs/1504778Signed-off-by:
David Henningsson <david.henningsson@canonical.com> Signed-off-by:
-
Vinod Koul authored
Compiling the hdac extended core on arm fails with below error: sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_writel': >> sound/hda/ext/hdac_ext_bus.c:29:2: error: implicit declaration of >> function +'writel' [-Werror=implicit-function-declaration] writel(value, addr); ^ sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_readl': >> sound/hda/ext/hdac_ext_bus.c:34:2: error: implicit declaration of >> function +'readl' [-Werror=implicit-function-declaration] return readl(addr); This is fixed by explicitly including io.h Fixes: 99463b3a - ('ALSA: hda: provide default bus io ops extended hdac') Reported-by:kbuild test robot <lkp@intel.com> Suggested-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
- 12 Oct, 2015 5 commits
-
-
Takashi Sakamoto authored
Currently, this driver picks up model name with be32_to_cpu() macro to align characters. This is wrong operation because the result is different depending on CPU endiannness. Additionally, vendor released several versions of firmware for this series. It's not better to assign model-dependent information to device entry according to the version field. This commit fixes these bugs. The name of model is picked up correctly and used to identify model-dependent information. Cc: Stefan Richter <stefanr@s5r6.in-berlin.de> Fixes: c0949b27 ('ALSA: firewire-tascam: add skeleton for TASCAM FireWire series') Signed-off-by:
Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by:
-
Takashi Sakamoto authored
TASCAM FireWire series has some LEDs on its surface. These LEDs can be turned on/off by receiving asynchronous transactions to a certain address. One of the LEDs is labels as 'FireWire'. It's better to light it up when this driver starts to work. Besides, the LED for 'FireWire' is turned off at bus reset. This commit implements this idea. Signed-off-by:
-
Takashi Sakamoto authored
In former commits, this driver got functionalities to transfer/receive MIDI messages to/from TASCAM FireWire series. This commit adds some ALSA MIDI ports to enable userspace applications to use the functionalities. I note that this commit doesn't support virtual MIDI ports which console models support. A physical controls can be assigned to a certain MIDI ports including physical and virtual. But the way is not clear. Signed-off-by:
-
Takashi Sakamoto authored
TASCAM FireWire series use asynchronous transaction to receive MIDI messages. The transaction should be sent to a certain address. This commit supports the outgoing MIDI messages. The messages in the transaction includes some quirks: * One MIDI message is transferred in one quadlet transaction, except for system exclusives. * MIDI running status is not allowed, thus transactions always include status byte. * The basic data format is the same as transferring MIDI messages supported in previous commit. Signed-off-by:
-
Takashi Sakamoto authored
TASCAM FireWire series use asynchronous transaction to transfer MIDI messages. The transaction is sent to a registered address. This commit supports the incoming MIDI messages. The messages in the transaction include some quirks: * Two quadlets are used for one MIDI message and one timestamp. * Usually, the first byte of the first quadlet includes MIDI port and MSB 4 bit of MIDI status. For system exclusive message, the first byte includes MIDI port and 0x04, or 0x07 in the end of the message. * The rest of the first quadlet includes MIDI bytes up to 3. * Several set of MIDI messages and timestamp can be transferred in one block transaction, up to 8 sets. I note that TASCAM FireWire series ignores ID bytes of system exclusive message. When receiving system exclusive messages with ID bytes on physical MIDI bus, the series transfers the messages without ID bytes on IEEE 1394 bus, and vice versa. Signed-off-by:
-
- 11 Oct, 2015 9 commits
-
-
Takashi Sakamoto authored
In former commits, asynchronous transactions are supported for physical controls. This commit adds a pair of MIDI ports for them. This driver already adds diferrent number of ALSA MIDI ports for physical MIDI ports, and the number of in/out ports are different. As seeing as 'amidi' program in alsa-utils package, a pair of in/out MIDI ports is expected with the same name. Therefore, this commit adds a pair of new ports to the first. Signed-off-by:
-
Takashi Sakamoto authored
ALSA: firewire-digi00x: add support of asynchronous transaction for outgoing MIDI messages to physical controls In previous commit, asynchronous transaction for incoming MIDI messages from physical controls is supported. The physical controls may be controlled by receiving MIDI messages at a certain address. This commit supports asynchronous transaction for this purpose. Signed-off-by:
-
Takashi Sakamoto authored
ALSA: firewire-digi00x: add support of asynchronous transaction for incoming MIDI messages from physical controls Digi 00x series has two types of model; rack and console. The console models have physical controls. The model can transmit control messages. These control messages are transferred by asynchronous transactions to registered address. This commit supports the asynchronous transaction. Signed-off-by:
-
Takashi Sakamoto authored
This commit adds MIDI functionality to capture/playback MIDI messages from/to physical MIDI ports. These messages are transferred in isochronous packets. When no substreams request AMDTP streams to run, this driver starts the streams at current sampling rate. When other substreams start at different sampling rate, the streams are stopped temporarily, then start again at requested sampling rate. This operation can generate missing MIDI bytes, thus it's preferable to start PCM substreams at favorite sampling rate in advance. Digi 002/003 console also has a set of MIDI port for physical controls. These ports are added in later commits. Signed-off-by:
-
Takashi Sakamoto authored
In Digi 002/003 protocol, MIDI messages are transferred in the last data channel of data blocks. Although this data channel has a label of 0x80, it's not fully MIDI conformant data channel especially because the Counter field always zero independently of included MIDI bytes. The 4th byte of the data channel in LSB tells the number of included MIDI bytes. This byte also includes the number of MIDI port. Therefore, the data format in this data channel is: * 1st: 0x80 as label * 2nd: MIDI bytes * 3rd: 0 or MIDI bytes * 4th: the number of MIDI byte and the number of MIDI port This commit adds support of MIDI messages in data block processing layer. Like AM824 data format, this data channel has a capability to transfer more MIDI messages than the capability of phisical MIDI bus. Therefore, a throttle for data rate is required to prevent devices' internal buffer to overflow. Signed-off-by:
-
Takashi Sakamoto authored
Original code for 'DoubleOhThree' encoding was written with '__u8' type, while the type is usually used to export something to userspace. This commit replaces the type with 'u8'. Signed-off-by:
-
Keith A. Milner authored
This patch enables interrupt transfer mode for MIDI ports on newer Boss/Roland devices such as the GT-100/001 which support interrupt transfer on both IN and OUT MIDI endpoints. Previously this wasn't being enabled for these devices as the code was specifically looking for the scenario where the IN endpoint supported interrupt transfer and the OUT endpoint was bulk transfer. Newer devices support interrupt transfer for both endpoints. This has been tested on Boss devices GT-001, BR-80 and JS-8 and Roland VS-20. It would benefit from some regresison testing with other devices if possible. Signed-off-by:
Keith A. Milner <maillist@superlative.org> Signed-off-by:
-
Takashi Sakamoto authored
In firewire-lib, isochronous packet streaming is stopped when detecting wrong value for FMT field of CIP headers. Although this is appropriate to IEC 61883-1 and 6, some BeBoB based devices with vendors' customization use invalid value to FMT field of CIP headers in the beginning of streaming. $ journalctl snd-bebob fw1.0: Detect unexpected protocol: 01000000 8000ffff I got this log with M-Audio FireWire 1814. In this line, the value of FMT field is 0x00, while it should be 0x10 in usual AMDTP. Except for the beginning, these devices continue to transfer packets with valid value for FMT field, except for the beginning. Therefore, in this case, firewire-lib should continue to process packets. The former implementation of firewire-lib performs it. This commit loosens the handling of wrong value, to continue packet processing in the case. Fixes: 414ba022 ('ALSA: firewire-lib: add support arbitrary value for fmt/fdf fields in CIP header') Signed-off-by:
-
Julia Lawall authored
The structures of type snd_bebob_clock_spec, snd_bebob_rate_spec, snd_bebob_meter_spec, and snd_bebob_spec are never modified after they are initialized. Make them all const. Done with the help of Coccinelle. Signed-off-by:
Julia Lawall <Julia.Lawall@lip6.fr> Tested-by:
-
- 09 Oct, 2015 6 commits
-
-
Takashi Sakamoto authored
Currently, when asynchronous transactions finish in error state and retries, work scheduling and work running also continues. This should be canceled at fatal error because it can cause endless loop. This commit enables to cancel transferring MIDI messages when transactions encounter fatal errors. This is achieved by setting error state. Signed-off-by:
-
Takashi Sakamoto authored
Typically, the target devices have internal buffer to adjust output of received MIDI messages for MIDI serial bus, while the capacity of the buffer is limited. IEEE 1394 transactions can transfer more MIDI messages than MIDI serial bus can. This can cause buffer over flow in device side. This commit adds throttle to limit MIDI data rate by counting intervals between two MIDI messages. Usual MIDI messages consists of two or three bytes. This requires 1.302 to 1.953 mili-seconds interval between these messages. This commit uses kernel monotonic time service to calculate the time of next transaction. Signed-off-by:
-
Takashi Sakamoto authored
Currently, when two MIDI trigger callbacks can be called immediately, transactions for the second MIDI messages can be postpone till next trigger callback. This is not good for real-time message transmission. This commit schedules work again at response handling callback if the MIDI substream still includes untransferred MIDI messages. Signed-off-by:
-
Takashi Sakamoto authored
Currently, when waiting for a response, callers can start another transaction by scheduling another work. This is not good for error processing of transaction, especially the first response is too late. This commit serialize request/response transactions, by adding one boolean member to represent idling state. Signed-off-by:
-
Takashi Sakamoto authored
Some models receive MIDI messages via IEEE 1394 asynchronous transactions. In this case, MIDI messages are transferred in fixed-length payload. It's nice that firewire-lib module has common helper functions. This commit implements this idea. Each driver adds 'struct snd_fw_async_midi_port' in its instance structure. In probing, it should call snd_fw_async_midi_port_init() to initialize the structure with some parameters such as target address, the length of payload in a transaction and a pointer for callback function to fill the payload buffer. At 'struct snd_rawmidi_ops.trigger()' callback, it should call 'snd_fw_async_midi_port_run()' to start transactions. Each driver should ensure that the lifetime of MIDI substream continues till calling 'snd_fw_async_midi_port_finish()'. The helper functions support retries to transferring MIDI messages when transmission errors occur. When transactions are successful, the helper functions call 'snd_rawmidi_transmit_ack()' internally to consume MIDI bytes in the buffer. Therefore, Each driver is expected to use 'snd_rawmidi_transmit_peek()' to tell the number of bytes to transfer to return value of 'fill' callback. Signed-off-by:
-
Kosuke Tatsukawa authored
snd_seq_oss_readq_put_event() seems to be missing a memory barrier which might cause the waker to not notice the waiter and miss sending a wake_up as in the following figure. snd_seq_oss_readq_put_event snd_seq_oss_readq_wait ------------------------------------------------------------------------ /* wait_event_interruptible_timeout */ /* __wait_event_interruptible_timeout */ /* ___wait_event */ for (;;) { prepare_to_wait_event(&wq, &__wait, state); spin_lock_irqsave(&q->lock, flags); if (waitqueue_active(&q->midi_sleep)) /* The CPU might reorder the test for the waitqueue up here, before prior writes complete */ if ((q->qlen>0 || q->head==q->tail) ... __ret = schedule_timeout(__ret) if (q->qlen >= q->maxlen - 1) { memcpy(&q->q[q->tail], ev, sizeof(*ev)); q->tail = (q->tail + 1) % q->maxlen; q->qlen++; ------------------------------------------------------------------------ There are two other place in sound/core/seq/oss/ which have similar code. The attached patch removes the call to waitqueue_active() leaving just wake_up() behind. This fixes the problem because the call to spin_lock_irqsave() in wake_up() will be an ACQUIRE operation. I found this issue when I was looking through the linux source code for places calling waitqueue_active() before wake_up*(), but without preceding memory barriers, after sending a patch to fix a similar issue in drivers/tty/n_tty.c (Details about the original issue can be found here: https://lkml.org/lkml/2015/9/28/849). Signed-off-by:Kosuke Tatsukawa <tatsu@ab.jp.nec.com> Signed-off-by:
-
- 08 Oct, 2015 2 commits
-
-
Vinod Koul authored
Now that we have introduced the core fns we should make hda use these helpers Signed-off-by:
-
Subhransu S. Prusty authored
The current codec helpers are local to hda code and needs to be moved to core so that other users can use it. The helpers to read/write the codec and to check the power state of widgets is copied Signed-off-by:
-
- 07 Oct, 2015 3 commits
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v4.3-rc4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.3 Quite a few fixes here but they're all very small and driver specific, none of them really stand out if you aren't using the relevant hardware but they're all useful if you do happen to have an affected device.
-
Mark Brown authored
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/db1200', 'asoc/fix/dwc', 'asoc/fix/imx-ssi', 'asoc/fix/maintainers', 'asoc/fix/rt5645', 'asoc/fix/sgtl5000' and 'asoc/fix/tas2552' into asoc-linus
-
- 06 Oct, 2015 2 commits
-
-
Mark Brown authored
Neither myself or Liam is especially interested in this driver any more and the devices are already covered by the general ex-Wolfson entry so just remove this. Signed-off-by:
Liam Girdwood <liam.r.girdwood@linux.intel.com>
-
Andreas Dannenberg authored
The minimum volume level for the TAS2552 (control register value 0x00) is -7dB however the driver declares it as -0.07dB. Running amixer before the patch reports: dBscale-min=-0.07dB,step=1.00dB,mute=0 Running amixer with the patch applied reports: dBscale-min=-7.00dB,step=1.00dB,mute=0 Signed-off-by:
Andreas Dannenberg <dannenberg@ti.com> Signed-off-by:
-
