- 11 May, 2016 2 commits
-
-
Takashi Sakamoto authored
In current implementation, packet processing is done in both of software IRQ contexts of IR/IT contexts and process contexts. This is usual interrupt handling of IR/IT context for 1394 OHCI. (in hardware IRQ context) irq_handler() (drivers/firewire/ohci.c) ->tasklet_schedule() (in software IRQ context) handle_it_packet() or handle_ir_packet_per_buffer() (drivers/firewire/ohci.c) ->flush_iso_completions() ->struct fw_iso_context.callback.sc() = out_stream_callback() or in_stream_callback() However, we have another chance for packet processing. It's done in PCM frame handling via ALSA PCM interfaces. (in process context) ioctl(i.e. SNDRV_PCM_IOCTL_HWSYNC) ->snd_pcm_hwsync() (sound/core/pcm_native.c) ->snd_pcm_update_hw_ptr() (sound/core/pcm_lib.c) ->snd_pcm_update_hw_ptr0() ->struct snd_pcm_ops.pointer() = amdtp_stream_pcm_pointer() ->fw_iso_context_flush_completions() (drivers/firewire/core-iso.c) ->struct fw_card_driver.flush_iso_completions() = ohci_flush_iso_completions() (drivers/firewire/ohci.c) ->flush_iso_completions() ->struct fw_iso_context.callback.sc() = out_stream_callback() or in_stream_callback() This design is for a better granularity of PCM pointer. When ioctl(2) is executed with some commands for ALSA PCM interface, queued packets are handled at first. Then, the latest number of handled PCM frames is reported. The number can represent PCM frames transferred in most near isochronous cycle. Current tracepoints include no information to distinguish running contexts. When tracing the interval of software IRQ context, this is not good. This commit adds more information for current context. Additionally, the index of packet processed in one context is added in a case that packet processing is executed in continuous context of the same kind, As a result, the output includes 11 fields with additional two fields to commit 0c95c1d6 ("ALSA: firewire-lib: add tracepoints to dump a part of isochronous packet data"): 17131.9186: out_packet: 07 7494 ffc0 ffc1 00 000700c0 9001a496 058 45 1 13 17131.9186: out_packet: 07 7495 ffc0 ffc1 00 000700c8 9001ba00 058 46 1 14 17131.9186: out_packet: 07 7496 ffc0 ffc1 00 000700d0 9001ffff 002 47 1 15 17131.9189: out_packet: 07 7497 ffc0 ffc1 00 000700d0 9001d36a 058 00 0 00 17131.9189: out_packet: 07 7498 ffc0 ffc1 00 000700d8 9001e8d4 058 01 0 01 17131.9189: out_packet: 07 7499 ffc0 ffc1 00 000700e0 9001023e 058 02 0 00 17131.9206: in_packet: 07 7447 ffc1 ffc0 01 3f070072 9001783d 058 32 1 00 17131.9206: in_packet: 07 7448 ffc1 ffc0 01 3f070072 90ffffff 002 33 1 01 17131.9206: in_packet: 07 7449 ffc1 ffc0 01 3f07007a 900191a8 058 34 1 02 (Here, some common fields are omitted so that a line is within 80 characters.) The legend is: - The second of cycle scheduled for the packet - The count of cycle scheduled for the packet - The ID of node as source (hex) - The ID of node as destination (hex) - The value of isochronous channel - The first quadlet of CIP header (hex) - The second quadlet of CIP header (hex) - The number of included quadlets - The index of packet in a buffer maintained by this module - 0 in process context, 1 in IRQ context - The index of packet processed in the context Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
ALSA: firewire-lib: permit to flush queued packets only in process context for better PCM period granularity These three commits were merged to improve PCM pointer granularity. commit 76fb8789 ("ALSA: firewire-lib: taskletize the snd_pcm_period_elapsed() call") commit e9148ddd ("ALSA: firewire-lib: flush completed packets when reading PCM position") commit 92b862c7 ("ALSA: firewire-lib: optimize packet flushing") The point of them is to handle queued packets not only in software IRQ context of IR/IT contexts, but also in process context. As a result of handling packets, period tasklet is scheduled when acrossing PCM period boundary. This is to prevent recursive call of 'struct snd_pcm_ops.pointer()' in the same context. When the pointer callback is executed in the process context, it's better to avoid the second callback in the software IRQ context. The software IRQ context runs immediately after scheduled in the process context because few packets are queued yet. For the aim, 'pointer_flush' is used, however it causes a race condition between the process context and software IRQ context of IR/IT contexts. Practically, this race is not so critical because it influences process context to skip flushing queued packet and to get worse granularity of PCM pointer. The race condition is quite rare but it should be improved for stable service. The similar effect can be achieved by using 'in_interrupt()' macro. This commit obsoletes 'pointer_flush' with it. Acked-by: Clemens Ladisch <clemens@ladisch.de> Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 10 May, 2016 11 commits
-
-
Takashi Iwai authored
When snd_pcm_add_chmap_ctls() is called to the PCM stream to which a chmap has been already assigned, it returns as an error due to the conflicting snd_ctl_add() result. However, this also clears the already assigned chmap_kctl field via pcm_chmap_ctl_private_free(), and becomes inconsistent in the later operation. This patch adds the check of the conflicting chmap kctl before actually trying to allocate / assign. The check failure is treated as a kernel warning, as the double call of snd_pcm_add_chmap_ctls() is basically a driver bug and having the stack trace would help developers to figure out the bad code path. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In former commit, drivers in ALSA firewire stack always starts IT context before IR context. If IR context starts after packets are transmitted by peer unit, packet discontinuity may be detected because the context starts in the middle of packet streaming. This situation is rare because IT context usually starts immediately. However, it's better to solve this issue. This is suppressed with CIP_SKIP_INIT_DBC_CHECK flag. This commit enables the same feature as CIP_SKIP_INIT_DBC_CHECK. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In previous commit, this module has no need to reuse parameters of incoming packets for outgoing packets anymore. This commit arranges some needless codes for outgoing packet processing. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In previous commit, this module has no need to reuse parameters of incoming packets for outgoing packets anymore. This commit arranges some needless codes for incoming packet processing. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In clause 6.3 of IEC 61883-6:2000, there's an explanation about processing of presentation timestamp. In the clause, we can see "If a function block receives a CIP, processes it and subsequently re-transmits it, then the SYT of the outgoing CIP shall be the sum of the incoming SYT and the processing delay." ALSA firewire stack has an implementation to partly satisfy this specification. Developers assumed the stack to perform as an Audio function block[1]. Following to the assumption, current implementation of ALSA firewire stack use one software interrupt context to handle both of in/out packets. In most case, this is processed in 1394 OHCI IR context independently of the opposite context. Thus, this implementation uses longer CPU time in the software interrupt context. This is not better for whole system. Against the assumption, I confirmed that each ASIC for IEC 61883-1/6 doesn't necessarily expect it to the stack. Thus, current implementation of ALSA firewire stack includes over-engineering. This commit purges the implementation. As a result, packets of one direction are handled in one software interrupt context and spends minimum CPU time. [1] [alsa-devel] [PATCH 0/8] [RFC] new driver for Echo Audio's Fireworks based devices http://mailman.alsa-project.org/pipermail/alsa-devel/2013-June/062660.htmlSigned-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In packet streaming protocol applied to TASCAM FireWire series, the value of SYT field in CIP header is always zero, therefore it has no meaning. There's no need to synchronize packets in both direction for the series. In current implementation of ALSA firewire stack, driver for the series uses incoming packet parameter for outgoing packet parameter to calculate the number of data blocks. This can be simplified because the task of corresponding driver is to transfer data blocks enough to sampling transfer frequency. This commit purges support of full duplex synchronization to prevent over-engineering implementation. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
On Fireworks board module of Echo Audio, TSB43Cx43A (IceLynx Micro, iCEM) is used to process payload of isochronous packets. There's an public document of this chip[1]. This document is for firmware programmers to transfer/receive AMDTP with IEC60958 data format, however in clause 2.5, 2.6 and 2.7, we can see system design to utilize the sequence of value in SYT field of CIP header. In clause 2.3, we can see the specification of Audio Master Clock (MCLK) from iCEM. Well, this clock is actually not used for sampling clock. This can be confirmed when corresponding driver transfer random value as the sequence of SYT field. Even if in this case, the unit generates proper sound. Additionally, in unique command set for this board module, the format of CIP is changed; for IEC 61883-6 mode which we use, and for Windows Operating System. In the latter mode, the whole 32 bit field in second CIP header from Windows driver is used to represent counter of packets (NO-DATA code is still used for packets without data blocks). If the master clock was physically used by DSP on the board module, the Windows driver must have transferred correct sequence of SYT field. Furthermore, as long as seeing capacities of AudioFire2, AudioFire4, AudioFire8, AudioFirePre8 and AudioFire12, these models don't support SYT-Match clock source. Summary, we have no need to relate incoming/outgoing packets. This commit drops reusing SYT sequence of incoming packets for outgoing packets. [1] Using TSB43Cx43A: S/PDIF over 1394 (2003, Texus Instruments Incorporated) http://www.ti.com/analog/docs/litabsmultiplefilelist.tsp?literatureNumber=slla148&docCategoryId=1&familyId=361Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
Windows driver for BeBoB-based models mostly wait for transmitted packets, then transfer packets to the models. This looks for the relationship between incoming packets and outgoing packets to synchronize the sequence of presentation timestamp. However, the sequence between packets of both direction has no relationship. Even if receiving NO-DATA packets, the drivers transfer packets with meaningful value in SYT field. Additionally, the order of starting packets is always the same, independently of the source of clock. The corresponding driver is expected as a generator of presentation timestamp and these models can select it as a source of sampling clock. This commit drops reusing SYT sequence from ALSA bebob driver. The driver always transfer packets with presentation timestamp generated by ALSA firewire stack, without re-using the sequence of value in SYT field in incoming packets to outgoing packets. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
-
Yura Pakhuchiy authored
Subwoofer does not work out of the box on ASUS N751/N551 laptops. This patch fixes it. Patch tested on N751 laptop. N551 part is not tested, but according to [1] and [2] this laptop requires similar changes, so I included them in the patch. 1. https://github.com/honsiorovskyi/asus-n551-hda-fix 2. https://bugs.launchpad.net/ubuntu/+source/alsa-tools/+bug/1405691 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117781Signed-off-by: Yura Pakhuchiy <pakhuchiy@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
The HD-audio reconfig function got broken in the recent kernels, typically resulting in a failure like: snd_hda_intel 0000:00:1b.0: control 3:0:0:Playback Channel Map:0 is already present This is because of the code restructuring to move the PCM and control instantiation into the codec drive probe, by the commit [bcd96557: ALSA: hda - Build PCMs and controls at codec driver probe]. Although the commit above removed the calls of snd_hda_codec_build_pcms() and *_build_controls() at the controller driver probe, the similar calls in the reconfig were still left forgotten. This caused the conflicting and duplicated PCMs and controls. The fix is trivial: just remove these superfluous calls from reconfig_codec(). Fixes: bcd96557 ('ALSA: hda - Build PCMs and controls at codec driver probe') Reported-by: Jochen Henneberg <jh@henneberg-systemdesign.com> Cc: <stable@vger.kernel.org> # v4.1+ Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 09 May, 2016 10 commits
-
-
Takashi Iwai authored
Since the recent rewrite of HD-audio infrastructure, CONFIG_SND_HDA_RECONFIG has a slightly different meaning. In the earlier versions, it implicitly assumed only the usage via hwdep sysfs entries. Meanwhile, in the recent version, this option is meant to enable the reconfig code in HD-audio driver, which may be used by the patch loader without hwdep interface. This patch tries to clarify the usage pattern a bit better, hopefully avoid the further confusion. Reported-by: Jochen Henneberg <jh@henneberg-systemdesign.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Charles Keepax authored
A switch statement looks a bit cleaner than an if statement spread over 3 lines, as such update this to a switch. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Charles Keepax authored
We can't return a negative error code from the poll callback the return type is unsigned and is checked against the poll specific flags we need to return POLLERR if we encounter an error. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Charles Keepax authored
stream can't be NULL here as we have just taken the address of it, so no need for the check. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Charles Keepax authored
We have a function that returns the appropriate flags for the stream direction, so we should use it. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Acked-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Charles Keepax authored
We can't return a negative error code from the poll callback the return type is unsigned and is checked against the poll specific flags we need to return POLLERR if we encounter an error. Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com> Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
When audio and music units have some quirks in their sequence of packet, it's really hard for non-owners to identify the quirks. Although developers need dumps for sequence of packets, it's difficult for users who have no knowledges and no equipments for this purpose. This commit adds tracepoints for this situation. When users encounter the issue, they can dump a part of packet data via Linux tracing framework as long as using drivers in ALSA firewire stack. Additionally, tracepoints for outgoing packets will be our help to check and debug packet processing of ALSA firewire stack. This commit newly adds 'snd_firewire_lib' subsystem with 'in_packet' and 'out_packet' events. In the events, some attributes of packets and the index of packet managed by this module are recorded per packet. This is an usage: $ trace-cmd record -e snd_firewire_lib:out_packet \ -e snd_firewire_lib:in_packet /sys/kernel/tracing/events/snd_firewire_lib/out_packet/filter /sys/kernel/tracing/events/snd_firewire_lib/in_packet/filter Hit Ctrl^C to stop recording ^C $ trace-cmd report trace.dat ... 23647.033934: in_packet: 01 4073 ffc0 ffc1 00 000f0040 9001b2d1 122 44 23647.033936: in_packet: 01 4074 ffc0 ffc1 00 000f0048 9001c83b 122 45 23647.033937: in_packet: 01 4075 ffc0 ffc1 00 000f0050 9001ffff 002 46 23647.033938: in_packet: 01 4076 ffc0 ffc1 00 000f0050 9001e1a6 122 47 23647.035426: out_packet: 01 4123 ffc1 ffc0 01 010f00d0 9001fb40 122 17 23647.035428: out_packet: 01 4124 ffc1 ffc0 01 010f00d8 9001ffff 002 18 23647.035429: out_packet: 01 4125 ffc1 ffc0 01 010f00d8 900114aa 122 19 23647.035430: out_packet: 01 4126 ffc1 ffc0 01 010f00e0 90012a15 122 20 (Here, some common fields are omitted so that a line to be within 80 characters.) ... One line represent one packet. The legend for the last nine fields is: - The second of cycle scheduled for the packet - The count of cycle scheduled for the packet - The ID of node as source (hex) - Some devices transfer packets with invalid source node ID in their CIP header. - The ID of node as destination (hex) - The value is not in CIP header of packets. - The value of isochronous channel - The first quadlet of CIP header (hex) - The second quadlet of CIP header (hex) - The number of included quadlets - The index of packet in a buffer maintained by this module This is an example to parse these lines from text file by Python3 script: \#!/usr/bin/env python3 import sys def parse_ts(second, cycle, syt): offset = syt & 0xfff syt >>= 12 if cycle & 0x0f > syt: cycle += 0x10 cycle &= 0x1ff0 cycle |= syt second += cycle // 8000 cycle %= 8000 # In CYCLE_TIMER of 1394 OHCI, second is represented in 8 bit. second %= 128 return (second, cycle, offset) def calc_ts(second, cycle, offset): ts = offset ts += cycle * 3072 # In DMA descriptor of 1394 OHCI, second is represented in 3 bit. ts += (second % 8) * 8000 * 3072 return ts def subtract_ts(minuend, subtrahend): # In DMA descriptor of 1394 OHCI, second is represented in 3 bit. if minuend < subtrahend: minuend += 8 * 8000 * 3072 return minuend - subtrahend if len(sys.argv) != 2: print('At least, one argument is required for packet dump.') sys.exit() filename = sys.argv[1] data = [] prev = 0 with open(filename, 'r') as f: for line in f: pos = line.find('packet:') if pos < 0: continue pos += len('packet:') line = line[pos:].strip() fields = line.split(' ') datum = [] datum.append(fields[8]) syt = int(fields[6][4:], 16) # Empty packet in IEC 61883-1, or NODATA in IEC 61883-6 if syt == 0xffff: data_blocks = 0 else: payload_size = int(fields[7], 10) data_block_size = int(fields[5][2:4], 16) data_blocks = (payload_size - 2) / data_block_size datum.append(data_blocks) second = int(fields[0], 10) cycle = int(fields[1], 10) start = (second << 25) | (cycle << 12) datum.append('0x{0:08x}'.format(start)) start = calc_ts(second, cycle, 0) datum.append("0x" + fields[5]) datum.append("0x" + fields[6]) if syt == 0xffff: second = 0 cycle = 0 tick = 0 else: second, cycle, tick = parse_ts(second, cycle, syt) ts = calc_ts(second, cycle, tick) datum.append(start) datum.append(ts) if ts == 0: datum.append(0) datum.append(0) else: # Usual case, or a case over 8 seconds. if ts > start or start > 7 * 8000 * 3072: datum.append(subtract_ts(ts, start)) if ts > prev or start > 7 * 8000 * 3072: gap = subtract_ts(ts, prev) datum.append(gap) else: datum.append('backward') else: datum.append('invalid') prev = ts data.append(datum) sys.exit() The data variable includes array with these elements: - The index of the packet - The number of data blocks in the packet - The value of cycle count (hex) - The value of CIP header 1 (hex) - The value of CIP header 2 (hex) - The value of cycle count (tick) - The value of calculated presentation timestamp (tick) - The offset between the cycle count and presentation timestamp - The elapsed ticks from the previous presentation timestamp Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In callback function of isochronous context, modules can queue packets to indicated isochronous cycles. Although the cycle to queue a packet is deterministic by calculation, this module doesn't implement the calculation because it's useless for processing. In future, the cycle count is going to be printed with the other parameters for debugging. This commit is the preparation. The cycle count is computed by cycle unit, and correctly arranged to corresponding packets. The calculated count is used in later commit. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
In callback function of isochronous context, u32 variable is passed for cycle count. The value of this variable comes from DMA descriptors of 1394 Open Host Controller Interface (1394 OHCI). In the specification, DMA descriptors transport lower 3 bits for second field and full cycle field in 16 bits field, therefore 16 bits of the u32 variable are available. The value for second is modulo 8, and the value for cycle is modulo 8,000. Currently, ALSA firewire-lib module don't use the value of the second field, because the value is useless to calculate presentation timestamp in IEC 61883-6. However, the value may be useful for debugging. In later commit, it will be printed with the other parameters for debugging. This commit makes this module to handle the whole cycle count including second. The value is calculated by cycle unit. The existed code is already written with ignoring the value of second, thus this commit causes no issues. Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Kaho Ng authored
For reducing the noise from the headset output on ASUS UX501VW, call the existing fixup, alc_fixup_headset_mode_alc668(), additionally. Thread: https://bbs.archlinux.org/viewtopic.php?id=209554Signed-off-by: Kaho Ng <ngkaho1234@gmail.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 08 May, 2016 11 commits
-
-
Jeeja KP authored
If the DMAs are not being quiesced properly, it may lead to stability issues, so the recommendation is to wait till DMAs are stopped. After setting the stop bit of RIRB/CORB DMA, we should wait for stop bit to be set. Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Vinod Koul authored
ebus is a member of extended device and was never initialized, so do this at device creation. Signed-off-by: Jeeja KP <jeeja.kp@intel.com> Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oliver Neukum authored
Allow for SS+ USB devices Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Oliver Neukum authored
Allow handling SS+ USB devices correctly. Signed-off-by: Oliver Neukum <oneukum@suse.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Kailang Yang authored
Support new codecs for ALC234/ALC274/ALC294. This three codecs was the same IC. But bonding is not the same. Signed-off-by: Kailang Yang <kailang@realtek.com> Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Dan Carpenter authored
"header->number" can be up to USHRT_MAX and it comes from the ioctl so it needs to be capped. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Kangjie Lu authored
The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu <kjlu@gatech.edu> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Kangjie Lu authored
The stack object “r1” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu <kjlu@gatech.edu> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Kangjie Lu authored
The stack object “tread” has a total size of 32 bytes. Its field “event” and “val” both contain 4 bytes padding. These 8 bytes padding bytes are sent to user without being initialized. Signed-off-by: Kangjie Lu <kjlu@gatech.edu> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Vinod Koul authored
Noticed two typos in Documentation, so fix them up Signed-off-by: Vinod Koul <vinod.koul@intel.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Sakamoto authored
M-Audio Profire 610 has an unexpected value in version field of its config ROM, thus ALSA dice driver is not assigned to the model due to a mismatch of modalias. This commit adds an entry to support the model. I expect the entry is also for Profire 2626. I note that Profire 610 uses TCD2220 (so-called Dice Jr.), and supports a part of Extended Application Protocol (EAP). $ cd linux-firewire-utils/src $ ./crpp < /sys/bus/firewire/devices/fw1/config_rom ROM header and bus information block ------------------------------------------------------------ 400 04047689 bus_info_length 4, crc_length 4, crc 30345 404 31333934 bus_name "1394" 408 e0ff8112 irmc 1, cmc 1, isc 1, bmc 0, pmc 0, cyc_clk_acc 255, max_rec 8 (512), max_rom 1, gen 1, spd 2 (S400) 40c 000d6c04 company_id 000d6c | 410 04400002 device_id 0404400002 | EUI-64 000d6c0404400002 root directory ------------------------------------------------------------ 414 000695fe directory_length 6, crc 38398 418 03000d6c vendor 41c 8100000a --> descriptor leaf at 444 420 17000011 model 424 8100000d --> descriptor leaf at 458 428 0c0087c0 node capabilities per IEEE 1394 42c d1000001 --> unit directory at 430 unit directory at 430 ------------------------------------------------------------ 430 0004fb14 directory_length 4, crc 64276 434 12000d6c specifier id 438 130100d1 version 43c 17000011 model 440 8100000c --> descriptor leaf at 470 descriptor leaf at 444 ------------------------------------------------------------ 444 0004b8e4 leaf_length 4, crc 47332 448 00000000 textual descriptor 44c 00000000 minimal ASCII 450 4d2d4175 "M-Au" 454 64696f00 "dio" descriptor leaf at 458 ------------------------------------------------------------ 458 00053128 leaf_length 5, crc 12584 45c 00000000 textual descriptor 460 00000000 minimal ASCII 464 50726f46 "ProF" 468 69726520 "ire " 46c 36313000 "610" descriptor leaf at 470 ------------------------------------------------------------ 470 00053128 leaf_length 5, crc 12584 474 00000000 textual descriptor 478 00000000 minimal ASCII 47c 50726f46 "ProF" 480 69726520 "ire " 484 36313000 "610" $ cat /proc/asound/card1/dice sections: global: offset 10, size 90 tx: offset 100, size 142 rx: offset 242, size 282 ext_sync: offset 524, size 4 unused2: offset 0, size 0 global: owner: ffc0:000100000000 notification: 00000040 nick name: FW610 clock select: internal 48000 enable: 1 status: locked 48000 ext status: 00000040 sample rate: 48000 version: 1.0.4.0 clock caps: 32000 44100 48000 88200 96000 176400 192000 aes1 aes4 aes adat tdif wc arx1 arx2 internal clock source names: SPDIF\AES34\AES56\TOS\AES_ANY\ADAT\ADAT_AUX\Word Clock\Unused\Unused\Unused\Unused\Internal\\ ... Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 29 Apr, 2016 2 commits
-
-
Takashi Iwai authored
Phoenix Audio MT202pcs (1de7:0114) and MT202exe (1de7:0013) need the same workaround as TMX320 for avoiding the firmware bug. It fixes the frequent error about the sample rate inquiries and the slow device probe as consequence. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=117321 Cc: <stable@vger.kernel.org> Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
Takashi Iwai authored
There are many USB audio devices with buggy firmware that don't react with the sample rate reading properly. This often results in the flood of error messages and slowing down the operation. The sample rate read back is basically only for confirming the sample rate setup, and it's not critically important. As a compromise, in this patch, we stop the sample rate read back once when the device gives errors more than tolerance (twice, as of now). This should improve most of error cases while we still can catch the firmware bugginess. Signed-off-by: Takashi Iwai <tiwai@suse.de>
-
- 27 Apr, 2016 1 commit
-
-
Takashi Iwai authored
Merge tag 'asoc-fix-v4.6-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus ASoC: Fixes for v4.6 This is a fairly large collection of fixes but almost all driver specific ones, especially to the new Intel drivers which have had a lot of recent development. The one core fix is a change to the debugfs code to avoid crashes in some relatively unusual configurations.
-
- 26 Apr, 2016 3 commits
-
-
Mark Brown authored
-
Mark Brown authored
Merge remote-tracking branches 'asoc/fix/arizona', 'asoc/fix/cs35l32', 'asoc/fix/hdac', 'asoc/fix/nau8825' and 'asoc/fix/rt5616' into asoc-linus
-
Mark Brown authored
-