| Age | Commit message (Collapse) | Author |
|---|
|
In most cases, we prefer the onboard codec as the primary device, thus
it's better to set it as the mixer name. Currently, however, the
mixer name is updated per the device instantiation order, and user
gets often HDMI/DP or other seen as a mixer chip name. Also, if a
codec name is renamed by the driver, the old chip name might be left
still as the mixer name.
This patch addresses these issues by remembering the chip address that
was referred as the mixer name. When a codec with the same or lower
address gives its name, renew the mixer name accordingly, as it's
either the update of the codec name or we get likely the more
appropriate chip as the reference.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
A few multiple codec drivers do renaming the chip_name string but all
these are open-coded and some of them have even no error check. Let's
make common helpers to do it properly.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Cirrus codecs have also fine power controls on each widget, thus it
gets benefit from the recent widget power-saving feature. As we
haven't seen any obvious regressions with tests on some MacBooks,
let's try to enable it.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We cap the upper bound of "idx" but not the negative side. Let's make
it unsigned to fix this.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Gen1 SRU support was created for preparation of Gen2 SRC support,
but no-one is using this feature (sampling rate convert) on Gen1.
BockW had used SRU before, but it was pass through mode.
This means it is same as SSI. And BockW "platform base" code was
removed from upstream code. It is now supported via DT, but it doesn't
use SRU. More detail, r8a7778.dtsi has "rcar_sound,src" entry, but
no-one is using this feature today. SRU probing has no relation to this
removing. This means there is no effect for DT compatibility, no issues
on upstream kernel.
Gen2 SRC was created from Gen1 SRU, these are similar but not same IP.
Keeping Gen1 SRU in current driver is a little bit difficult,
and no-one is using it today. Gen1 sound is still supported via SSI.
Gen1 SRU support will be removed in the next kernel version.
This patch announces it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Rounding must take place before multiplication with the frame size, since
each packet contains a whole number of frames.
We must also properly consider the data interval, as a larger data
interval will result in larger packets, which, depending on the sampling
frequency, can result in packet sizes that are less than integral
multiples of the packet size for a lower data interval.
Detailed explanation and rationale:
The code before this commit had the following expression on line 613 to
calculate the maximum isochronous packet size:
maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3))
>> (16 - ep->datainterval);
Here, ep->freqmax is the maximum assumed sample frequency, calculated from the
nominal sample frequency plus 25%. It is ultimately derived from ep->freqn,
which is in the units of frames per packet, from get_usb_full_speed_rate()
or usb_high_speed_rate(), as applicable, in Q16.16 format.
The expression essentially adds the Q16.16 equivalent of 0.999... (i.e.
the largest number less than one) to the sample rate, in order to get a
rate whose integer part is rounded up from the fractional value. The
multiplication with (frame_bits >> 3) yields the number of bytes in a
packet, and the (16 >> ep->datainterval) then converts it from Q16.16 back
to an integer, taking into consideration the bDataInterval field of the
endpoint descriptor (which describes how often isochronous packets are
transmitted relative to the (micro)frame rate (125us or 1ms, for USB high
speed and full speed, respectively)). For this discussion we will initially
assume a bDataInterval of 0, so the second line of the expression just
converts the Q16.16 value to an integer.
In order to illustrate the problem, we will set frame_bits 64, which
corresponds to a frame size of 8 bytes.
The problem here is twofold. First, the rounding operation consists
of the addition of 0x0.ffff and subsequent conversion to integer, but as the
expression stands, the conversion to integer is done after multiplication
with the frame size, rather than before. This results in the resulting
maxsize becoming too large.
Let's take an example. We have a sample rate of 96 kHz, so our ep->freqn is
0xc0000 (see usb_high_speed_rate()). Add 25% (line 612) and we get 0xf0000.
The calculated maxsize is then ((0xf0000 + 0x0ffff) * 8) >> 16 = 127 .
However, if we do the number of bytes calculation in a less obscure way it's
more apparent what the true corresponding packet size is: we get
ceil(96000 * 1.25 / 8000) * 8 = 120, where 1.25 is the 25% from line 612,
and the 8000 is the number of isochronous packets per second on a high
speed USB connection (125 us microframe interval).
This is fixed by performing the complete rounding operation prior to
multiplication with the frame rate.
The second problem is that when considering the ep->datainterval, this
must be done before rounding, in order to take the advantage of the fact
that if the number of bytes per packet is not an integer, the resulting
rounded-up integer is not necessarily a factor of two when the data
interval is increased by the same factor.
For instance, assuming a freqency of 41 kHz, the resulting
bytes-per-packet value for USB high speed is 41 kHz / 8000 = 5.125, or
0x52000 in Q16.16 format. With a data interval of 1 (ep->datainterval = 0),
this means that 6 frames per packet are needed, whereas with a data
interval of 2 we need 10.25, i.e. 11 frames needed.
Rephrasing the maxsize expression to:
maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) *
(frame_bits >> 3);
for the above 96 kHz example we instead get
((0xf0000 + 0xffff) >> 16) * 8 = 120 which is the correct value.
We can also do the calculation with a non-integer sample rate which is when
rounding comes into effect: say we have 44.1 kHz (resulting ep->freqn =
0x58333, and resulting ep->freqmax 0x58333 * 1.25 = 0x6e3ff (rounded down)):
Original maxsize = ((0x6e3ff + 0xffff) * 8) << 16 = 63 (63.124.. rounded down)
True maxsize = ceil(44100 * 1.25 / 8000) * 8 = 7 * 8 = 56
New maxsize = ((0x6e3ff + 0xffff) >> 16) * 8 = 7 * 8 = 56
This is also corroborated by the wMaxPacketSize check on line 616. Assume
that wMaxPacketSize = 104, with ep->maxpacksize then having the same value.
As 104 < 127, we get maxsize = 104. ep->freqmax is then recalculated to
(104 / 8) << 16 = 0xd0000 . Putting that rate into the original maxsize
calculation yields a maxsize of ((0xd0000 + 0xffff) * 8) >> 16 = 111
(with decimals 111.99988). Clearly, we should get back the 104 here,
which we would with the new expression: ((0xd0000 + 0xffff) >> 16) * 8 = 104 .
(The error has not been a problem because it only results in maxsize being
a bit too big which just wastes a couple of bytes, either as a result of
the first maxsize calculation, or because the resulting calculation will
hit the wMaxPacketSize value before the packet is too big, resulting in
fixing the size to wMaxPacketSize even though the packet is actually not
too long.)
Tested with an Edirol UA-5 both at 44.1 kHz and 96 kHz.
Signed-off-by: Ricard Wanderlof <ricardw@axis.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
|
|
Add the appropriate quirk to indicate the Lenovo G50-80 has a stereo
mic input where one channel has reverse polarity.
Alsa-info available at:
https://launchpadlibrarian.net/220846272/AlsaInfo.txt
Cc: stable@vger.kernel.org
BugLink: https://bugs.launchpad.net/bugs/1504778
Signed-off-by: David Henningsson <david.henningsson@canonical.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Compiling the hdac extended core on arm fails with below error:
sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_writel':
>> sound/hda/ext/hdac_ext_bus.c:29:2: error: implicit declaration of
>> function
+'writel' [-Werror=implicit-function-declaration]
writel(value, addr);
^
sound/hda/ext/hdac_ext_bus.c: In function 'hdac_ext_readl':
>> sound/hda/ext/hdac_ext_bus.c:34:2: error: implicit declaration of
>> function
+'readl' [-Werror=implicit-function-declaration]
return readl(addr);
This is fixed by explicitly including io.h
Fixes: 99463b3a3994 - ('ALSA: hda: provide default bus io ops extended hdac')
Reported-by: kbuild test robot <lkp@intel.com>
Suggested-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
It is not necessary to set registers volatile. So, return false
for default case of rt298_volatile_register.
Signed-off-by: Bard Liao <bardliao@realtek.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
s/SUR/SRU/g
Signed-off-by: Masanari Iida <standby24x7@gmail.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently, this driver picks up model name with be32_to_cpu() macro
to align characters. This is wrong operation because the result is
different depending on CPU endiannness.
Additionally, vendor released several versions of firmware for this
series. It's not better to assign model-dependent information to
device entry according to the version field.
This commit fixes these bugs. The name of model is picked up correctly
and used to identify model-dependent information.
Cc: Stefan Richter <stefanr@s5r6.in-berlin.de>
Fixes: c0949b278515 ('ALSA: firewire-tascam: add skeleton for TASCAM FireWire series')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
TASCAM FireWire series has some LEDs on its surface. These LEDs can be
turned on/off by receiving asynchronous transactions to a certain
address. One of the LEDs is labels as 'FireWire'. It's better to light it
up when this driver starts to work. Besides, the LED for 'FireWire' is
turned off at bus reset.
This commit implements this idea.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In former commits, this driver got functionalities to transfer/receive
MIDI messages to/from TASCAM FireWire series.
This commit adds some ALSA MIDI ports to enable userspace applications
to use the functionalities.
I note that this commit doesn't support virtual MIDI ports which console
models support. A physical controls can be assigned to a certain MIDI
ports including physical and virtual. But the way is not clear.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
asynchronous transaction
TASCAM FireWire series use asynchronous transaction to receive MIDI
messages. The transaction should be sent to a certain address.
This commit supports the outgoing MIDI messages. The messages in the
transaction includes some quirks:
* One MIDI message is transferred in one quadlet transaction, except for
system exclusives.
* MIDI running status is not allowed, thus transactions always include
status byte.
* The basic data format is the same as transferring MIDI messages
supported in previous commit.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
asynchronous transaction
TASCAM FireWire series use asynchronous transaction to transfer MIDI
messages. The transaction is sent to a registered address.
This commit supports the incoming MIDI messages. The messages in the
transaction include some quirks:
* Two quadlets are used for one MIDI message and one timestamp.
* Usually, the first byte of the first quadlet includes MIDI port and MSB
4 bit of MIDI status. For system exclusive message, the first byte
includes MIDI port and 0x04, or 0x07 in the end of the message.
* The rest of the first quadlet includes MIDI bytes up to 3.
* Several set of MIDI messages and timestamp can be transferred in one
block transaction, up to 8 sets.
I note that TASCAM FireWire series ignores ID bytes of system exclusive
message. When receiving system exclusive messages with ID bytes on physical
MIDI bus, the series transfers the messages without ID bytes on IEEE 1394
bus, and vice versa.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In former commits, asynchronous transactions are supported for physical
controls. This commit adds a pair of MIDI ports for them.
This driver already adds diferrent number of ALSA MIDI ports for physical
MIDI ports, and the number of in/out ports are different. As seeing as
'amidi' program in alsa-utils package, a pair of in/out MIDI ports is
expected with the same name. Therefore, this commit adds a pair of new
ports to the first.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
MIDI messages to physical controls
In previous commit, asynchronous transaction for incoming MIDI messages
from physical controls is supported. The physical controls may be
controlled by receiving MIDI messages at a certain address.
This commit supports asynchronous transaction for this purpose.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
MIDI messages from physical controls
Digi 00x series has two types of model; rack and console. The console
models have physical controls. The model can transmit control messages.
These control messages are transferred by asynchronous transactions to
registered address.
This commit supports the asynchronous transaction.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
isochronous packet streaming
This commit adds MIDI functionality to capture/playback MIDI messages
from/to physical MIDI ports. These messages are transferred in isochronous
packets.
When no substreams request AMDTP streams to run, this driver starts the
streams at current sampling rate. When other substreams start at different
sampling rate, the streams are stopped temporarily, then start again at
requested sampling rate. This operation can generate missing MIDI bytes,
thus it's preferable to start PCM substreams at favorite sampling rate in
advance.
Digi 002/003 console also has a set of MIDI port for physical controls.
These ports are added in later commits.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In Digi 002/003 protocol, MIDI messages are transferred in the last data
channel of data blocks. Although this data channel has a label of 0x80,
it's not fully MIDI conformant data channel especially because the Counter
field always zero independently of included MIDI bytes. The 4th byte of
the data channel in LSB tells the number of included MIDI bytes. This byte
also includes the number of MIDI port. Therefore, the data format in this
data channel is:
* 1st: 0x80 as label
* 2nd: MIDI bytes
* 3rd: 0 or MIDI bytes
* 4th: the number of MIDI byte and the number of MIDI port
This commit adds support of MIDI messages in data block processing layer.
Like AM824 data format, this data channel has a capability to transfer
more MIDI messages than the capability of phisical MIDI bus. Therefore, a
throttle for data rate is required to prevent devices' internal buffer to
overflow.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Original code for 'DoubleOhThree' encoding was written with '__u8' type,
while the type is usually used to export something to userspace.
This commit replaces the type with 'u8'.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
on newer Roland devices
This patch enables interrupt transfer mode for MIDI ports on newer
Boss/Roland devices such as the GT-100/001 which support interrupt
transfer on both IN and OUT MIDI endpoints. Previously this wasn't being
enabled for these devices as the code was specifically looking for the
scenario where the IN endpoint supported interrupt transfer and the OUT
endpoint was bulk transfer. Newer devices support interrupt transfer for
both endpoints.
This has been tested on Boss devices GT-001, BR-80 and JS-8 and Roland
VS-20.
It would benefit from some regresison testing with other devices if
possible.
Signed-off-by: Keith A. Milner <maillist@superlative.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
In firewire-lib, isochronous packet streaming is stopped when detecting
wrong value for FMT field of CIP headers. Although this is appropriate
to IEC 61883-1 and 6, some BeBoB based devices with vendors' customization
use invalid value to FMT field of CIP headers in the beginning of
streaming.
$ journalctl
snd-bebob fw1.0: Detect unexpected protocol: 01000000 8000ffff
I got this log with M-Audio FireWire 1814. In this line, the value of FMT
field is 0x00, while it should be 0x10 in usual AMDTP.
Except for the beginning, these devices continue to transfer packets with
valid value for FMT field, except for the beginning. Therefore, in this
case, firewire-lib should continue to process packets. The former
implementation of firewire-lib performs it.
This commit loosens the handling of wrong value, to continue packet
processing in the case.
Fixes: 414ba022a528 ('ALSA: firewire-lib: add support arbitrary value for fmt/fdf fields in CIP header')
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The structures of type snd_bebob_clock_spec, snd_bebob_rate_spec,
snd_bebob_meter_spec, and snd_bebob_spec are never modified after they are
initialized. Make them all const.
Done with the help of Coccinelle.
Signed-off-by: Julia Lawall <Julia.Lawall@lip6.fr>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
This ensures that the link is not requesting any clock and the
PLL can turn off. The link is powered when controller is brought
out of reset.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
On runtime pm resume, we need to download the firmware, also on
suspend we need to ensure all the interrupts from controller and
DSP are disabled.
Also since we download the firmware on resume, we don't need to do
so on init, so remove that bit
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Like we have in legacy mode HDA driver, we need to check the
status bit and handle interrupt only when it is not zero or all
bits set. We typically see the status as all 1's when controller
resumes from suspend, So add the check here as well and don't
handle for these cases.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Skylake driver will set the SPA bit to 0 to turn off the DSP core.
Driver will poll the Current Power Active (CPA) bit to match the
Set Power Active (SPA) bit value. When CPA bit matches the value
of SPA bit, the achieved power state has reached.
In case of DSP power down, register that was polled is SPA
instead of CPA. This patch corrects the register to be polled
in case of DSP power down.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Currently, when asynchronous transactions finish in error state and
retries, work scheduling and work running also continues. This
should be canceled at fatal error because it can cause endless loop.
This commit enables to cancel transferring MIDI messages when transactions
encounter fatal errors. This is achieved by setting error state.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Typically, the target devices have internal buffer to adjust output of
received MIDI messages for MIDI serial bus, while the capacity of the
buffer is limited. IEEE 1394 transactions can transfer more MIDI messages
than MIDI serial bus can. This can cause buffer over flow in device side.
This commit adds throttle to limit MIDI data rate by counting intervals
between two MIDI messages. Usual MIDI messages consists of two or three
bytes. This requires 1.302 to 1.953 mili-seconds interval between these
messages. This commit uses kernel monotonic time service to calculate the
time of next transaction.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
messages
Currently, when two MIDI trigger callbacks can be called immediately,
transactions for the second MIDI messages can be postpone till next trigger
callback. This is not good for real-time message transmission.
This commit schedules work again at response handling callback if the
MIDI substream still includes untransferred MIDI messages.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Currently, when waiting for a response, callers can start another
transaction by scheduling another work. This is not good for error
processing of transaction, especially the first response is too late.
This commit serialize request/response transactions, by adding one
boolean member to represent idling state.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
transfer MIDI messages
Some models receive MIDI messages via IEEE 1394 asynchronous transactions.
In this case, MIDI messages are transferred in fixed-length payload. It's
nice that firewire-lib module has common helper functions.
This commit implements this idea. Each driver adds
'struct snd_fw_async_midi_port' in its instance structure. In probing,
it should call snd_fw_async_midi_port_init() to initialize the
structure with some parameters such as target address, the length
of payload in a transaction and a pointer for callback function
to fill the payload buffer. At 'struct snd_rawmidi_ops.trigger()'
callback, it should call 'snd_fw_async_midi_port_run()' to start
transactions. Each driver should ensure that the lifetime of MIDI
substream continues till calling 'snd_fw_async_midi_port_finish()'.
The helper functions support retries to transferring MIDI messages when
transmission errors occur. When transactions are successful, the helper
functions call 'snd_rawmidi_transmit_ack()' internally to consume MIDI
bytes in the buffer. Therefore, Each driver is expected to use
'snd_rawmidi_transmit_peek()' to tell the number of bytes to transfer to
return value of 'fill' callback.
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd_seq_oss_readq_put_event() seems to be missing a memory barrier which
might cause the waker to not notice the waiter and miss sending a
wake_up as in the following figure.
snd_seq_oss_readq_put_event snd_seq_oss_readq_wait
------------------------------------------------------------------------
/* wait_event_interruptible_timeout */
/* __wait_event_interruptible_timeout */
/* ___wait_event */
for (;;) { prepare_to_wait_event(&wq, &__wait,
state);
spin_lock_irqsave(&q->lock, flags);
if (waitqueue_active(&q->midi_sleep))
/* The CPU might reorder the test for
the waitqueue up here, before
prior writes complete */
if ((q->qlen>0 || q->head==q->tail)
...
__ret = schedule_timeout(__ret)
if (q->qlen >= q->maxlen - 1) {
memcpy(&q->q[q->tail], ev, sizeof(*ev));
q->tail = (q->tail + 1) % q->maxlen;
q->qlen++;
------------------------------------------------------------------------
There are two other place in sound/core/seq/oss/ which have similar
code. The attached patch removes the call to waitqueue_active() leaving
just wake_up() behind. This fixes the problem because the call to
spin_lock_irqsave() in wake_up() will be an ACQUIRE operation.
I found this issue when I was looking through the linux source code
for places calling waitqueue_active() before wake_up*(), but without
preceding memory barriers, after sending a patch to fix a similar
issue in drivers/tty/n_tty.c (Details about the original issue can be
found here: https://lkml.org/lkml/2015/9/28/849).
Signed-off-by: Kosuke Tatsukawa <tatsu@ab.jp.nec.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Now that we have introduced the core fns we should make hda use these
helpers
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The current codec helpers are local to hda code and needs to be moved to
core so that other users can use it.
The helpers to read/write the codec and to check the
power state of widgets is copied
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
We were getting build warning about "Section mismatch".
dmi_platform_intel_broadwell is being referenced from the probe function
rt5645_i2c_probe(), but dmi_platform_intel_broadwell was marked with
__initdata.
Signed-off-by: Sudip Mukherjee <sudip@vectorindia.org>
Reviewed-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add a driver for the SPDIF transceiver available on RK3066, RK3188 and
RK3288. Heavily based on the rockchip i2s driver.
Signed-off-by: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
This patch adds the acpi match ID for nau8825 codec
Signed-off-by: Fang, Yang A <yang.a.fang@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
dev_info is too noisy for tplg wiget loading, so move it to
debug level
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus
ASoC: Fixes for v4.3
Quite a few fixes here but they're all very small and driver specific,
none of them really stand out if you aren't using the relevant hardware
but they're all useful if you do happen to have an affected device.
|
|
into asoc-linus
|
|
'asoc/fix/imx-ssi', 'asoc/fix/maintainers', 'asoc/fix/rt5645', 'asoc/fix/sgtl5000' and 'asoc/fix/tas2552' into asoc-linus
|
|
Load and Initialize Non HDA Link Table in Skylake driver
to get platform configuration.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
If processing pipe capability is supported, add DSP support.
Adds initialization/free/suspend/resume DSP functionality.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Initialize and creates DSP controls if processing pipe capability
is supported by HW. Updates the dma_id, hw_params to module param
to be used when DSP module has to be configured.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The SKL driver does not code DSP topology in driver. It uses the
newly added ASoC topology core to parse the topology information
(controls, widgets and map) from topology binary.
Each topology element passed private data which contains
information that driver used to identify the module instance
within firmware and send IPCs for that module to DSP firmware
along with parameters.
This patch adds init routine to invoke topology load and callback
for topology creation.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
For FE and BE, the PCM parameters come from FE and BE hw_params
values passed. For a FE we convert the FE params to DSP expected
module format and pass to DSP. For a BE we need to find the
gateway settings (i2s/PDM) to be applied. These are queried from
NHLT table and applied.
Further for BE based on direction the settings are applied as
either source or destination parameters.
These helpers here allow the format to be calculated and queried
as per firmware format.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
The Skylake driver topology model tries to model the firmware
rule for pipeline and module creation.
The creation rule is:
- Create Pipe
- Add modules to Pipe
- Connect the modules (bind)
- Start the pipes
Similarly destroy rule is:
- Stop the pipe
- Disconnect it (unbind)
- Delete the pipe
In driver we use Mixer, as there will always be ONE mixer in a
pipeline to model a pipe. The modules in pipe are modelled as PGA
widgets. The DAPM sequencing rules (mixer and then PGA) are used
to create the sequence DSP expects as depicted above, and then
widget handlers for PMU and PMD events help in that.
This patch adds widget event handlers for PRE/POST PMU and
PRE/POST PMD event for mixer and pga modules. These event
handlers invoke pipeline creation, destroy, module creation,
module bind, unbind and pipeline bind unbind
Event handler sequencing is implement to target the DSP FW
sequence expectations to enable path from source to sink pipe for
Playback/Capture.
Signed-off-by: Jeeja KP <jeeja.kp@intel.com>
Signed-off-by: Hardik T Shah <hardik.t.shah@intel.com>
Signed-off-by: Subhransu S. Prusty <subhransu.s.prusty@intel.com>
Signed-off-by: Vinod Koul <vinod.koul@intel.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
|
