Merge/sound upstream 20250114#5288
Merged
bardliao merged 1062 commits intothesofproject:topic/sof-devfrom Jan 16, 2025
Merged
Conversation
…selftest Fixup the uc_attr_mem_limit test case to also cover the KVM_HAS_DEVICE_ATTR ioctl. Signed-off-by: Christoph Schlameuss <schlameuss@linux.ibm.com> Tested-by: Hariharan Mari <hari55@linux.ibm.com> Reviewed-by: Claudio Imbrenda <imbrenda@linux.ibm.com> Link: https://lore.kernel.org/r/20241216092140.329196-7-schlameuss@linux.ibm.com Message-ID: <20241216092140.329196-7-schlameuss@linux.ibm.com> Signed-off-by: Claudio Imbrenda <imbrenda@linux.ibm.com>
The ALC5682I-VD and ALC5682I-VE use the same I2C codec driver with different calibration settings. This patch aims to handle their differences. Signed-off-by: Derek Fang <derek.fang@realtek.com> Link: https://patch.msgid.link/20241225094307.3678837-1-derek.fang@realtek.com Signed-off-by: Mark Brown <broonie@kernel.org>
Use the standard helper str_on_off() to simplify the code. Only code refactoring, no behavior change. Link: https://patch.msgid.link/20250107155641.4435-2-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use the standard helper str_off_on() to simplify the code. Only code refactoring, no behavior change. Link: https://patch.msgid.link/20250107155641.4435-3-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use the standard helper str_on_off() to simplify the code. Only code refactoring, no behavior change. Link: https://patch.msgid.link/20250107155641.4435-4-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use the standard helper str_on_off() to simplify the code. Only code refactoring, no behavior change. Link: https://patch.msgid.link/20250107155641.4435-5-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use the standard helper str_enabled_disabled() to simplify the code. Only code refactoring, no behavior change. Link: https://patch.msgid.link/20250107155641.4435-7-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
Use the standard helper str_enable_disable() to simplify the code. Only code refactoring, no behavior change. Link: https://patch.msgid.link/20250107155641.4435-8-tiwai@suse.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
During fuzz testing, the following warning was discovered:
different return values (15 and 11) from vsnprintf("%*pbl
", ...)
test:keyward is WARNING in kvasprintf
WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130
Call Trace:
kvasprintf+0x121/0x130
kasprintf+0xa6/0xe0
bitmap_print_to_buf+0x89/0x100
core_siblings_list_read+0x7e/0xb0
kernfs_file_read_iter+0x15b/0x270
new_sync_read+0x153/0x260
vfs_read+0x215/0x290
ksys_read+0xb9/0x160
do_syscall_64+0x56/0x100
entry_SYSCALL_64_after_hwframe+0x78/0xe2
The call trace shows that kvasprintf() reported this warning during the
printing of core_siblings_list. kvasprintf() has several steps:
(1) First, calculate the length of the resulting formatted string.
(2) Allocate a buffer based on the returned length.
(3) Then, perform the actual string formatting.
(4) Check whether the lengths of the formatted strings returned in
steps (1) and (2) are consistent.
If the core_cpumask is modified between steps (1) and (3), the lengths
obtained in these two steps may not match. Indeed our test includes cpu
hotplugging, which should modify core_cpumask while printing.
To fix this issue, cache the cpumask into a temporary variable before
calling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged
during the printing process.
Fixes: bb9ec13 ("topology: use bin_attribute to break the size limitation of cpumap ABI")
Cc: stable <stable@kernel.org>
Signed-off-by: Li Huafei <lihuafei1@huawei.com>
Reviewed-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Link: https://lore.kernel.org/r/20241114110141.94725-1-lihuafei1@huawei.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Mask admin command returned max phase adjust value for both input and
output pins. Only 31 bits are relevant, last released data sheet wrongly
points that 32 bits are valid - see [1] 3.2.6.4.1 Get CCU Capabilities
Command for reference. Fix of the datasheet itself is in progress.
Fix the min/max assignment logic, previously the value was wrongly
considered as negative value due to most significant bit being set.
Example of previous broken behavior:
$ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \
--do pin-get --json '{"id":1}'| grep phase-adjust
'phase-adjust': 0,
'phase-adjust-max': 16723,
'phase-adjust-min': -16723,
Correct behavior with the fix:
$ ./tools/net/ynl/cli.py --spec Documentation/netlink/specs/dpll.yaml \
--do pin-get --json '{"id":1}'| grep phase-adjust
'phase-adjust': 0,
'phase-adjust-max': 2147466925,
'phase-adjust-min': -2147466925,
[1] https://cdrdv2.intel.com/v1/dl/getContent/613875?explicitVersion=true
Fixes: 90e1c90 ("ice: dpll: implement phase related callbacks")
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Signed-off-by: Arkadiusz Kubalewski <arkadiusz.kubalewski@intel.com>
Tested-by: Pucha Himasekhar Reddy <himasekharx.reddy.pucha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
ptp4l application reports too high offset when ran on E823 device with a 100GB/s link. Those values cannot go under 100ns, like in a working case when using 100 GB/s cable. This is due to incorrect frequency settings on the PHY clocks for 100 GB/s speed. Changes are introduced to align with the internal hardware documentation, and correctly initialize frequency in PHY clocks with the frequency values that are in our HW spec. To reproduce the issue run ptp4l as a Time Receiver on E823 device, and observe the offset, which will never approach values seen in the PTP working case. Reproduction output: ptp4l -i enp137s0f3 -m -2 -s -f /etc/ptp4l_8275.conf ptp4l[5278.775]: master offset 12470 s2 freq +41288 path delay -3002 ptp4l[5278.837]: master offset 10525 s2 freq +39202 path delay -3002 ptp4l[5278.900]: master offset -24840 s2 freq -20130 path delay -3002 ptp4l[5278.963]: master offset 10597 s2 freq +37908 path delay -3002 ptp4l[5279.025]: master offset 8883 s2 freq +36031 path delay -3002 ptp4l[5279.088]: master offset 7267 s2 freq +34151 path delay -3002 ptp4l[5279.150]: master offset 5771 s2 freq +32316 path delay -3002 ptp4l[5279.213]: master offset 4388 s2 freq +30526 path delay -3002 ptp4l[5279.275]: master offset -30434 s2 freq -28485 path delay -3002 ptp4l[5279.338]: master offset -28041 s2 freq -27412 path delay -3002 ptp4l[5279.400]: master offset 7870 s2 freq +31118 path delay -3002 Fixes: 3a74962 ("ice: implement basic E822 PTP support") Reviewed-by: Milena Olech <milena.olech@intel.com> Signed-off-by: Przemyslaw Korba <przemyslaw.korba@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
When booting with a dock connected, the igc driver may get stuck for ~40 seconds if PCIe link is lost during initialization. This happens because the driver access device after EECD register reads return all F's, indicating failed reads. Consequently, hw->hw_addr is set to NULL, which impacts subsequent rd32() reads. This leads to the driver hanging in igc_get_hw_semaphore_i225(), as the invalid hw->hw_addr prevents retrieving the expected value. To address this, a validation check and a corresponding return value catch is added for the EECD register read result. If all F's are returned, indicating PCIe link loss, the driver will return -ENXIO immediately. This avoids the 40-second hang and significantly improves boot time when using a dock with an igc NIC. Log before the patch: [ 0.911913] igc 0000:70:00.0: enabling device (0000 -> 0002) [ 0.912386] igc 0000:70:00.0: PTM enabled, 4ns granularity [ 1.571098] igc 0000:70:00.0 (unnamed net_device) (uninitialized): PCIe link lost, device now detached [ 43.449095] igc_get_hw_semaphore_i225: igc 0000:70:00.0 (unnamed net_device) (uninitialized): Driver can't access device - SMBI bit is set. [ 43.449186] igc 0000:70:00.0: probe with driver igc failed with error -13 [ 46.345701] igc 0000:70:00.0: enabling device (0000 -> 0002) [ 46.345777] igc 0000:70:00.0: PTM enabled, 4ns granularity Log after the patch: [ 1.031000] igc 0000:70:00.0: enabling device (0000 -> 0002) [ 1.032097] igc 0000:70:00.0: PTM enabled, 4ns granularity [ 1.642291] igc 0000:70:00.0 (unnamed net_device) (uninitialized): PCIe link lost, device now detached [ 5.480490] igc 0000:70:00.0: enabling device (0000 -> 0002) [ 5.480516] igc 0000:70:00.0: PTM enabled, 4ns granularity Fixes: ab40561 ("igc: Add NVM support") Cc: Chia-Lin Kao (AceLan) <acelan.kao@canonical.com> Signed-off-by: En-Wei Wu <en-wei.wu@canonical.com> Reviewed-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Some entries use my kernel.org address, while others use my Red Hat one. Since this is a bit of an inconvinience for me, align them to all use the same (kernel.org) address. Signed-off-by: Danilo Krummrich <dakr@kernel.org> Link: https://lore.kernel.org/r/20241204152248.8644-1-dakr@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
…rride[] Like the Vivobook X1704VAP the X1504VAP has its keyboard IRQ (1) described as ActiveLow in the DSDT, which the kernel overrides to EdgeHigh which breaks the keyboard. Add the X1504VAP to the irq1_level_low_skip_override[] quirk table to fix this. Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219224 Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241220181352.25974-1-hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
The TongFang GM5HG0A is a TongFang barebone design which is sold under various brand names. The ACPI IRQ override for the keyboard IRQ must be used on these AMD Zen laptops in order for the IRQ to work. At least on the SKIKK Vanaheim variant the DMI product- and board-name strings have been replaced by the OEM with "Vanaheim" so checking that board-name contains "GM5HG0A" as is usually done for TongFang barebones quirks does not work. The DMI OEM strings do contain "GM5HG0A". I have looked at the dmidecode for a few other TongFang devices and the TongFang code-name string being in the OEM strings seems to be something which is consistently true. Add a quirk checking one of the DMI_OEM_STRING(s) is "GM5HG0A" in the hope that this will work for other OEM versions of the "GM5HG0A" too. Link: https://www.skikk.eu/en/laptops/vanaheim-15-rtx-4060 Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219614 Cc: All applicable <stable@vger.kernel.org> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://patch.msgid.link/20241228164845.42381-1-hdegoede@redhat.com Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
acpi_dev_irq_override() gets called approx. 30 times during boot (15 legacy IRQs * 2 override_table entries). Of these 30 calls at max 1 will match the non DMI checks done by acpi_dev_irq_override(). The dmi_check_system() check is by far the most expensive check done by acpi_dev_irq_override(), make this call the last check done by acpi_dev_irq_override() so that it will be called at max 1 time instead of 30 times. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Link: https://patch.msgid.link/20241228165253.42584-1-hdegoede@redhat.com [ rjw: Subject edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Merge series from Stephen Gordon <gordoste@iinet.net.au>: Some minor tweaks to debugging for dai_links.
Merge series from wangweidong.a@awinic.com: Add the awinic,aw88083 property to support the aw88083 chip. The driver is for amplifiers aw88083 of Awinic Technology Corporation. The AW88083 is an intelligent digital audio amplifier with low noise.
of_thermal_zone_find() calls of_parse_phandle_with_args(), but does not release the OF node reference obtained by it. Add a of_node_put() call when the call is successful. Fixes: 3fd6d6e ("thermal/of: Rework the thermal device tree initialization") Signed-off-by: Joe Hattori <joe@pf.is.s.u-tokyo.ac.jp> Link: https://patch.msgid.link/20241224031809.950461-1-joe@pf.is.s.u-tokyo.ac.jp [ rjw: Changelog edit ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
…WMON interface" There is a garbage value problem in fbnic_mac_get_sensor_asic(). 'fw_cmpl' is uninitialized which makes 'sensor' and '*val' to be stored garbage value. Revert commit d85ebad ("eth: fbnic: Add hardware monitoring support via HWMON interface") to avoid this problem. Fixes: d85ebad ("eth: fbnic: Add hardware monitoring support via HWMON interface") Signed-off-by: Su Hui <suhui@nfschina.com> Suggested-by: Jakub Kicinski <kuba@kernel.org> Suggested-by: Michal Swiatkowski <michal.swiatkowski@linux.intel.com> Link: https://patch.msgid.link/20250106023647.47756-1-suhui@nfschina.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Compliment the existing macro to construct an SDCA control address with macros to extract the constituent parts, and validation of such an address. Also update the masks for the original macro to use GENMASK to make mental comparisons with the included comment on the address format easier. Acked-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-2-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
Update the list of entity_0 controls to better match version v1.0 of the SDCA specification. Remove both INTSTAT_CLEAR and INT_ENABLE as these are no longer used, and add some missing controls and bits into the enum. Also rename the SDCA_CONTROL prefix to SDCA_CTL because this better matches the macros in the sdw_registers.h header, and the names can get quite long so saving a few characters is definitely a plus. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-3-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org>
SoundWire MBQ register maps typically contain a variety of register sizes, which doesn't map ideally to the regmap abstraction which expects register maps to have a consistent size. Currently the MBQ register map only allows 16-bit registers to be defined, however this leads to complex CODEC driver implementations with an 8-bit register map and a 16-bit MBQ, every control will then have a custom get and put handler that allows them to access different register maps. Further more 32-bit MBQ quantities are not currently supported. Add support for additional MBQ sizes and to avoid the complexity of multiple register maps treat the val_size as a maximum size for the register map. Within the regmap use an ancillary callback to determine how many bytes to actually read/write to the hardware for a specific register. In the case that no callback is defined the behaviour defaults back to the existing behaviour of a fixed size register map. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-4-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
The SDCA specification allows for controls to be deferred. In the case of a deferred control the device will return COMMAND_IGNORED to the 8-bit operation that would cause the value to commit. Which is the final 8-bits on a write, or the first 8-bits on a read. In the case of receiving a defer, the regmap will poll the SDCA function busy bit, after which the transaction will be retried, returning an error if the function busy does not clear within a chip specific timeout. Since this is common SDCA functionality which is the 99% use-case for MBQs it makes sense to incorporate this functionality into the register map. If no MBQ configuration is specified, the behaviour will default to the existing behaviour. Signed-off-by: Charles Keepax <ckeepax@opensource.cirrus.com> Link: https://patch.msgid.link/20250107154408.814455-5-ckeepax@opensource.cirrus.com Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.dev> Signed-off-by: Mark Brown <broonie@kernel.org>
…/kernel/git/pcmoore/selinux Pull selinux fix from Paul Moore: "A single SELinux patch to address a problem with a single domain using multiple xperm classes" * tag 'selinux-pr-20250107' of git://git.kernel.org/pub/scm/linux/kernel/git/pcmoore/selinux: selinux: match extended permissions to their base permissions
Merge series from Charles Keepax <ckeepax@opensource.cirrus.com>: The current SDCA MBQ (Multi-Byte Quantities) register map only supports 16-bit types, add support for more sizes and then update the rt722 driver to use the new support. We also add support for the deferring feature of MBQs to allow hardware to indicate it is not currently ready to service a read/write. Afraid I don't have hardware to test the rt722 change so it is only build tested, but I thought it good to include a change to demonstrate the new features in use.
When `ksmbd_vfs_kern_path_locked` met an error and it is not the last entry, it will exit without restoring changed path buffer. But later this buffer may be used as the filename for creation. Fixes: c5a709f ("ksmbd: handle caseless file creation") Signed-off-by: He Wang <xw897002528@gmail.com> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
The x86 shadow stack support has its own set of registers. Those registers are XSAVE-managed, but they are "supervisor state components" which means that userspace can not touch them with XSAVE/XRSTOR. It also means that they are not accessible from the existing ptrace ABI for XSAVE state. Thus, there is a new ptrace get/set interface for it. The regset code that ptrace uses provides an ->active() handler in addition to the get/set ones. For shadow stack this ->active() handler verifies that shadow stack is enabled via the ARCH_SHSTK_SHSTK bit in the thread struct. The ->active() handler is checked from some call sites of the regset get/set handlers, but not the ptrace ones. This was not understood when shadow stack support was put in place. As a result, both the set/get handlers can be called with XFEATURE_CET_USER in its init state, which would cause get_xsave_addr() to return NULL and trigger a WARN_ON(). The ssp_set() handler luckily has an ssp_active() check to avoid surprising the kernel with shadow stack behavior when the kernel is not ready for it (ARCH_SHSTK_SHSTK==0). That check just happened to avoid the warning. But the ->get() side wasn't so lucky. It can be called with shadow stacks disabled, triggering the warning in practice, as reported by Christina Schimpe: WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 ssp_get+0x89/0xa0 [...] Call Trace: <TASK> ? show_regs+0x6e/0x80 ? ssp_get+0x89/0xa0 ? __warn+0x91/0x150 ? ssp_get+0x89/0xa0 ? report_bug+0x19d/0x1b0 ? handle_bug+0x46/0x80 ? exc_invalid_op+0x1d/0x80 ? asm_exc_invalid_op+0x1f/0x30 ? __pfx_ssp_get+0x10/0x10 ? ssp_get+0x89/0xa0 ? ssp_get+0x52/0xa0 __regset_get+0xad/0xf0 copy_regset_to_user+0x52/0xc0 ptrace_regset+0x119/0x140 ptrace_request+0x13c/0x850 ? wait_task_inactive+0x142/0x1d0 ? do_syscall_64+0x6d/0x90 arch_ptrace+0x102/0x300 [...] Ensure that shadow stacks are active in a thread before looking them up in the XSAVE buffer. Since ARCH_SHSTK_SHSTK and user_ssp[SHSTK_EN] are set at the same time, the active check ensures that there will be something to find in the XSAVE buffer. [ dhansen: changelog/subject tweaks ] Fixes: 2fab02b ("x86: Add PTRACE interface for shadow stack") Reported-by: Christina Schimpe <christina.schimpe@intel.com> Signed-off-by: Rick Edgecombe <rick.p.edgecombe@intel.com> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com> Tested-by: Christina Schimpe <christina.schimpe@intel.com> Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250107233056.235536-1-rick.p.edgecombe%40intel.com
… occur scsi_execute_cmd() function can return both negative (linux codes) and positive (scsi_cmnd result field) error codes. Currently the driver just passes error codes of scsi_execute_cmd() to hwmon core, which is incorrect because hwmon only checks for negative error codes. This leads to hwmon reporting uninitialized data to userspace in case of SCSI errors (for example if the disk drive was disconnected). This patch checks scsi_execute_cmd() output and returns -EIO if it's error code is positive. Fixes: 5b46903 ("hwmon: Driver for disk and solid state drives with temperature sensors") Signed-off-by: Daniil Stas <daniil.stas@posteo.net> Cc: Guenter Roeck <linux@roeck-us.net> Cc: Chris Healy <cphealy@gmail.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Martin K. Petersen <martin.petersen@oracle.com> Cc: Bart Van Assche <bvanassche@acm.org> Cc: linux-kernel@vger.kernel.org Cc: linux-scsi@vger.kernel.org Cc: linux-ide@vger.kernel.org Cc: linux-hwmon@vger.kernel.org Link: https://lore.kernel.org/r/20250105213618.531691-1-daniil.stas@posteo.net [groeck: Avoid inline variable declaration for portability] Signed-off-by: Guenter Roeck <linux@roeck-us.net>
As SMB3 posix extension specification, Give posix file type to posix mode. https://www.samba.org/~slow/SMB3_POSIX/fscc_posix_extensions.html#posix-file-type-definition Cc: stable@vger.kernel.org Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com>
There are two MQS instances on the i.MX943 platform. The definition of bit positions in the control register are different. In order to support these MQS modules, define two compatible strings to distinguish them. On i.MX943 one instance is in Always-on mix, another is in Wakeup-mix. Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://patch.msgid.link/20250113090321.3193464-2-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
There are two MQS instances on the i.MX943 platform. The definition of bit positions in the control register are different. In order to support these MQS modules, define two compatible strings to distinguish them. As one instance is in the always-on domain, another is in the wakeup domain, so the compatible strings are "fsl,imx943-aonmix-mqs", "fsl,imx943-wakeupmix-mqs". Signed-off-by: Shengjiu Wang <shengjiu.wang@nxp.com> Reviewed-by: Daniel Baluta <daniel.baluta@nxp.com> Link: https://patch.msgid.link/20250113090321.3193464-3-shengjiu.wang@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org>
There is no audio output if Speaker volume is set above 25. According to datasheet Rev 2.5 maximum allowed value for the Speaker output is 0b11001 (25) 0x6D CLASSD_GAIN_1/ 0x6E CLASSD_GAIN_2: Left/Right Channel Class-D Driver Gain For DAC Left/Right Input (Step size is 1dB.) 00000 = Mute (DEFAULT) 00001 = 0dB 00002 = 1dB ... 11000 = 23dB 11001 = 24dB So adjust this value in accordance with the datasheet. Signed-off-by: Maxim Kochetkov <fido_max@inbox.ru> Link: https://patch.msgid.link/20241219042227.7075-1-fido_max@inbox.ru Signed-off-by: Mark Brown <broonie@kernel.org>
audio-graph-card2 handles many type of device_node, thus need to use of_node_put() in many place. Let's use __free(device_node) and avoid it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Stephen Gordon <gordoste@iinet.net.au> Link: https://patch.msgid.link/87y0zoo5kc.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
audio-graph-card handles many type of device_node, thus need to use of_node_put() in many place. Let's use __free(device_node) and avoid it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Stephen Gordon <gordoste@iinet.net.au> Link: https://patch.msgid.link/87wmf8o5k1.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
simple-card handles many type of device_node, thus need to use of_node_put() in many place. Let's use __free(device_node) and avoid it. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Stephen Gordon <gordoste@iinet.net.au> Link: https://patch.msgid.link/87v7uso5js.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
…_provider_raw() snd_soc_daifmt_parse_clock_provider_raw() might be called with NULL np. Return 0 in such case. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Stephen Gordon <gordoste@iinet.net.au> Link: https://patch.msgid.link/87ttaco5jm.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
…ext_multi_ep() Audio Graph Card2 is assuming "port" are necessarily in order, but there is no guarantee in case of overlay. Use of_graph_get_port_by_id() instead to handle it correctly. Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Stephen Gordon <gordoste@iinet.net.au> Link: https://patch.msgid.link/87sepwo5jf.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Current ASoC is using dai_link->dai_fmt to set DAI format for both CPU/Codec. But because it is using same settings, and SND_SOC_DAIFMT_CLOCK_PROVIDER is flipped for CPU, we can't set both CPU/Codec as clock consumer, for example. To solve this issue, this patch enable to use extra format for each DAI which can keep compatibility with legacy system, 1. SND_SOC_DAIFMT_FORMAT_MASK 2. SND_SOC_DAIFMT_CLOCK 3. SND_SOC_DAIFMT_INV 4. SND_SOC_DAIFMT_CLOCK_PROVIDER Legacy dai_fmt includes 1, 2, 3, 4 New idea dai_fmt includes 1, 2, 3 ext_fmt includes 4 Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Stephen Gordon <gordoste@iinet.net.au> Link: https://patch.msgid.link/87r05go5ja.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
Current ASoC is using dai_link->dai_fmt to set DAI format for both CPU/Codec. But because it is using same settings, and SND_SOC_DAIFMT_CLOCK_PROVIDER is flipped for CPU, we can't set both CPU/Codec as clock consumer, for example. To solve this issue, this patch uses extra format for each DAI which can keep compatibility with legacy system, 1. SND_SOC_DAIFMT_FORMAT_MASK 2. SND_SOC_DAIFMT_CLOCK 3. SND_SOC_DAIFMT_INV 4. SND_SOC_DAIFMT_CLOCK_PROVIDER Legacy dai_fmt includes 1, 2, 3, 4 New idea dai_fmt includes 1, 2, 3 ext_fmt includes 4 Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> Tested-by: Stephen Gordon <gordoste@iinet.net.au> Link: https://patch.msgid.link/87pll0o5j6.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Mark Brown <broonie@kernel.org>
The upcoming DRM connector HDMI codec implementation is going to use codec-specific data in the .get_dai_id to get drm_connector. Pass data to the callback, as it is done with other hdmi_codec_ops callbacks. Acked-by: Mark Brown <broonie@kernel.org> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patch.msgid.link/20241224-drm-bridge-hdmi-connector-v10-1-dc89577cd438@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
The no_capture_mute flag might differ from platform to platform, especially in the case of the wrapping implementations, like the upcoming DRM HDMI Codec framework. Move the flag next to all other flags in struct hdmi_codec_pdata. Acked-by: Mark Brown <broonie@kernel.org> Tested-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://patch.msgid.link/20241224-drm-bridge-hdmi-connector-v10-2-dc89577cd438@linaro.org Signed-off-by: Mark Brown <broonie@kernel.org>
Remove hard-coded strings by using the str_yes_no() helper function. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Link: https://patch.msgid.link/20250107110900.3716-2-thorsten.blum@linux.dev Signed-off-by: Mark Brown <broonie@kernel.org>
Use the ARRAY_SIZE() macro to calculate PEB2466_TLV_SIZE and improve the code's readability. Signed-off-by: Thorsten Blum <thorsten.blum@linux.dev> Acked-by: Herve Codina <herve.codina@bootlin.com> Link: https://patch.msgid.link/20250113001001.400669-2-thorsten.blum@linux.dev Signed-off-by: Mark Brown <broonie@kernel.org>
Merge series from Shengjiu Wang <shengjiu.wang@nxp.com>: There are two MQS instances on the i.MX943 platform. The definition of bit positions in the control register are different. In order to support these MQS modules, define two compatible strings to distinguish them.
Merge series from Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>: Current clock provider/consumer setting is set by dai_link->dai_fmt, and it is Codec base on Sound Card driver (= SND_SOC_DAIFMT_CBx_CFx). Current CPU/Codec drivers are already based on its own base (= SND_SOC_DAIFMT_Bx_Fx). So, Codec clock setting uses dai_link->dai_fmt as-is, and CPU side clock setting is created from Codec base setting by flipping. Because of this, we can't set both CPU/Codec clock consumer for example. To solve this issue, this patch-set adds new ext_fmt on each DAI. It can keep compatible with legacy style. 1. SND_SOC_DAIFMT_FORMAT_MASK 2. SND_SOC_DAIFMT_CLOCK 3. SND_SOC_DAIFMT_INV 4. SND_SOC_DAIFMT_CLOCK_PROVIDER dai_fmt : dai_link->dai_fmt = common settings ext_fmt : each DAI settings Legacy dai_fmt includes 1, 2, 3, 4 New style dai_fmt includes 1, 2, 3 ext_fmt includes 4 Audio-Graph-Card2 will use this new style by this patch-set. By this patch, Card2 default behavior (= no "clock-master / frame-master" settings on DT) will be changed, but no drivers are using it. In case of no DAI has "clock-master / frame-master" property on DT, it will be... Legacy CPU : provider (because flipped from Codec) Codec: consumer New style CPU : consumer Codec: consumer One note is that Simple-Card, Audio-Graph-Card don't implement this new style to keep compatiblily. In Overlay case, port order can be random, so we shouldn't use get_next() function to get next port.
Merge series from Dmitry Baryshkov <dmitry.baryshkov@linaro.org>: Provide some more functionality from the hdmi-codec driver to facilitate some DRM framework enhancements.
bardliao
requested review from
dbaluta,
kv2019i,
lgirdwood,
plbossart,
ranj063 and
ujfalusi
as code owners
Collaborator
Author
|
SOFCI TEST |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No conflict