Add support for two configurations with SoundWire mockup devices that
emulate the two CometLake configurations with one and two amps. This
patch helps test the SOF firmware on an UpExtreme board without any
hardware connected, e.g. by doing a loopback of the playback stream on
capture streams.
The mapping of the partIDs is as follows:
0xAAAA: generic full-duplex codec (not currently used)
0xAA55: headset codec (mock-up of RT711/RT5682) - full-duplex
0x55AA: amplifier (mock-up of RT1308/RT1316/Maxim 98373) - playback
with IV sense feedback
0x5555: mic codec (mock-up of RT715) - capture-only
The tables are added in a separate file to allow for mockup codecs to be
added on other platforms, but the mapping to specific topologies
remains platform-specific.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20210714032209.11284-3-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
To test the host controller and bus management code, it is currently
required to have a physical SoundWire peripheral attached to the
bus. To help with pre-silicon or early hardware enablement, it would
be very useful to have a SoundWire 'mockup' device that is exposed in
platform firmware but does not drive any signal on the bus.
This is different to the existing ASoC 'dummy' codec uses for I2S/TDM,
the SoundWire spec makes it clear that a device that is not attached
to the bus is not permitted to interact with the bus, be it for
command/control or data.
This patch exposes a 'mockup' device, with a minimalist driver, with 4
partID values reserved by Intel for such test configurations. The
mockup device exposes one full-duplex DAI based on 2 ports (DP1 for
playback and DP8 for capture). The capture data port is just virtual,
such a mockup device is prevented by the SoundWire specification from
presenting any data generated by a Source port without being Attached.
All the callbacks exposed by the SoundWire Slave interface are
populated, even if they just return immediately. This is intentional
to describe what a minimal codec driver should do and implement and
help new codec vendors provide support for their devices.
Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Reviewed-by: Rander Wang <rander.wang@intel.com>
Signed-off-by: Bard Liao <yung-chuan.liao@linux.intel.com>
Link: https://lore.kernel.org/r/20210714032209.11284-2-yung-chuan.liao@linux.intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Hi,
Changes since v1:
- Do not calculat that we allow one serializer in DIT mode, just set the
max_active_serializers to 1.
Reported-by: kernel test robot <lkp@intel.com>
it has been on my todo list for several years to support McASP on OMAP4 devices.
For Galaxy Nexus we had an omap-mcasp driver (which was mostly a stripped down
davinci-mcasp driver) to support what was needed on that specific phone + it's
dock for S/PDIF (48KHz, 16bit, stereo).
Not many (if any) device available to test the DIT mode of McASP.
I have used BeagleBone White (McASP1 AXR3 can be routed to a pin) to get the
S/PDIF mode working then PandaES for OMAP4 support (on PandaES the gpio_121 is
not used and the signal is routed to expansion J6 pin14).
In theory the McASP in OMAP5 should be working after this series, but the OMAP5
TRM is not public and I do not have one to check the addresses and see if there
is a way to test it on omap5-uevm.
Mark, Tony:
The ASoC and dts patches can go via separate tree I felt that it is better if
they are together, at least initially.
Nikolaus: fyi, this might be useful for Pyra?
Regards,
Péter
---
Peter Ujfalusi (5):
ASoC: ti: davinci-mcasp: Fix DIT mode support
ASoC: dt-bindings: davinci-mcasp: Add compatible string for OMAP4
ASoC: ti: davinci-mcasp: Add support for the OMAP4 version of McASP
ARM: dts: omap4-l4-abe: Correct sidle modes for McASP
ARM: dts: omap4-l4-abe: Add McASP configuration
.../bindings/sound/davinci-mcasp-audio.txt | 1 +
arch/arm/boot/dts/omap4-l4-abe.dtsi | 39 ++--
include/linux/platform_data/davinci_asp.h | 1 +
sound/soc/ti/Kconfig | 1 +
sound/soc/ti/davinci-mcasp.c | 176 +++++++++++++++---
5 files changed, 175 insertions(+), 43 deletions(-)
--
2.32.0
The first fix solves an underflow in SoundWire platforms using the
max98373 amplifier, the rest of the patches are minor corrections in
machine drivers.
The fix should be queued for the 5.14 cycle, the rest should be
harmless but can be deferred for 5.15 if it's too late already.
Brent Lu (2):
ASoC: SOF: add a helper to get topology configured bclk
ASoC: Intel: sof_cs42l42: use helper function to get bclk frequency
Gongjun Song (1):
ASoC: Intel: soc-acpi: add support for SoundWire of TGL-H-RVP
Rander Wang (1):
ASoC: Intel: boards: fix xrun issue on platform with max98373
include/sound/sof.h | 1 +
sound/soc/intel/boards/sof_cs42l42.c | 8 +-
sound/soc/intel/boards/sof_sdw_max98373.c | 81 ++++++++++++-------
.../intel/common/soc-acpi-intel-tgl-match.c | 15 ++++
sound/soc/sof/sof-audio.c | 42 ++++++++--
5 files changed, 111 insertions(+), 36 deletions(-)
--
2.25.1
The TAS2505/TAS2521 does support up to two channels, LEFT and RIGHT,
which are being alternated on the audio data bus by Word Clock, WCLK.
This is documented in TI slau472 2.7.1 Digital Audio Interface. Note
that both the LEFT and RIGHT channels are only used for audio INPUT,
while only the LEFT channel is used for audio OUTPUT.
Fixes: b4525b6196 ("ASoC: tlv320aic32x4: add support for TAS2505")
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Claudius Heine <ch@denx.de>
Cc: Mark Brown <broonie@kernel.org>
Link: https://lore.kernel.org/r/20210708091229.56443-1-marex@denx.de
Signed-off-by: Mark Brown <broonie@kernel.org>
OMAP4 has one McASP instance with single serializer and supporting only
DIT mode.
According to the TRM the DAT port needs to be accessed as specific offset
compared to other devices where access to any part of the DAT region is
valid.
To handle this constraint we need to introduce a new compatiple string for
OMAP4.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20210705194249.2385-3-peter.ujfalusi@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The DIT mode support has not been tested due to lack of platform where it
can be tested.
To be able to use the McASP on OMAP4/5 (only supporting DIT mode) we need
to have DIT mode working in the McASP driver on a know platform.
After hacking around (on BBW, mcasp1.axr1 can be routed out for this) it
appeared that DIT mode is broken.
This patch fixes it up and 16/24 bit audio works along with passthrough,
but I have only tested with DTS example and test files.
Signed-off-by: Peter Ujfalusi <peter.ujfalusi@gmail.com>
Link: https://lore.kernel.org/r/20210705194249.2385-2-peter.ujfalusi@gmail.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The kernel recovers in due course from missing Mlocked pages: but there
was no point in calling page_mlock() (formerly known as
try_to_munlock()) on a THP, because nothing got done even when it was
found to be mapped in another VM_LOCKED vma.
It's true that we need to be careful: Mlocked accounting of pte-mapped
THPs is too difficult (so consistently avoided); but Mlocked accounting
of only-pmd-mapped THPs is supposed to work, even when multiple mappings
are mlocked and munlocked or munmapped. Refine the tests.
There is already a VM_BUG_ON_PAGE(PageDoubleMap) in page_mlock(), so
page_mlock_one() does not even have to worry about that complication.
(I said the kernel recovers: but would page reclaim be likely to split
THP before rediscovering that it's VM_LOCKED? I've not followed that up)
Fixes: 9a73f61bdb ("thp, mlock: do not mlock PTE-mapped file huge pages")
Signed-off-by: Hugh Dickins <hughd@google.com>
Reviewed-by: Shakeel Butt <shakeelb@google.com>
Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
Link: https://lore.kernel.org/lkml/cfa154c-d595-406-eb7d-eb9df730f944@google.com/
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Jason Gunthorpe <jgg@nvidia.com>
Cc: Ralph Campbell <rcampbell@nvidia.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Yang Shi <shy828301@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull irq fixes from Ingo Molnar:
"Two fixes:
- Fix a MIPS IRQ handling RCU bug
- Remove a DocBook annotation for a parameter that doesn't exist
anymore"
* tag 'irq-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
irqchip/mips: Fix RCU violation when using irqdomain lookup on interrupt entry
genirq/irqdesc: Drop excess kernel-doc entry @lookup
Pull scheduler fixes from Ingo Molnar:
"Three fixes:
- Fix load tracking bug/inconsistency
- Fix a sporadic CFS bandwidth constraints enforcement bug
- Fix a uclamp utilization tracking bug for newly woken tasks"
* tag 'sched-urgent-2021-07-11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/uclamp: Ignore max aggregation if rq is idle
sched/fair: Fix CFS bandwidth hrtimer expiry type
sched/fair: Sync load_sum with load_avg after dequeue
