IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The recent change in ALSA core allows drivers to get the current PCM
state directly from runtime object. Replace the calls accordingly.
Reviewed-by: Jaroslav Kysela <perex@perex.cz>
Link: https://lore.kernel.org/r/20220926135558.26580-5-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
A user reports functional regression for Mackie Onyx 1640i that the device
generates slow sound with ALSA oxfw driver which supports media clock
recovery. Although the device is based on OXFW971 ASIC, it does not
transfer isochronous packet with own event frequency as expected. The
device seems to adjust event frequency according to events in received
isochronous packets in the beginning of packet streaming. This is
unknown quirk.
This commit fixes the regression to turn the recovery off in driver
side. As a result, nominal frequency is used in duplex packet streaming
between device and driver. For stability of sampling rate in events of
transferred isochronous packet, 4,000 isochronous packets are skipped
in the beginning of packet streaming.
Reference: https://github.com/takaswie/snd-firewire-improve/issues/38
Fixes: 029ffc4294 ("ALSA: oxfw: perform sequence replay for media clock recovery")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20211028130325.45772-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Loud Technologies Mackie Onyx 1640i (former model) is identified as
the model which uses OXFW971. The analysis of packet dump shows that
it transfers events in blocking method of IEC 61883-6, however the
default behaviour of ALSA oxfw driver is for non-blocking method.
This commit adds code to detect it assuming that all of loud models
based on OXFW971 have such quirk. It brings no functional change
except for alignment rule of PCM buffer.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210913021042.10085-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
OXFW 971 has no function to use the value in syt field of received
isochronous packet for playback timing generation. In kernel prepatch for
v5.14, ALSA OXFW driver got change to send NO_INFO value in the field
instead of actual timing value. The change brings Apogee Duet FireWire to
generate no playback sound, while output meter moves.
As long as I investigate, _any_ value in the syt field takes the device to
generate sound. It's reasonable to think that the device just ignores data
blocks in packet with NO_INFO value in its syt field for audio data
processing.
This commit adds a new flag for the quirk to fix regression.
Fixes: 029ffc4294 ("ALSA: oxfw: perform sequence replay for media clock recovery")
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210812022839.42043-1-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The delayed registration of sound card instance brings less benefit than
complication of kobject management. This commit ceases from it.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210607081250.13397-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit takes ALSA oxfw driver to perform sequence replay for media
clock recovery. Unfortunately, OXFW970 ASIC and its firmware has a quirk
called jumbo payload which skips several isochronous cycles for packet
transmission, thus the sequence replay is just adopted to OXFW971 ASIC.
As well as Fireworks, OXFW ASICs also ignores presentation time against
the way in IEC 61883-1/6.
The sequence replay is tested with below models:
* Tascam FireOne
* Stanton Magnetics SCS.1m
* Apogee Duet FireWire
For below models, the sequence replay is tested to be disabled:
* Griffin FireWave
* Behringer F-Control Audio 202
* Loud Technology Tapco Link.FireWire 4x6
* Loud Technology Mackie Onyx Satellite
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210531025103.17880-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Models in below series start transmission of packet after receiving the
sequence of packets:
* Digidesign Digi00x family
* RME Fireface series
Additionally, models in Tascam FireWire series start multiplexing PCM
frames into packets enough after receiving packets. It's required to
transfer packets on-the-fly for the above models according to nominal
sampling transfer frequency before starting sequence replay.
This commit allows drivers to decide whether the engine transfers packet
on-the-fly or not.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210527122611.173711-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In design of audio and music unit in IEEE 1394 bus, feedback of
effective sampling transfer frequency (STF) is delivered by packets
transferred from device. The devices supported by ALSA firewire stack
are categorized to three groups regarding to it.
* Group 1:
* Echo Audio Fireworks board module
* Oxford Semiconductor OXFW971 ASIC
* Digidesign Digi00x family
* Tascam FireWire series
* RME Fireface series
* Group 2:
* BridgeCo. DM1000/DM1100/DM1500 ASICs for BeBoB solution
* TC Applied Technologies DICE ASICs
* Group 3:
* Mark of the Unicord FireWire series
In group 1, the effective STF is determined by the sequence of the number
of events per packet. In group 2, the sequence of presentation timestamp
expressed in syt field of CIP header is interpreted as well. In group 3,
the presentation timestamp is expressed in source packet header (SPH) of
each data block.
I note that some models doesn't take care of effective STF with large
internal buffer. It's reasonable to name it as group 0:
* Group 0
* Oxford Semiconductor OXFW970 ASIC
The effective STF is known to be slightly different from nominal STF for
all of devices, and to be different between the devices. Furthermore, the
effective STF is known to be shifted for long-period transmission. This
makes it hard for software to satisfy the effective STF when processing
packets to the device.
The effective STF is deterministic as a result of analyzing the batch of
packet transferred from the device. For the analysis, caching the sequence
of parameter in the packet is required.
This commit adds an option so that AMDTP domain structure takes AMDTP
stream structure to cache the sequence of parameters in packet transferred
from the device. The parameters are offset ticks of syt field against the
cycle to receive the packet and the number of data blocks per packet.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210527122611.173711-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When starting AMDTP domain, tasks in process context yields running CPU
till all of isochronous context get callback, with an assumption that
it's OK to process content of packet.
However several isochronous cycles are skipped to transfer rx packets, or
the content of rx packets are dropped, to manage the timing to start
processing the packets.
This commit changes the timing for tasks in process context to wake up
when processing content of packet is actually ready.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210520040154.80450-9-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA OXFW supports two types of ASICS; OXFW970 and OXFW971. The former
is known to have a quirk we call 'jumbo payload' that some isochronous
cycles are skipped to transfer isochronous packets during handling
asynchronous transaction. The quirk seems to correspond to firmware
initially delivered by Oxford Semiconductor since the quirk is not
confirmed for Mackie Onyx Satellite in which the revised firmware is
available. The quirk is not confirmed in the latter.
This commit adds code comment to describe the quirk.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-8-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Loud Technologies Mackie Onyx Satellite is identified as the model with
OXFW970 ASIC.
This commit adds explicit entry for the model.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Loud Technologies Tapco Link.FireWire 4x6 is identified as the model
with OXFW970 ASIC.
This commit adds explicit entry for the model.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-6-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit changes condition statement to call mackie models detection
just for the device entry. Additionally, comment is added for Onyx 1640i.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
All of the devices known to be based on OXFW ASICs have the same layout
of configuration ROM, in which unit directory includes vendor, model,
specifier_id and version immediate values. Especially, the pair of
specifier_id and version is fixed to represent AV/C general protocol.
This commit refactors device entries to fulfil with these 4 elements.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This reverts commit 0edabdfe89.
I've explained that optional FireWire card for d.2 is also built-in to
d.2 Pro, however it's wrong. The optional card uses DM1000 ASIC and has
'Mackie DJ Mixer' in its model name of configuration ROM. On the other
hand, built-in FireWire card for d.2 Pro and d.4 Pro uses OXFW971 ASIC
and has 'd.Pro' in its model name according to manuals and user
experiences. The former card is not the card for d.2 Pro. They are similar
in appearance but different internally.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210518084557.102681-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Mackie d.2 has an extension card for IEEE 1394 communication, which uses
BridgeCo DM1000 ASIC. On the other hand, Mackie d.4 Pro has built-in
function for IEEE 1394 communication by Oxford Semiconductor OXFW971,
according to schematic diagram available in Mackie website. Although I
misunderstood that Mackie d.2 Pro would be also a model with OXFW971,
it's wrong. Mackie d.2 Pro is a model which includes the extension card
as factory settings.
This commit fixes entries in Kconfig and comment in ALSA OXFW driver.
Cc: <stable@vger.kernel.org>
Fixes: fd6f4b0dc1 ("ALSA: bebob: Add skelton for BeBoB based devices")
Fixes: ec4dba5053 ("ALSA: oxfw: Add support for Behringer/Mackie devices")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20210513125652.110249-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Smatch complains that "count" isn't clamped properly and
"oxfw->dev_lock_changed" is false then it leads to an information
leak. But it turns out that "oxfw->dev_lock_changed" is always
set and the condition can be removed.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/YA6ntkBxT/4DJ4YK@mwanda
Signed-off-by: Takashi Iwai <tiwai@suse.de>
strlcpy is deprecated. see: Documentation/process/deprecated.rst
Change the calls that do not use the strlcpy return value to the
preferred strscpy.
Done with cocci script:
@@
expression e1, e2, e3;
@@
- strlcpy(
+ strscpy(
e1, e2, e3);
This cocci script leaves the instances where the return value is
used unchanged.
After this patch, sound/ has 3 uses of strlcpy() that need to be
manually inspected for conversion and changed one day.
$ git grep -w strlcpy sound/
sound/usb/card.c: len = strlcpy(card->longname, s, sizeof(card->longname));
sound/usb/mixer.c: return strlcpy(buf, p->name, buflen);
sound/usb/mixer.c: return strlcpy(buf, p->names[index], buflen);
Miscellenea:
o Remove trailing whitespace in conversion of sound/core/hwdep.c
Link: https://lore.kernel.org/lkml/CAHk-=wgfRnXz0W3D37d01q3JFkr_i_uTL=V6A6G1oUZcprmknw@mail.gmail.com/
Signed-off-by: Joe Perches <joe@perches.com>
Acked-by: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/22b393d1790bb268769d0bab7bacf0866dcb0c14.camel@perches.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Stanton SCS.1d uses Oxford Semiconductor FW 971 ASIC (FW971) for
communication. Although the unit is bound to ALSA oxfw driver, the instance
of sound card can not be added due to its quirk of plug information. This
bug was added when snd-scs1x is merged into snd-oxfw at commit
9e2004f9ce ("ALSA: oxfw: obsolete scs1x module").
This commit fixes the driver for the quirk. In cases that the unit returns
NOT IMPLEMENTED for some AV/C commands, the sound card is added without any
PCM/MIDI interfaces for packet streaming. For SCS.1d, model dependent
operation adds MIDI interface and applications can use it to operate
according to HSS1394 protocol from reverse-engineering work by Sean M.
Pappalardo.
Plug Control Register (PCR) has information that the unit has a pair of
plugs for isochronous communication:
(oMPR)
$ ./firewire-request /dev/fw1 read 0xfffff0000900
result: 80ff0001
(iMPR)
$ ./firewire-request /dev/fw1 read 0xfffff0000980
result: 80ff0001
AV/C PLUG INFO also returns information that the unit has a pair of
plugs for isochronous communication.
(AV/C PLUG INFO command)
$ ./firewire-request /dev/fw1 fcp 0x01ff0200ffffffff
response: 000: 0c ff 02 00 01 01 02 02
However, AV/C PLUG SIGNAL INFO command is rejected for both plugs.
(AV/C OUTPUT PLUG SIGNAL INFO command)
$ ./firewire-request /dev/fw1 fcp 0x01ff1800ffffffff
response: 000: 0a ff 18 00 ff ff ff ff
(AV/C INPUT PLUG SIGNAL INFO command)
$ ./firewire-request /dev/fw1 fcp 0x01ff1900ffffffff
response: 000: 0a ff 19 00 ff ff ff ff
Furthermore, AV/C EXTENDED STREAM FORMAT INFO is not implemented.
(AV/C EXTENDED STREAM FORMAT INFO list subfunction for input plug)
$ ./firewire-request /dev/fw1 fcp 0x01ffbfc000000000ffff00ff
response: 000: 08 ff bf c0 00 00 00 00 ff ff 00 ff
(AV/C EXTENDED STREAM FORMAT INFO list subfunction for output plug)
$ ./firewire-request /dev/fw1 fcp 0x01ffbfc001000000ffff00ff
response: 000: 08 ff bf c0 01 00 00 00 ff ff 00 ff
(AV/C EXTENDED STREAM FORMAT INFO single subfunction for input plug)
$ ./firewire-request /dev/fw1 fcp 0x01ffbfc100000000ffffffff
response: 000: 08 ff bf c1 00 00 00 00 ff ff ff ff
(AV/C EXTENDED STREAM FORMAT INFO single subfunction for output plug)
$ ./firewire-request /dev/fw1 fcp 0x01ffbfc101000000ffffffff
response: 000: 08 ff bf c1 01 00 00 00 ff ff ff ff
Reference: https://mailman.alsa-project.org/pipermail/alsa-devel/2012-May/052264.html
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200113073418.24622-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Stanton SCS.1d doesn't support packet streaming even if it has plugs for
isochronous communication.
This commit is a preparation for this case. The 'has_input' member is
added to specific structure, and MIDI/PCM interfaces are not added when
the member is false.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200113073418.24622-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When AV/C command returns 'NOT IMPLEMENTED' status in its response, ALSA
oxfw driver uses ENOSYS as error code. However, it's expected just to be
used for missing system call number.
This commit replaces it with ENXIO.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20200113073418.24622-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
All the PCM ioctl ops of ALSA FireWire drivers do nothing but calling
the default handler.
Now PCM core accepts NULL as the default ioctl ops(*), so let's drop
altogether.
(*) commit fc033cbf6f ("ALSA: pcm: Allow NULL ioctl ops")
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191210061145.24641-6-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Clean up the drivers with the new managed buffer allocation API.
The superfluous snd_pcm_lib_malloc_pages() and
snd_pcm_lib_free_pages() calls are dropped.
Acked-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191209192422.23902-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The recent change (*) in the ALSA memalloc core allows us to drop the
special vmalloc-specific allocation and page handling. This patch
coverts to the common code.
(*) 1fe7f397cf: ALSA: memalloc: Add vmalloc buffer allocation
support
7e8edae39f: ALSA: pcm: Handle special page mapping in the
default mmap handler
Link: https://lore.kernel.org/r/20191105151856.10785-11-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Some devices have a quirk to postpone transmission of isoc packet for
several dozen or hundred isoc cycles since configured to transmit.
Furthermore, some devices have a quirk to transmit isoc packet with
discontinued data of its header.
In 1394 OHCI specification, software allows to start isoc context with
certain isoc cycle. Linux firewire subsystem has kernel API to use it
as well.
This commit uses the functionality of 1394 OHCI controller to handle
the quirks. At present, this feature is convenient to ALSA bebob and
fireface driver. As a result, some devices can be safely handled, as
long as I know:
- MAudio FireWire solo
- MAudio ProFire Lightbridge
- MAudio FireWire 410
- Roland FA-66
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-7-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
An isoc context for AMDTP stream is flushed to queue packet
by a call of pcm.ack. This commit extends this for AMDTP
domain.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-4-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
An isoc context for AMDTP stream is flushed to queue packet
by a call of pcm.pointer. This commit extends this for AMDTP
domain.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191018061911.24909-3-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit allows ALSA oxfw driver to share PCM buffer size for both
capture and playback PCM substream. When AMDTP domain starts for one
of the PCM substream, buffer size of the PCM substream is stores to
AMDTP domain structure. Some AMDTP streams have already run with the
buffer size when another PCM substream starts, therefore the PCM
substream has a constraint to its buffer size.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The number of packets in packet buffer has been fixed number (=48) since
first commit of ALSA IEC 61883-1/6 packet streaming engine.
This commit allows the engine to use variable number of packets in the
buffer. The size is calculated by a parameter in AMDTP domain structure
surely to store the number of events in the packets of buffer. Although
the value of parameter is expected to come from 'period size' parameter
of PCM substream, at present 48 is still used.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191017155424.885-2-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, when opening a PCM substream, it's needed to
check whether the opposite PCM substream runs. This is to assign
effectual constraints (e.g. sampling rate) to opened PCM substream.
The number of PCM substreams and MIDI substreams on AMDTP streams in
domain is recorded in own structure. Usage of this count is an
alternative of the above check. This is better because the count is
incremented in pcm.hw_params earlier than pcm.trigger.
This idea has one issue because it's incremented for MIDI substreams as
well. In current implementation, for a case that any MIDI substream run
and a PCM substream is going to start, PCM application to start the PCM
substream can decide hardware parameters by restart packet streaming.
Just checking the substream count can brings regression.
Now AMDTP domain structure has a member for the size of PCM period in
PCM substream which starts AMDTP streams in domain. When the value has
zero and the substream count is greater than 1, it means that any MIDI
substream starts AMDTP streams in domain. Usage of the value can resolve
the above issue.
This commit replaces the check with the substream count and the value for
the size of PCM period.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-13-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a preparation to share the size of PCM period between
PCM substreams on AMDTP streams in the same domain. At this time,
the size of PCM period in PCM substream which starts AMDTP streams in the
same domain is recorded.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Link: https://lore.kernel.org/r/20191007110532.30270-5-o-takashi@sakamocchi.jp
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Quite a big update this time around, particularly in the core
where we've had a lot of cleanups from Morimoto-san - there's
not much functional change but quite a bit of modernization
going on. We've also seen a lot of driver work, a lot of it
cleanups but also some particular drivers.
- Lots and lots of cleanups from Morimoto-san and Yue Haibing.
- Lots of cleanups and enhancements to the Freescale, sunxi dnd
Intel rivers.
- Initial Sound Open Firmware suppot for i.MX8.
- Removal of w90x900 and nuc900 drivers as the platforms are
being removed.
- New support for Cirrus Logic CS47L15 and CS47L92, Freescale
i.MX 7ULP and 8MQ, Meson G12A and NXP UDA1334
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl13cr4THGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0NKuB/9fvRIh6bJ4pUA26Bc7+shJQ1BtC/MN
jo1G4maN+hY5ZUwE5hvg04S6W6Unm1iNotQecKcF43Vh/4SZNiLtfSEM4b/6IBWw
IFUU6xDz8Q4HbF4HJMotpKQKMABpfds5flH2e1YrrNoMH+KlkC9kJOR26B2W36xW
TZclfquCDICxr8M7eYGM7N5hOqSrlugyWBZqTTnTDnsMrW4SAaH2HYwFhaeayd+I
ECyaXIoUHvo4FX5ueZv/mzBiMl0z4rgXn3tuqI6a8LoWJdRZTkcSQabtuIC+wmxb
P734RY6vjSUYZrv03cAtxHDrSVoC/RYedOzhT+iFF6y/NHzdu701lsJb
=aD0T
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-next
ASoC: Updates for v5.4
Quite a big update this time around, particularly in the core
where we've had a lot of cleanups from Morimoto-san - there's
not much functional change but quite a bit of modernization
going on. We've also seen a lot of driver work, a lot of it
cleanups but also some particular drivers.
- Lots and lots of cleanups from Morimoto-san and Yue Haibing.
- Lots of cleanups and enhancements to the Freescale, sunxi dnd
Intel rivers.
- Initial Sound Open Firmware suppot for i.MX8.
- Removal of w90x900 and nuc900 drivers as the platforms are
being removed.
- New support for Cirrus Logic CS47L15 and CS47L92, Freescale
i.MX 7ULP and 8MQ, Meson G12A and NXP UDA1334
When userspace application calls ioctl(2) to configure hardware for PCM
playback substream, ALSA OXFW driver handles incoming AMDTP stream.
In this case, outgoing AMDTP stream should be handled.
This commit fixes the bug for v5.3-rc kernel.
Fixes: 4f380d0070 ("ALSA: oxfw: configure packet format in pcm.hw_params callback")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA oxfw driver supports Griffin FireWave. This device supports one
isochronous stream for PCM playback. Current driver executes code to
wait event for stream structure of opposite direction. This causes
NULL pointer dereference.
This commit fixes the bug.
Fixes: ac5d77864c ("ALSA: oxfw: support AMDTP domain")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.
- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.
-----BEGIN PGP SIGNATURE-----
iQFHBAABCgAxFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAl0jGwUTHGJyb29uaWVA
a2VybmVsLm9yZwAKCRAk1otyXVSH0LD4B/9AkutfS+vznOrk0V0wFb2SUfjwE4Pr
+z/kAehohAOl/7pg9Dun/lmZYBWMyOM2aYmK81ahEo2DfO+uzwkwjCaXFjGVGwEK
j7XpWkrIjKnou/z1FeALgVvt+crzdy5iNWC04AbKaP2WHCcI7zvPQIsBta/V0OJt
lg+j0J7pagnTMcgV1+qJdaASmofy/hpoZ79Gv0PIfGC8hpJ/3mBgcNPCLQrJtD4R
v+tzvCZNrZVqCanwLf3vouEm1bpWYOpI+Wdmu4u6rY7MhmCj72EJ2zyfdm/qtaxF
e7whgCyOQFkWe7NgDn0G08aAT6LsaxOtPNr7H8tL8S8sw8425fqeOouV
=n/HQ
-----END PGP SIGNATURE-----
Merge tag 'asoc-v5.3' of https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Updates for v5.3
This is a very big update, mainly thanks to Morimoto-san's refactoring
work and some fairly large new drivers.
- Lots more work on moving towards a component based framework from
Morimoto-san.
- Support for force disconnecting muxes from Jerome Brunet.
- New drivers for Cirrus Logic CS47L35, CS47L85 and CS47L90, Conexant
CX2072X, Realtek RT1011 and RT1308.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In IEC 61883-6, several types of sampling data can be multiplexed into
payload of common isochronous packet (CIP). For typical audio and music
units, PCM samples and MIDI messages are multiplexed into one packet
streaming.
ALSA oxfw driver allows applications of rawmidi interface to start
packet streaming for transmission of MIDI messages. However at error
path, the reference count of stream functionality is not operated
correctly. This can brings a bug that packet streaming is not stopped
when all referrers release the count.
This commit fixes the bug.
Fixes: 4f380d0070 ("ALSA: oxfw: configure packet format in pcm.hw_params callback")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This back-merge is necessary for adjusting the latest FireWire fix
with the recent refactoring in 5.3 development branch.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
When stopping packet streaming in reserve function for duplex streams,
isochronous resources should be released.
Fixes: 7bc93821a7 ("ALSA: firewire-lib: split allocation of isochronous resources from establishment of connection")
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In current implementation, establishment connection corresponds to
allocation of isochronous resources. Although this is an ideal
implementation of CMP described in IEC 61883-1, it's not enough
efficient to recover PCM substream multiplexed in packet streaming.
The packet streaming can always restart on the same allocated
isochronous resources even if the previous packet streaming
corrupted.
This commit splits allocation of isochronous resources from
establishment of connection so that CMP runs with allocated
isochronous resources.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
you might feel like a deja vu to receive a bulk of changes at rc5,
and it happens again; we've got a collection of fixes for ASoC.
Most of fixes are targeted for the newly merged SOF (Sound Open
Firmware) stuff and the relevant fixes for Intel platforms.
Other than that, there are a few regression fixes for the recent
ASoC core changes and HD-audio quirk, as well as a couple of
FireWire fixes and for other ASoC codecs.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAl0DY4YOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE/X9BAAzLc3OXBQhnQfFGvAmW8ro/bRuhwg3KjptwNe
Zd/y6V4ru2Lhuqbr+EZMZqu665EkTg1CpHydMwsmD7bbmi47Xet7ocufjQMgHKcX
l+QVRvzB+Ve5ARdUww8B6jqoc7CvZiM/tcW9VP3kphXOD4/iY1VcnRbVzHGYrAgI
drLCnlC91Z5ssWPmAjuju6vZUwqCQupALs0wtdRFnwRonz0sCcPKjKzPAoS6KVQS
6kzRW3nLqKMpatbXdaSjb5tdVxRax8042sqaCqppvE1ToxvkbvSZykOwLQGDdCDn
zkHUv+hmS76IV2Q4baCkAl4fkborKOJXgNQnoxQ5VDbOzBbOMy6867jQ+Y3gEx8k
UqGpS2AA46c3pQcUvos0KqqHaSe3ESP2sH02k0BWWpmnyo927MAYE7qm80BnqjmJ
emXXs0I5u5MkUBb00jP2QpvZqhoKzRLD84BWuHSlg5gIDCQ1cn1WIQaq8YIT4+Bf
V50QUZMPI3PIw1g81XYLZXbhT/0b3zurOOhwEChPyJdz1ZoIyEeGMxt1rsZWD64B
qn24AzRfIQTDteIYUmYovUtzZeFcAqQDsbtLQa98BzDHAYhvJEc+1bbT/NYgtv7/
zJqeFX9CbOcDihmiThvZKVAfThQeUCSWFBXk5JgBxs19uUa4et7XCHbXmPeyBJiq
gF2xAhs=
=9U0L
-----END PGP SIGNATURE-----
Merge tag 'sound-5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull sound fixes from Takashi Iwai:
"It might feel like deja vu to receive a bulk of changes at rc5, and it
happens again; we've got a collection of fixes for ASoC. Most of fixes
are targeted for the newly merged SOF (Sound Open Firmware) stuff and
the relevant fixes for Intel platforms.
Other than that, there are a few regression fixes for the recent ASoC
core changes and HD-audio quirk, as well as a couple of FireWire fixes
and for other ASoC codecs"
* tag 'sound-5.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound: (54 commits)
Revert "ALSA: hda/realtek - Improve the headset mic for Acer Aspire laptops"
ALSA: ice1712: Check correct return value to snd_i2c_sendbytes (EWS/DMX 6Fire)
ALSA: oxfw: allow PCM capture for Stanton SCS.1m
ALSA: firewire-motu: fix destruction of data for isochronous resources
ASoC: Intel: sst: fix kmalloc call with wrong flags
ASoC: core: Fix deadlock in snd_soc_instantiate_card()
SoC: rt274: Fix internal jack assignment in set_jack callback
ALSA: hdac: fix memory release for SST and SOF drivers
ASoC: SOF: Intel: hda: use the defined ppcap functions
ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_card
ASoC: Intel: cht_bsw_rt5672: fix kernel oops with platform_name override
ASoC: Intel: cht_bsw_nau8824: fix kernel oops with platform_name override
ASoC: Intel: bytcht_es8316: fix kernel oops with platform_name override
ASoC: Intel: cht_bsw_max98090: fix kernel oops with platform_name override
ASoC: sun4i-i2s: Add offset to RX channel select
ASoC: sun4i-i2s: Fix sun8i tx channel offset mask
ASoC: max98090: remove 24-bit format support if RJ is 0
ASoC: da7219: Fix build error without CONFIG_I2C
ASoC: SOF: Intel: hda: Fix COMPILE_TEST build error
ASoC: SOF: fix DSP oops definitions in FW ABI
...
This commit is a part of preparation to perform allocation/release
of isochronous resources in pcm.hw_params/hw_free callbacks.
This commit splits out an operation to configure stream parameters into
pcm.hw_params callback. In pcm.prepare callback, establishing
connections and start isochronous contexts.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
This commit is a part of preparation to perform allocation/release
of isochronous resources in pcm.hw_params/hw_free callbacks.
At present, several operations are done in pcm.prepare callback. To
reduce load of the callback, This commit splits out an operation to
set packet format in pcm.hw_params callback.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commits, two isochronous contexts are handles at the same
time. This commit unifies stream counters to obsolete them.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
In former commits, ALSA oxfw driver handles two isochronous contexts
at the same time, except for some devices which supports one endpoint
of isochronous packet stream.
This commit renames some helper functions so that they handles duplex
streams.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The helper function stop packet streaming is not enough useful. This
commit obsoletes it and expands its code.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
