summaryrefslogtreecommitdiffstats
path: root/sound/firewire
AgeCommit message (Collapse)AuthorFilesLines
2016-03-28ALSA: dice: fix memory leak when unpluggingTakashi Sakamoto1-10/+4
When sound card is going to be released, dice private data is also released. Then all of data should be released. However, stream data is not released. This causes memory leak when unplugging dice unit. This commit fixes the bug. Fixes: 4bdc495c87b3('ALSA: dice: handle several PCM substreams when any isochronous streams are available') Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-03-10ALSA: dice: use structure to represent register parameters instead of array ↵Takashi Sakamoto1-56/+54
with basic type element In dice interface, two blocks of register are accessible via IEEE 1394 asynchronous transaction to represent the number of supported isochronous streams and the number of quadlets for stream information. Current ALSA dice driver uses array with 'unsigned int' element for temporary cache of these information. But using structure is preferable for begin easily comprehensible. This commit applies a local structure for this aim. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-03-09ALSA: dice: force to add two pcm devices for listed modelsTakashi Sakamoto3-9/+58
Some models reduce the number of available isochronous streams for higher sampling transfer frequency. Such models bring an issue about how to add PCM substreams. When at lower sampling transfer frequency, the models reports whole available streams, thus this driver can add enough number of PCM substreams at probing time. On the other hand, at higher sampling transfer frequency, this driver can just add reduced number of PCM substreams. After probed, even if the sampling transfer frequency is changed to lower rate, fewer PCM substreams are actually available. This is inconvenience. For the reason, this commit adds a list so that this driver assume models on the list to have two pairs of PCM substreams. This list keeps the name of model in which the number of available streams differs depending on sampling transfer frequency. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-03-09ALSA: dice: handle several PCM substreams when any isochronous streams are ↵Takashi Sakamoto1-46/+75
available In former commits, ALSA dice driver can handle available isochronous streams. This commit adds support for several PCM substreams on the streams. The additional PCM substreams are available via another ALSA PCM character devices so that one ALSA PCM application can handle them without cumbersome operations. For example, two PCM substreams are available on each stream, two ALSA character devices are added for them. In configuration space of alsa-lib, it's represented with 'hw:0,0' and 'hw:0,1'. The PCM substreams are constraint to parameters of the corresponding streams. If the PCM substreams are unavailable for some reasons, open(2) to ALSA PCM character device returns error and reports ENXIO. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-03-09ALSA: dice: handle whole available isochronous streamsTakashi Sakamoto1-143/+255
This commit enables ALSA dice driver to handle whole available streams. In Dice, certain registers represent the number of available streams at current sampling transfer frequency for both directions. The parameters of each stream are represented in a block of register. This block is aligned sequentially. These streams start simultaneously by writing enable bit to a register. This commit operates these registers when starting/stopping streams. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-03-09ALSA: dice: have two sets of isochronous resources/streamsTakashi Sakamoto4-48/+79
Currently ALSA dice driver handles a pair of isochronous resources for IEC 61883-1/6 packet streaming. While, according to some documents about ASICs named as 'Dice', several isochronous streams are available. Here, I start to describe ASICs produced under 'Dice' name. * Dice II (designed by wavefront semiconductor, including TCAT's IP) * STD (with limited functionality of DTCP) * CP (with full functionality of DTCP) * TCD2210/2210-E (so-called 'Dice Mini') * TCD2220/2220-E (so-called 'Dice Jr.') * TCD3070-CH (so-called 'Dice III') Some documents are public and we can see hardware design of them. We can find some articles about hardware internal register definitions (not registers exported to IEEE 1394 bus). * DICE II User Guide * http://www.tctechnologies.tc/archive/downloads/dice_ii_user_guide.pdf * 6.1 AVS Audio Receivers * Table 6.1: AVS Audio Receiver Memory Map * ARX1-ARX4 * 6.2 AVS Audio Transmitters * Table 6.2: AVS Audio Transmitter Memory Map * ATX1, ATX2 * TCD22xx User Guide * http://www.tctechnologies.tc/downloads/tcd22xx_user_guide.pdf * 6.1 AVS Audio Receivers * Table 66: AVS Audio Receiver Memory Map * ARX1, ARX2 * 6/2 AVS Audio Transmitters * Table 67: AVS Audio Transmitter Memory Map * ATX1, ATX2 * DICE III * http://www.tctechnologies.tc/downloads/TCD3070-CH.pdf * Dual stream 63 channel transmitter/receiver For Dice II and TCD22xx series, maximum 16 data channels are transferred in an AMDTP packet, while for Dice III, maximum 32 data channels are transferred. According to the design of the series of these ASICs, this commit allows this driver to handle additional set of isochronous resources. For practical reason, two pair of isochronous resources are added. As of this commit, this driver still use a pair of the first isochronous resources. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-28ALSA: dice: drop duplex streams synchronization to transfer own time stampsTakashi Sakamoto1-40/+2
This commit drops implementation of duplex streams synchronization from ALSA dice driver, due to a reason of hardware design. This patch allows dice-based units to generate sounds correctly when isochronous packet streaming starts at first time. In IEC 61883-6:2005, CIP packetization layer for AM824 data format utilizes the value of SYT field in CIP header of received packet for a reference to phase lock loop. Figure 3 in clause 4.3 describes it. The value is an offset from cycle_time field of every cycle start packet from cycle master on IEEE 1394 bus. The time calculated with these two fields is called as 'presentation timestamp' which represents the time to play data included in the packet. Although, this idea includes some problems due to accuracy of timekeep in cycle master, accuracy of transmission of cycle start packet on the bus with the other units, accuracy of sampling clock in data transmitter side and accuracy of replay in data receiver side. In most case, these accuracies somewhat worse because there's no such ideal hardwares in this world. For the issues, ASICs for Dice include Jitter Elimination Technologies (JET) PLL. The PLL can handle several sources of clock and compensate it with high-precision internal clock source. The sequence of value in syt field of received AMDTP packets is one of the sources, therefore transmitters on IEEE 1394 bus should transfer it. On the other hand, current ALSA dice driver is programmed with a mode of duplex streams with synchronization. In this mode, the driver outputs packets after some incoming packets are handled, to re-use the value of SYT field in incoming packets to the value for outgoing packets. This mode is enabled when source signal of sampling clock is set to internal, and this is a major use case. Thus, in most cases, the unit receives no packets during a short time after packet streaming starts. As long as I experienced, this causes the units to generate no sounds at first time to receive packets. This issue occurs only with Dice II. I guess this is due to a quirk of the PLL. In short, the PLL cannot generate firm signals to ADCs/DACs or the other ICs when no packets are received in the beginning of packet streaming. While, on second time or later, the unit generates sound correctly. I guess that starting packet streaming at first time sets the PLL correctly. Well, still based on my hypothesis and no way to prove it, this commit drops duplex streams synchronization from this driver. At least, the PLL requires the sequence of value in SYT field of received AMDTP packets as one of source of clock signals with internal clock source. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-24ALSA: oxfw: discontinue MIDI substream for scs1x at transaction failureTakashi Sakamoto1-3/+10
With a previous commit, ALSA oxfw driver retries transferring MIDI messages at transaction failure for scs1x. On the other hand, there're fatal transaction error. Then, no MIDI messages reach to the unit anymore. In this case, MIDI substream should be terminated. This commit stops MIDI transmission after the fatal error occurs. Unfortunately, unlike ALSA PCM functionality, ALSA rawmidi core has no feature to discontinue MIDI substream runtime in kernel side, thus this commit just stops MIDI transmission without notifying it to userspace. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-24ALSA: oxfw: retry MIDI transferring for scs1x at transaction failureTakashi Sakamoto1-3/+11
Currently, ALSA oxfw driver has a TODO to retry MIDI transferring at transaction failure. This commit achieves it. Current implementation uses snd_rawmidi_transmit() to transfer messages, thus the target MIDI messages are not in buffer when transaction failure is detected. Although we cannot use a pair of snd_rawmidi_transmit_peek() and snd_ramwidi_transmit_ack(), the messages are still in scs1x specific structure and the data is available for retries. This commit adds a member to the structure for the length of buffered messages, and uses the value again at retries. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-20ALSA: fireworks: serialize transactions to update connections at bus resetTakashi Sakamoto2-4/+5
In IEC 61883-1, at bus-reset, applications can continue isochronous streaming by updating connections. In ALSA fireworks driver, the operation is executed in 'update' handler for bus driver. The connection resources are also changed in process contexts of PCM/MIDI applications. Therefore, bus-reset handling has race condition against connection. Current ALSA fireworks driver has a bug for the condition. This commit fixes the bug, by expand critical section with mutex. As a result, connection updating operation in bus-reset handler and connection changing operation in process context are serialized. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-20ALSA: bebob: give up updating streams at bus reset handlerTakashi Sakamoto3-20/+16
DM1000/DM1100/DM1500 chipsets transfer packets with discontinue value in 'dbc' field of CIP header. For ALSA bebob driver, this makes its bus-reset handler meaningless, because the discontinuity is detected quite earlier than executing the handler. This commit gives up updating streams at the bus reset handler. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-20ALSA: bebob: change type of substream counter from atomic_t to unsigned intTakashi Sakamoto4-11/+11
The counter is incremented/decremented in critical section protected with mutex. Therefore, no need to use atomic_t. This commit changes the type to unsigned int. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-20ALSA: bebob: move mutex from function callee to callersTakashi Sakamoto3-11/+24
Currently, critical section is protected by mutex in functions of fireworks_stream.c. Callers increments/decrements substreams counter before calling the functions. Moving mutex to the callers code allows to change type of the substream counter from atomic_t to unsigned int. This commit is a preparation for obsoleting usage of atomic_t for substream counter. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-20ALSA: bebob: simplify bus-reset handlingTakashi Sakamoto3-36/+5
At bus-reset, DM1000/DM1100/DM1500 chipsets transfer packets with discontinuous value in 'dbc' field of CIP header. In this case, packet streaming layer in firewire-lib module stops streaming and set XRUN to PCM substream. In ALSA, PCM applications are notified the XRUN status by the return value of ALSA PCM interface. They can recover this state by executing snd_pcm_prepare(), then PCM drivers' prepare handler is called, and start new PCM substream. For ALSA BeBoB driver, the handler establishes new connections and start new AMDTP streaming. Unfortunately, neither the PCM applications nor the driver know the reason of XRUN. The driver gets to know the reason when update handler is called by IEEE 1394 bus driver. As long as I tested, the order of below events are not fixed: * Detecting packet discontinuity in tasklet context of OHCI 1394 driver * Calling prepare handler in process context of ALSA PCM application * Calling update handler in kthread context of IEEE 1394 bus driver The unpredictable order is disadvantage for the driver to be compliant to CMP. In IEC 61883-1, new CMP establish operations should be done 1 sec (isoc_resource_delay) after bus-reset. Within 1 sec, CMP restore operations are allowed. For this reason, in former commit ('b6bc812327aa: ALSA: bebob/firewire-lib: Add a quirk for discontinuity at bus reset'), the process context is forced to wait for executing update handler. The process context wait for bus-reset up to 1 sec. This commit solves the issue, while causes more disadvantages. For PCM applications, calling snd_pcm_prepare() for recovering XRUN state takes more time and the driver got a bit complicated code, while the recovery is not always successful. As long as I tested, DM1000/DM1100/DM1500 and BeBoB firmware can allow drivers to establish new connections just after bus reset. Furthermore, any FCP transactions are handled correctly. Therefore, the driver don't need to wait for bus reset handler for starting new streaming. This commit removes the codes to reduce maintenance cost. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-18ALSA: oxfw: use workqueue instead of tasklet for scs1xTakashi Sakamoto1-6/+6
This commit replaces tasklet with workqueue for scs1x functionality of ALSA oxfw driver. This driver transfers MIDI message specific for SCS.1m and SCS.1d. This task is currently done in software IRQ context of tasklet. In a view of system, this context is limited resources and some important drivers (at least, more important than ALSA oxfw driver) use the context as its bottom-harf. If the work to transfer MIDI messages is done within a time, it's better to use the other context for the work. Actually, with recent CPUs, the work will be scheduled within a time. This is a reason of this commit. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-12ALSA: dice: old firmware optimization for Dice notificationTakashi Sakamoto1-3/+14
As long as I tested, Dice-based models produced by TC Electronic with factory-configured settings transfer no notification within ensure_phase_lock(). On the other hand, with upgraded firmwares, it starts to transfer the notification. This seems to be a quirk of earlier firmwares. This commit ensures phase lock by reading a register after waiting for the notification. Even if it's timed-out, ensure_phase_lock() return success as long as the register has expected clock status. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-12ALSA: dice: change notification mask to detect lock status changeTakashi Sakamoto1-1/+1
With former patchset, ALSA dice driver doesn't change clock parameters anymore, while the driver still touch clock configuration for phase lock. Although the locking status is in Dice notification, the driver doesn't detect it. Usually, this causes no issues because in most case NOTIFY_LOCK_CHG notification transfers after NOTIFY_CLOCK_ACCEPTED notification, while it's better to detect locking status. This commit changes notification mask just to detect lock status change. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-09Merge branch 'for-linus' into for-nextTakashi Iwai4-8/+16
2016-02-09ALSA: dice: ensure phase lock before starting streamingTakashi Sakamoto3-57/+32
In former commits, probing process has no need to set sampling transfer frequency. Although it's OK to drop a function to change the frequency from this module, some models require it before streaming. This seems to be due to phase lock of clock source. This commit moves the function from transaction layer to stream layer, and rename it according to the purpose. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-09ALSA: dice: purge generating channel cacheTakashi Sakamoto3-93/+5
Dice interface design doesn't allow drivers to read supported combination between sampling transfer frequencies and the number of Multi bit linear audio data channels. Due to the design, ALSA dice driver changes current sampling transfer frequency to generate cache of the combinations at device probing processing. Although, this idea is worse because ALSA dice driver changes the state of clock. This is not what users want when they save favorite configuration to the device in advance. Furthermore, there's a possibility that the format of data block is decided not only according to current sampling transfer frequency, but also the other factors, i.e. data format for digital interface. It's not good to generate channel cache according to the sampling transfer frequency only. This commit purges processing cache data and related structure members. As a result, users must set preferable sampling transfer frequency before using ALSA PCM applications, as long as they want to start any PCM substreams at the rate except for current one. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-09ALSA: dice: get the number of MBLA data channel at opening PCM substreamTakashi Sakamoto1-8/+21
This commit is a preparation to remove members related to channel cache for the number of channels for multi bit linear audio data and MIDI ports. This commit changes the way to get the number of multi bit linear audio data channel. It's directly retrieved by asynchronous transactions to some registers. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-09ALSA: dice: add MIDI ports according to current number of MIDI substreamsTakashi Sakamoto1-6/+17
This commit changes the way to add ALSA MIDI ports. This driver read the number of multiplexed MIDI substreams from hardware register, then adds the same number of ALSA MIDI ports. This commit is based on my assumption that the number is fixed at all of supported sampling transfer frequency. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-09ALSA: dice: limit stream to current sampling transfer frequency.Takashi Sakamoto1-6/+15
In previous commit, ALSA Dice driver limits PCM substreams at current sampling transfer frequency and current number of Multi bit linear audio data channel. Thus, the driver has no need to start AMDTP streams at the other sampling transfer frequency except for current one. This is due to Dice interface design. This commit limits AMDTP stream at current sampling transfer frequency, according to the design. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-09ALSA: dice: limit to current sampling transfer frequencyTakashi Sakamoto1-139/+31
ALSA PCM core has a functionality for rule of PCM substream parameters. Typically, when userspace opens PCM character devices, each driver adds its own rules to PCM substream according to design of hardware. When the userspace executes hw_params ioctl with favorite parameters, the actual parameters are calculated according to the rules and the given parameters. Then, the result is returned to userspace. Currently, ALSA Dice driver has the rule between channels and rates, while Dice interface design doesn't allow drivers to retrieve all of the combinations. Dice drivers are just allowed to get current sampling transfer frequency and the number of multi bit linear audio data channels in an data block of an AMDTP packet. This commit purges the rule, and limit PCM substreams to current sampling transfer frequency, following to the interface design. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-09ALSA: firewire-digi00x: Drop bogus const type qualifier on dot_scrt()Geert Uytterhoeven1-1/+1
sound/firewire/digi00x/amdtp-dot.c:67: warning: type qualifiers ignored on function return type Drop the bogus "const" type qualifier on the return type of dot_scrt() to fix this. Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-05ALSA: firewire-tascam: remove needless member for control and status messageTakashi Sakamoto1-3/+0
Commit 3beab0f844fa added a member for control and status message, while it's planned and not implemented yet. This commit removes it. Fixes: 3beab0f844fa('ALSA: firewire-tascam: add support for outgoing MIDI messages by asynchronous transaction') Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-05ALSA: firewire-tascam: remove a flag for controllerTakashi Sakamoto2-4/+0
Currently, 'struct snd_tscm_spec' has a member named as 'is_controller' to identify MIDI controller. This member was originally added to skip parse control and status messages in isochronous packets for non-controller model. As long as I investigate, FW-1804 (non-controller) also transfers the control and status message, thus it becomes meaningless. This commit removes it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-05ALSA: firewire-tascam: add support for FW-1804Takashi Sakamoto1-1/+10
This model supports: * maximum 12 PCM channels for PCM playback * maximum 18 PCM channels for PCM capture * 4 ports for MIDI playback * 4 ports for MIDI capture * control and status messages in tx isochronous packets * up to 96.0 kHz This commit adds support for the model. As the other supported models, all of available PCM channels are always enabled. As I described in commit c0949b278515da94, Ilya Zimnovich had investigated TASCAM FireWire series in 2011 with his FW-1804. In his report, this model has internal multiplexer and any software implementation can control it. Following to the design of ALSA firewire stack, this commit won't implement it. It should be in userspace via Linux fw character device. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-02-05ALSA: firewire-tascam: fix NULL pointer dereference when model ↵Takashi Sakamoto1-0/+6
identification fails When unsupported models are connected, snd-firewire-tascam module causes NULL pointer dereference in fw_core_remove_address_handler() (due to list_del_rcu()). This commit prevents this bug. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-01-26ALSA: bebob: Use a signed return type for get_formation_indexLucas Tanure1-5/+9
The return type "unsigned int" was used by the get_formation_index function despite of the aspect that it will eventually return a negative error code. So, change to signed int and get index by reference in the parameters. Done with the help of Coccinelle. [Fix the missing braces suggested by Julia Lawall -- tiwai] Signed-off-by: Lucas Tanure <tanure@linux.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-01-06ALSA: dice: expand timeout to wait for Dice notificationTakashi Sakamoto1-1/+1
Some users have reported that their Dice based models generate ETIMEDOUT when starting PCM playback. It means that current timeout (=100msec) is not enough for their models to transfer notifications. This commit expands the timeout up to 2 sec. As a result, in a worst case, any operations to start AMDTP streams takes 2 sec or more. Then, in userspace, snd_pcm_hw_params(), snd_pcm_prepare(), snd_pcm_recover(), snd_rawmidi_open(), snd_seq_connect_from() and snd_seq_connect_to() may take the time. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-01-06ALSA: dice: purge transaction initialization at timeout of Dice notificationTakashi Sakamoto1-23/+8
In previous commit, card registration is processed under situation with few bus reset. There's no need to add a workaround of transaction re-initialization at timeout. This commit purges the re-initialization. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-01-06ALSA: dice: postpone card registrationTakashi Sakamoto2-45/+117
Some models based on ASIC for Dice II series (STD, CP) change their hardware configurations after appearing on IEEE 1394 bus. This is due to interactions of boot loader (RedBoot), firmwares (eCos) and vendor's configurations. This causes current ALSA dice driver to get wrong information about the hardware's capability because its probe function runs just after detecting unit of the model. As long as I investigated, it takes a bit time (less than 1 second) to load the firmware after bootstrap. Just after loaded, the driver can get information about the unit. Then the hardware is initialized according to vendor's configurations. After, the got information becomes wrong. Between bootstrap, firmware loading and post configuration, some bus resets are observed. This commit offloads most processing of probe function into workqueue and schedules the workqueue after successive bus resets. This has an effect to get correct hardware information and avoid involvement to bus reset storm. For code simplicity, this change effects all of Dice-based models, i.e. Dice II, Dice Jr., Dice Mini and Dice III. I use a loose strategy to manage a race condition between the work and the bus reset. This is due to a specification of dice transaction. When bus reset occurs, registered address for the transaction is cleared. Drivers must re-register their own address again. While, this operation is required for the work because the work includes to wait for the transaction. This commit uses no lock primitives for the race condition. Instead, checking 'registered' member of 'struct snd_dice' avoid executing the work again. If sound card is not registered, the work can be scheduled again by bus reset handler. When .remove callback is executed, the sound card is going to be released. The work should not be pending or executed in the releasing. This commit uses cancel_delayed_work_sync() in .remove callback and wait till the pending work finished. After .remove callback, .update callback is not executed, therefore no works are scheduled again. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2016-01-06ALSA: dice: split subaddress check from category checkTakashi Sakamoto2-84/+78
Before allocating an instance of sound card, ALSA dice driver checks chip_ID_hi in Bus information block of Config ROM, then also checks subaddresses. The former operation reads cache of Config ROM in Linux FireWire subsystem, while the latter operation sends read transaction. The latter can be merged into initialization of transaction system. This commit splits these two operations to reduce needless transactions in probe processing. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: add stream format quirk for SCS.1 modelsTakashi Sakamoto1-1/+9
As long as I investigate SCS.1m, this model reports to transfer/receive PCM data channels/MIDI conformant data channels in tx/rx AMDTP packet. There's a contradiction that this model actually has no analog/digital capture port for PCM frames and no physical MIDI ports. I guess that SCS.1d also has the contradiction. This model has no analog/digital ports for PCM frames and no physical MIDI ports, thus it requires no streaming functionality. This commit adds some modification codes to handle the contradiction, as much as possible. Unfortunately, this module adds one PCM playback substream for SCS.1d so as SCS.1m. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: obsolete scs1x moduleTakashi Sakamoto4-543/+27
Now ALSA oxfw driver gains functionalities which scs1x module has. This commit obsoletes the scs1x module, and adds a line of MODULE_ALIAS to load oxfw module instead of scs1x module. In scs1x module, the name of 'shortname' field is fixed as 'SCS1x'. This field is used to name MIDI ports for both of SCS.1m and SCS.1d. This is not good because typically some SCS.1m and SCS.1d are used in the same system. It's better to distinguish them according to name of the ports. This commit applies model name in config ROM to the 'shortname'. For the name of 'driver' and 'longname', this commit uses the same way applied to the other models. This change may not bring disadvantages to users because userspace applications use ALSA rawmidi or seq interface and these interfaces are not influenced by them directly. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: add MIDI playback port for SCS.1 modelsTakashi Sakamoto1-2/+45
This commit adds MIDI playback ports so that scs1x driver has. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: copy handlers of asynchronous transaction for MIDI playbackTakashi Sakamoto1-0/+161
This commit copies some functions of asynchronous transactions for MIDI playback, to merge scs1x module. The features of payload in asynchronous transaction are the same as captured MIDI messages. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: add MIDI capture port for SCS.1 modelsTakashi Sakamoto1-1/+33
This commit adds MIDI capture so that scs1x driver has. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: copy handlers of asynchronous transaction for MIDI captureTakashi Sakamoto1-1/+82
This commit copies some functions of asynchronous transactions for MIDI capture, to merge scs1x module. The features of payload in asynchronous transaction are: * System exclusive messages for SCS.1 are encoded without ID data. In this encoding scheme, 4 bits in LSB are available. The bits are squashed in payload byte. Thus, one payload byte transfers two MIDI messages. * The first byte of payload byte means: * 0x00: depending on second payload byte * 0xf9: including escaped system exclusive messages for SCS.1, up to 3 byte (= 6 MIDI messages) * the others: including MIDI 1.0 messages * the others: including escaped system exclusive messages for SCS.1, up to 64 bytes Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: allocate own address region for SCS.1 seriesTakashi Sakamoto2-1/+65
When physical controls on SCS.1 models are operated, the models transfer MIDI messages in asynchronous transactions on IEEE 1394 bus. The models have a register to have an address for the transactions, and drivers can register own address for this purpose. This commit keeps a region of address, registers it and adds a handler for the transactions. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: add scs1x layerTakashi Sakamoto4-3/+30
Stanton Controllers and Systems 1 (SCS.1) series is supported by ALSA scs1x driver. This driver just supports MIDI functionality. On the other hand, models in this series are based on OXFW971 and ALSA OXFW driver can support them. SCS.1 series has MIDI functionality to control its surface state such as LED lighting. When operating physical knobs and faders, the models generate MIDI messages. These MIDI messages are transferred by asynchronous transactions. These transactions are really model-specific and ALSA OXFW driver requires the functionality so as scs1x module implements. This commit adds scs1x layer as a preparation to merge scs1x driver to oxfw driver. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: rename a structure so that it means backward compatibility to ↵Takashi Sakamoto2-10/+10
old drivers In former commits, some model-specific members are split from the structure. The structure is just to keep names for compatibility to old drivers. This commit arranges name of the structure and localize it. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: move model-specific parameters from common structureTakashi Sakamoto3-42/+39
In previous commit, some members are moved from 'struct snd_oxfw' because they're model-specific. There are also the other model-specific parameters in 'struct device_info'. This commit moves these members to model-specific structure. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: move model-specific members from common structureTakashi Sakamoto2-19/+34
Currently, 'struct snd_oxfw' has some members for models supported by old firewire-speakers driver, while these members are useless to the other models. This commit allocates new memory block and moves these members to model-specific structure. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-22ALSA: oxfw: enable to keep memory block for model-specific structureTakashi Sakamoto2-0/+2
ALSA oxfw driver should have backward compatibility to old firewire-speakers driver. Additionally, in future commit, scs1x driver will be merged. It's nice to add a pointer to have a memory block for model-specific structures. This commit adds a member to 'struct snd_oxfw' for this aim. Deallocation is done at freeing ALSA card structure. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-16Merge branch 'topic/firewire-update' into for-nextTakashi Iwai4-34/+46
2015-12-15ALSA: oxfw: gather model-dependent conditions to a functionTakashi Sakamoto1-11/+18
Adding control elements is just for models supported by old firewire-speakers modules. The processing should be in a function to add model-dependent quirk. This commit moves the codes to the function. As a result, the function should handle error state, thus this commit also changes prototype of the function. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-15ALSA: oxfw: reuse driver entry to detect quirksTakashi Sakamoto2-16/+24
Currently, assignment to model-dependent quirk is corresponding to asynchronous transactions on IEEE 1394 bus. This is also achieved with device entry. This commit changes the processing of model-dependent quirk with the entry. As a result, the transactions are sent only for Loud models. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
2015-12-15ALSA: oxfw: change function prototype for AV/C Audio Subunit commandTakashi Sakamoto1-23/+31
ALSA OXFW driver uses AV/C Audio Subunit commands to control some models. The commands get/set the state of Feature function block of the subunit. The commands are not specific to OXFW, thus there's a possibility to use them in the other drivers. Currently, helper functions for the commands require 'struct snd_oxfw', although, it's not necessarily required. It's better to change prototype of the functions without the structure for future use. This commit changes the prototype. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>