| Age | Commit message (Collapse) | Author |
|---|
|
# Conflicts:
# net/ceph/osd_client.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
|
# Conflicts:
# drivers/gpu/drm/xe/xe_pagefault.c
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
|
|
https://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound.git
|
|
|
|
The Behringer FCA1616 (1397:0004) returns silent capture samples unless its
playback endpoint is active.
Use the existing fixed implicit-feedback mechanism to keep playback endpoint
0x01 on interface 1 active during capture.
Tested with 16-channel S32_LE capture at 44.1 and 48 kHz.
Signed-off-by: Kitty Makin <autumnull@posteo.net>
Link: https://patch.msgid.link/20260914002334.12691-1-autumnull@posteo.net
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
On the HP OMEN 15 ax-202nf, the keyboard mute LED is exposed through
NID 0x1b rather than 0x18. This reuses the existing quirk
(ALC269_FIXUP_HP_MUTE_LED_MIC3) to allow the keyboard LED to reflect
the built-in speaker mute state.
Tested on HP OMEN 15 ax-202nf with Realtek ALC295:
- hda::mute/brightness properly follows mute state
- mute/unmute via keyboard shortcut or via GUI volume control
- state is kept on suspend & resume, and reboot
- plugging a 3.5mm jack headset reflects the headset mute status
- unplugging reverts the LED to the speaker mute status
- USB/Bluetooth headsets are not covered
Signed-off-by: Xavier Goffin <xaviergoffin42@gmail.com>
Link: https://patch.msgid.link/20260913211155.20305-1-xaviergoffin42@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The Pioneer DJ DDJ-SZ exposes its audio interface as USB vendor-specific
class (0xFF) rather than USB Audio Class, so it needs a quirks-table
entry like its sibling Pioneer devices (DJM-750, DJM-850, DJM-900NXS2,
DJM-450, DJM-V10) already have.
The device presents 10 channels of S24_3LE audio in both directions,
fixed at 44.1kHz, on interface 0 altsetting 1: playback on endpoint
0x01, capture on endpoint 0x82. The unit contains its own analog mixer,
and each playback channel pair feeds one of its physical channel strips:
0/1, 2/3, 4/5 and 6/7 feed strips 1-4 respectively, and 8/9 feed the
booth output. The master output is produced in analog by that mixer and
is not carried over USB at all. On the capture side, channels 8/9 are
the mic input; capture channels 0-7 are not yet mapped to specific
physical inputs.
Implicit feedback needs no quirk flag here: is_pioneer_implicit_fb() in
implicit.c already covers vendor 0x08e4 with a vendor-spec class
interface and two endpoints, and the driver duly reports endpoint 0x82
as the playback sync endpoint.
Activation reuses the existing pioneer_djm_set_format_quirk() used by
the DJM-750/850/900NXS2/450/V10 (SET_INTERFACE to altsetting 1, then a
UAC-shaped SET_CUR sample-rate control transfer) with this device's own
captured wIndex (0x0082). Unlike those devices, the DDJ-SZ additionally
needs a vendor "arm" sequence before its capture path produces real
audio -- without it, capture opens and runs with no USB/ALSA errors
but delivers silence (a hard zero on every channel) rather than any
error, so this is easy to miss. The arm sequence is six vendor control
transfers (bmRequestType=0x40, bRequest=3, varying wValue/wIndex, each
followed by a bmRequestType=0xc0, bRequest=0 status read), replicated
byte-for-byte from a USB capture of the official Windows driver.
All of the above -- endpoint numbers, format, channel mapping, and the
arm sequence bytes -- were determined by capturing and decoding real USB
traffic from the Windows driver (USBPcap + Wireshark) during
enumeration, playback, and mic recording, then verifying the format
hypothesis against actual de-interleaved payload data rather than
packet-size arithmetic alone. Both playback and capture have been
verified working with real audio, not just clean enumeration.
Signed-off-by: Hanh Kieu <hhkieu@gmail.com>
Link: https://patch.msgid.link/20260903231641.18536-1-hhkieu@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Add support for optional reset/enable gpios as per the trivial-codec.yaml
bindings that cover this basic PCM5102A driver. Some addons gate the
PCM5102A's supply through an external GPIO, and rather than forcing
this by using a manual config to drive the GPIO high use the documented
mechanism to do this. Based on similar functionality in the pcm1789 driver.
Signed-off-by: Peter Robinson <pbrobinson@gmail.com>
Link: https://patch.msgid.link/20260912082422.331962-1-pbrobinson@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add DMI entry for Huawei Matebook B3-420 (BDZ-WXX9) with HEADPHONE_GPIO
and HEADSET_MIC1 quirks.
Similar to Huawei Matebook D (BOD-WXX9).
On the same machine,audio routing between speakers and headphones works
correctly when running Windows with the Huawei audio driver.
However, after reinstalling Linux, both the speakers and headphones output
sound simultaneously,indicating that the amplifier enable GPIOs are not
being toggled correctly to separate the two outputs.
Signed-off-by: Ai Chao <aichao@kylinos.cn>
Link: https://patch.msgid.link/20260911081932.2605407-1-aichao@kylinos.cn
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Richard Fitzgerald <rf@opensource.cirrus.com> says:
Struct snd_soc_dai_link_ch_map had a single mask member to set the
CPU channel masks. But no fixup was done to the codec end of the link.
For example if a 4-channel CPU capture DAI was made from two codecs both
supplying 2 channels, the hw_params() of the codec would be passed a
channel count of 4.
On SoundWire this could cause multiple codecs to send data in the same
bits of a frame because the unused channels were not disabled.
The changes in this series are:
- Separate channel masks for CPU and codec in struct
snd_soc_dai_link_ch_map .
- Apply the codec channel mask as a channel count fixup if the machine
drive has not set a TDM mask.
- Set the codec channel mask in the SoundWire machine driver.
- Remove the workaround from the cs_amp machine driver.
Link: https://patch.msgid.link/20260910114500.1586637-1-rf@opensource.cirrus.com
|
|
Delete the asoc_sdw_cs_spk_feedback_rtd_init(). This is not needed now
that the ASoC bug it was working around has been fixed. And it was broken
anyway because it didn't match the way the core SoundWire code mapped
codec channels to frame bitslots.
This code was added to avoid a problem where multiple codec DP outputs
were mapped to the same SoundWire frame bit slot. This would allow a
user to break the SoundWire bus just by enabling mixer outputs using
ALSA controls.
As no production system has used the capture stream, this workaround
was of little consequence and the problem of conflicting DP mappings
was not investigated.
The ASoC bug that enabled too many channels on each codec has now been
fixed. So this workaround can be completely deleted.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260910114500.1586637-6-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In asoc_sdw_hw_params() set the codec_ch_mask member of struct
snd_soc_dai_link_ch_map for capture streams. ASoC will then pass the
correct number of channels to each codec hw_params(). This prevents
trying to enable more channels on the codec DP than have been allocated
bitslots in the SoundWire frame, which would cause bus clash errors.
In theory codec_ch_mask could also be set for playback streams, but for
those the CPU is the only sender so there is no risk of bus clash.
For playback streams codec_ch_mask is set to 0 to preserve the existing
behavior and avoid introducing bugs.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260910114500.1586637-5-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In __soc_pcm_hw_params() if there is a snd_soc_dai_link_ch_map with
non-zero codec_ch_mask, use that channel mask to restrict which channels
are enabled on the codec. But only if there isn't a TDM mask.
It is possible that a snd_soc_dai_link_ch_map could include the same codec
multiple times on different CPUs so the for_each_rtd_ch_maps() loop
accumulates the channel masks for all entries of that codec.
If a TDM mask was also set, it takes priority and is used instead of any
possible snd_soc_dai_link_ch_map entries. (They cannot be ANDed together
because the bit positions are indicating different things: TDM is a bit
for each TDM slot, codec_ch_mask is a bit for each codec channel.)
This fixes a problem of incorrect TX channels enabled on the codec when
multiple codecs are aggregated on a single capture link. For example:
- Two CPUs with six 4-channel codecs.
- The machine driver chooses to assign one channel from each codec to
one channel on the CPU
- But the codec hw_params() would be passed a channel count of 6, which
(a) is more channels than the codec has and (b) allows enabling channels
that should not be driving the audio bus.
Fixes: ac950278b087 ("ASoC: add N cpus to M codecs dai link support")
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260910114500.1586637-4-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Rename the ch_mask member of snd_soc_dai_link_ch_map to cpu_ch_mask,
as that is what it is used for.
The CPU and codec channel masks are not necessarily the same, and are
quite likely different. SoundWire and I2S/TDM both support assigning
different sample slots to each codec, so for example channel 0 on each
codec could map to different channels at the CPU. So it's quite normal
that the channel mask at the CPU end is different for each codec, but
the codec channel masks are the same for each codec.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260910114500.1586637-2-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Add pll2 reconfiguration sequence in order to fix calibration
time-out issue and to support 24.576MHz MCLK on specific platforms.
Signed-off-by: Jack Yu <jack.yu@realtek.com>
Link: https://patch.msgid.link/20260909085449.862350-1-jack.yu@realtek.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
In wm_adsp_request_firmware_file() only log the "Failed to request
FILENAME" message when there is a real error (not when the file is
missing). Add a new debug message to log the sequence of filenames tried
during the file search.
People have enabled debug messages, seen the "Failed to request" messages
that are only logging the normal file search sequence, and reported them
as errors.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://patch.msgid.link/20260910121047.1592541-1-rf@opensource.cirrus.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
snd_pcm_timer_init() calls snd_device_register() to link the new
struct snd_timer into the global timer list while it still carries
hw.c_resolution = snd_pcm_timer_resolution (and hw.start/hw.stop),
and only afterwards sets timer->private_data = substream.
Once the timer is on the list under register_mutex, a concurrent
reader can already reach it through the same mutex and invoke these
callbacks. /proc/asound/timers does this via c_resolution(), and
snd_timer_open()+snd_timer_start() reach start()/stop() the same way.
All three dereference timer->private_data, which for this brief
window is NULL, giving a NULL-pointer dereference:
substream = timer->private_data;
return substream->runtime ? ... // substream is NULL
Move the private_data/private_free assignment before
snd_device_register() so the timer is never visible on the list
without its private_data set. On the snd_device_register() failure
path, private_free() (snd_pcm_timer_free()) can now run, but it only
does substream->timer = NULL, which is already NULL at that point
since substream->timer is set to the new timer just once, after a
successful registration -- so the failure path stays safe.
Reported-by: syzbot+19da64013c46df87f971@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=19da64013c46df87f971
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Signed-off-by: Nguyen Ngoc Thang <ngocthang2710.1999@gmail.com>
Link: https://patch.msgid.link/20260913134446.114724-1-ngocthang2710.1999@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
virtsnd_remove() and virtsnd_freeze() delete the virtqueues before
resetting the device. del_vqs() frees the vring backing, but does not
provide a generic device quiesce operation. In particular, modern
virtio-pci keeps enabled queues active until the device is reset.
Reset the device before deleting the virtqueues so it can no longer
access the vring memory when that memory is released. This also covers
probe failures after DRIVER_OK, which unwind through virtsnd_remove().
Fixes: de3a9980d8c3 ("ALSA: virtio: add virtio sound driver")
Fixes: 575483e90a32 ("ALSA: virtio: introduce device suspend/resume support")
Cc: stable@vger.kernel.org
Signed-off-by: Yuho Choi <oss.patchbox@gmail.com>
Link: https://patch.msgid.link/20260911031121.1542502-1-oss.patchbox@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The hda-acpi platform driver never enables runtime PM, so
pm_runtime_force_suspend() in hda_acpi_suspend() skips the runtime
callbacks. On resume the controller is therefore never re-initialised:
azx_init_chip() is called only at probe time, so after S3 the codec
verbs time out and audio is dead until the driver is rebound.
Add explicit runtime_suspend/runtime_resume callbacks and invoke them
from the system-sleep paths, mirroring the pattern used by snd-hda-intel.
Tested on an arm64 platform with the NVDA2014 controller: resume latency
drops from 81.5 s to 3.6 s and audio is live immediately after wake.
Signed-off-by: David Cemin <dcemin@nvidia.com>
Link: https://patch.msgid.link/20260912182120.1156356-1-dcemin@nvidia.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Usually a sound driver releases the resources assigned to the card via
snd_card_free(), and it synchronizes with the whole release procedure.
However, when the card is released asynchronously via
snd_card_free_when_closed() like USB-audio driver, the situation is
slightly different; although the snd_card_disconnect() call at the
disconnection guarantees that any newer accesses will be gated, the
in-flight tasks might be still accessing to the underlying card->dev
device even after the disconnection, which would cause a
use-after-free in the end, as reported by fuzzers.
For addressing the bug above, this patch takes the refcount of
card->dev at initialization of the card object, and releases at its
destructor. This assures the availability of the card->dev in its
whole lifecycle.
Reported-by: Farhad Alemi <farhad.alemi@berkeley.edu>
Closes: https://lore.kernel.org/CA+0ovChexj4TrZL_2iG_P0WBEbZc5+73GfB3DkciQi=R8pZOnA@mail.gmail.com
Closes: https://lore.kernel.org/CA+0ovCgQUQNN=Z1tJTouiCsDaXR5M-3-SQEGk-cpPXQkM5Xh+w@mail.gmail.com
Cc: <stable@vger.kernel.org>
Link: https://patch.msgid.link/20260912162150.455144-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
data_ep_set_params() allocates each data URB for exactly u->packets
isochronous frames, so urb->iso_frame_desc[] has u->packets slots and
ctx->packets is the driver's only record of that limit. For an implicit
feedback sink, snd_usb_queue_pending_output_urbs() overwrites it with the
sync source's packet count, which is calculated independently from the
capture endpoint's parameters. When that count is larger,
prepare_playback_urb() and prepare_silent_urb() can write
iso_frame_desc[] past the allocation; their existing bounds limit payload
bytes, not the descriptor index.
The reproducer uses a high-speed UAC2 device declaring bInterval 1 for
implicit feedback capture (8 packets) and bInterval 4 for playback
(1 packet). On the first capture completion after the stream starts, it
accesses seven descriptors spanning 112 bytes beyond the one-packet URB:
BUG: KASAN: slab-out-of-bounds in prepare_playback_urb (sound/usb/pcm.c:1560)
Write of size 4 at addr ffff88801e696ad0 by task vhci_rx/178
prepare_playback_urb (sound/usb/pcm.c:1560)
prepare_outbound_urb (sound/usb/endpoint.c:340)
snd_usb_queue_pending_output_urbs (sound/usb/endpoint.c:501)
snd_complete_urb (sound/usb/endpoint.c:1834)
__usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1657)
usb_hcd_giveback_urb (drivers/usb/core/hcd.c:1741)
vhci_rx_loop (drivers/usb/usbip/vhci_rx.c:107)
kthread (kernel/kthread.c:436)
The buggy address belongs to the object at ffff88801e696a00
which belongs to the cache kmalloc-256 of size 256
The buggy address is located 0 bytes to the right of
allocated 208-byte region [ffff88801e696a00, ffff88801e696ad0)
Record the allocated packet count per endpoint and clamp both the adopted
count and the packet-size copy to it. Fold the Format Type II delimiter
into urb_packs before the allocation loop so the recorded limit matches
every URB.
Fixes: cf044e441902 ("ALSA: usb-audio: Update the number of packets properly at receiving")
Reported-by: co+8eacd4fa193b1b28@bugs.sh
Closes: https://lore.kernel.org/all/22xPn8drvIUtYgVeQnBiNqXuevOTpBAjepLz%40bugs.sh/
Cc: stable@vger.kernel.org
Assisted-by: Claude:claude-opus-5
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Link: https://patch.msgid.link/20260912200530.1955491-1-xmei5@asu.edu
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Although we tried to fix the potential UAF issues at USB disconnect on
bcd2000 driver, there is still an overlooked case -- namely, when a
rawmidi trigger callback has been already running at USB disconnect
handling, the in-flight function (e.g. bcd2000_midi_send()) could
still access the URB, because the previous URB NULL-check & clearance
was considered only for the URB complete callbacks, but not about the
parallel rawmidi operations.
For addressing the race, this patch introduced a new spinlock that
covers each rawmidi operation as well as the rawmidi handling in the
complete callback. The URB is cleared with the lock, so it guarantees
that the pending rawmidi task already finished or a NULL check is
effective.
Fixes: 459d3a64766f ("ALSA: bcd2000: clear the URB pointers on disconnect")
Link: https://patch.msgid.link/20260910155227.996210-1-tiwai@suse.de
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
The mute LED on this board does not respond to mute state changes
because no fixup is matched for SSID 103c:8bb1. The reporter
verified the LED can be toggled manually via COEF index 0x0B.
Reported-by: Mazen Ahmed <mazen001.ahmed001@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221982
Tested-by: Mazen Ahmed <mazen001.ahmed001@gmail.com>
Signed-off-by: Krish Gulati <krishgulati7@gmail.com>
Link: https://patch.msgid.link/20260912070618.21272-1-krishgulati7@gmail.com
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
I'm now posting "use .auto_selectable_formats" for Codecs.
This is "use .auto_selectable_formats" for each vendor.
o: done
y: now posting
x: this patch-set
[o] Step1: ASoC: a to b
[y] Step2: ASoC: codec: ...
[x] Step3: ASoC: d to x
Current ASoC supports snd_soc_daifmt_parse_format() which can specify DAI
format by "dai-format" property from DT.
But strictly speaking, it is SW settings, so doesn't match to DT's policy.
Current ASoC is supporting auto format select via
snd_soc_dai_ops :: .auto_selectable_formats.
But the user is very few today.
DT doesn't need to specify the DAI format via "dai-format", if both CPU
and Codec drivers were supporting .auto_selectable_formats. It will be
automatically selected from .auto_selectable_formats.
One note is that auto select might not find best format on some CPU/Codec
combination. So "dai-format" property itself is necessary anyway.
Link: https://patch.msgid.link/87zexzyw5v.wl-kuninori.morimoto.gx@renesas.com
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/875x0nyw3d.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/877bl3yw3g.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/878q5jyw3k.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87a4pzyw3o.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://patch.msgid.link/87bjafyw3s.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87cxuvyw3v.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87ecfbyw3z.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87fqzryw42.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87ik4nyw4a.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87jyp3yw4d.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87ld9jyw4i.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87mrtzyw4m.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87pkyvyw4t.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87qzjbyw4x.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87se3ryw50.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87tso7yw53.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87v78nyw57.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/87y0djyw5g.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> says:
This is v3 of Step2 of "use .auto_selectable_formats" patch-set
o: done
x: this patch-set
[o] Step1: ASoC: a to b
[x] Step2: ASoC: codec: ...
[ ] Step3: ASoC: d to r
[ ] Step4: ASoC: r to x
Current ASoC supports snd_soc_daifmt_parse_format() which can specify DAI
format by "dai-format" property from DT.
But strictly speaking, it is SW settings, so doesn't match to DT's policy.
Current ASoC is supporting auto format select via
snd_soc_dai_ops :: .auto_selectable_formats.
But the user is very few today.
DT doesn't need to specify the DAI format via "dai-format", if both CPU
and Codec drivers were supporting .auto_selectable_formats. It will be
automatically selected from .auto_selectable_formats.
One note is that auto select might not find best format on some CPU/Codec
combination. So "dai-format" is necessary anyway.
Link: https://lore.kernel.org/r/87cxvyyazi.wl-kuninori.morimoto.gx@renesas.com
Link: https://lore.kernel.org/r/877bm2vjjn.wl-kuninori.morimoto.gx@renesas.com
Link: https://patch.msgid.link/87o6eivpyd.wl-kuninori.morimoto.gx@renesas.com
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/874igaub8v.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/875x0qub8y.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/877bl6ub93.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
|
We can use .auto_selectable_formats. Let's adds it.
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Link: https://patch.msgid.link/878q5mub97.wl-kuninori.morimoto.gx@renesas.com
Signed-off-by: Mark Brown <broonie@kernel.org>
|
