- Sound-open-firmware - mailman.alsa-project.org

[Sound-open-firmware] [PATCH 0/3] Add DSP node on i.MX8QXP board
by Daniel Baluta 23 Jul '19

23 Jul '19

i.MX8QXP boards feature an Hifi4 DSP from Tensilica. This patch series adds the DT node. Note that we switched to the new yaml format for bindings documentation. The DSP will run SOF Firmware [1]. Patches adding support for Linux DSP driver are already sent for review to SOF folks [2]. This patch series also contains a patch introducing DT related clocks. The patch was already reviewed here: https://lkml.org/lkml/2019/7/17/975 but I added it in this patch series because it wasn't yet picked by Shawn so patches 2/3 will not compiled without patch 1. [1] https://github.com/thesofproject/sof [2] https://github.com/thesofproject/linux/pull/1048/commits Daniel Baluta (3): clk: imx8: Add DSP related clocks arm64: dts: imx8qxp: Add DSP DT node dt-bindings: dsp: fsl: Add DSP core binding support .../devicetree/bindings/dsp/fsl,dsp.yaml | 87 +++++++++++++++++++ arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 + arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 32 +++++++ drivers/clk/imx/clk-imx8qxp-lpcg.c | 5 ++ include/dt-bindings/clock/imx8-clock.h | 6 +- 5 files changed, 133 insertions(+), 1 deletion(-) create mode 100644 Documentation/devicetree/bindings/dsp/fsl,dsp.yaml -- 2.17.1

6 10

[Sound-open-firmware] Linux build for arm64
by Daniel Baluta 18 Jul '19

18 Jul '19

Hi Liam / Pierre, Could we add a build for arm64 too in CI? With recent patches that add support for i.MX8 SOF Linux driver it would be handy to also have the build for arm64. I can help you with the cross-compilers and build instructions. Currently we are only building for x86_64. https://travis-ci.org/thesofproject/linux/builds/560509972 thanks, Daniel.

2 3

[Sound-open-firmware] New platform bringup docs
by Curtis Malainey 11 Jul '19

11 Jul '19

Hello SOF community, Do we have any documents similar to the new architecture links (https://thesofproject.github.io/latest/architectures/dsp/index.html#adding-…) but more advanced. I was thinking ideally something along the lines of a check/worklist of features to be built for introducing a new platform to SOF. Daniel you have done this, do you have any documents or experiences that we can turn into a doc? Thanks in advance. Curtis

2 2

[Sound-open-firmware] Problems booting byt in qemu
by Dragos Tarcatu 03 Jul '19

03 Jul '19

Hi, I've been trying to put together a qemu test environment for byt but I'm struggling to get the firmware to properly boot up. My setup is as following: - x86 host VM: Linux kernel from topic/sof-dev configured for x86_64_defconfig + sof for Baytrail (acpi) with forced nocodec mode, on top of some Ubuntu root file system - DSP VM: sof firmware from master built for byt according to the sof documentation - qemu from sof-stable - topology: sof-byt-nocodec I'm launching the qemu VMs using: xtensa-host.sh byt -d and x86-host.sh byt <my-ubuntu-image> Shortly after the x86 VM boots up, the DSP VM starts logging a lot of shim.io messages, but the linux driver fails after: [ 3.054963] sof-audio-acpi 80860F28:00: ACPI DSP detected [ 3.054966] sof-audio-acpi 80860F28:00: IOSF_MBI not available, no BYT-CR detection [ 3.054967] sof-audio-acpi 80860F28:00: Force to use nocodec mode [ 3.054971] sof-audio-acpi 80860F28:00: LPE PHY base at 0xf1400000 size 0x200000 [ 3.054981] sof-audio-acpi 80860F28:00: LPE VADDR 000000009309825a [ 3.054982] sof-audio-acpi 80860F28:00: IMR not set by BIOS. Ignoring [ 3.054984] sof-audio-acpi 80860F28:00: using IRQ 11 [ 3.058424] sof-audio-acpi 80860F28:00: loading firmware [ 3.070402] sof-audio-acpi 80860F28:00: header size=0x15e60 modules=0x1 abi=0x1 size=16 [ 3.070504] sof-audio-acpi 80860F28:00: new module size 0x15e54 blocks 0x11 type 0x0 [ 3.070506] sof-audio-acpi 80860F28:00: block 0 type 0x1 size 0xf0 ==> offset 0xc0000 [ 3.070524] sof-audio-acpi 80860F28:00: block 1 type 0x1 size 0x16c ==> offset 0xc0400 [ 3.070525] sof-audio-acpi 80860F28:00: block 2 type 0x1 size 0x8 ==> offset 0xc057c [ 3.070527] sof-audio-acpi 80860F28:00: block 3 type 0x1 size 0x8 ==> offset 0xc059c [ 3.070528] sof-audio-acpi 80860F28:00: block 4 type 0x1 size 0x8 ==> offset 0xc05bc [ 3.070529] sof-audio-acpi 80860F28:00: block 5 type 0x1 size 0x8 ==> offset 0xc05dc [ 3.070530] sof-audio-acpi 80860F28:00: block 6 type 0x1 size 0x8 ==> offset 0xc05fc [ 3.070532] sof-audio-acpi 80860F28:00: block 7 type 0x1 size 0x4 ==> offset 0xc061c [ 3.070533] sof-audio-acpi 80860F28:00: block 8 type 0x1 size 0x8 ==> offset 0xc063c [ 3.070534] sof-audio-acpi 80860F28:00: block 9 type 0x1 size 0x4 ==> offset 0xc0658 [ 3.070536] sof-audio-acpi 80860F28:00: block 10 type 0x1 size 0x18 ==> offset 0xc065c [ 3.070537] sof-audio-acpi 80860F28:00: block 11 type 0x1 size 0x8 ==> offset 0xc067c [ 3.070539] sof-audio-acpi 80860F28:00: block 12 type 0x1 size 0x12660 ==> offset 0xc06c0 [ 3.070599] sof-audio-acpi 80860F28:00: block 13 type 0x2 size 0x21e8 ==> offset 0x100008 [ 3.070611] sof-audio-acpi 80860F28:00: block 14 type 0x2 size 0x28 ==> offset 0x1021f0 [ 3.070613] sof-audio-acpi 80860F28:00: block 15 type 0x2 size 0x11f8 ==> offset 0x102218 [ 3.070617] sof-audio-acpi 80860F28:00: block 16 type 0x2 size 0x6c ==> offset 0x103a98 [ 3.070623] sof-audio-acpi 80860F28:00: booting DSP firmware [ 3.172697] sof-audio-acpi 80860F28:00: error: firmware boot failure [ 3.176674] sof-audio-acpi 80860F28:00: error: unexpected fault 0x70028800 trace 0x00000000 [ 3.177125] sof-audio-acpi 80860F28:00: error: failed to boot DSP firmware -5 [ 3.181048] sof-audio-acpi 80860F28:00: error: failed to probe DSP hardware! [ 3.181477] sof-audio-acpi: probe of 80860F28:00 failed with error -5 Any idea what may be wrong? Thanks, Dragoș

4 9

[Sound-open-firmware] SOF dynamic module loading
by Daniel Baluta 28 Jun '19

28 Jun '19

Hi Liam / Pierre, I remember that at some point there was a branch in SOF with initial support for loading dynamic modules at runtime. Anyhow I don't remember the name, can you help? We have some decoding/encoding algorithms and we need to be able to dynamically load them and use them in a simple pipeline like this: -> Host0 -> Buffer0 \ Algorithm <-Host1 <- Buffer1 / Any pointers are welcomed. thanks, Daniel.

2 1

[Sound-open-firmware] Creating Pull Requests for specific issues
by Jankowski, Janusz 10 Jun '19

10 Jun '19

Hello, When you create PR that is aimed to solve some specific issue, please include in PR description sentence like "Closes #IssueNumber". This way issue will be closed automatically when PR is merged and we will not have dangling issues that got solved but forgotten and maintainers are not sure if they can be closed. Also please take care and don't write something like "Partially resolves #SomeIssue", because GitHub will catch it and it will close this issue, when author intention probably was not to do it. I recommend you to take a look at this: https://help.github.com/en/articles/closing-issues-using-keywords Thanks, Janusz

1 0

[Sound-open-firmware] SOF v1.3 released
by Liam Girdwood 07 Jun '19

07 Jun '19

I'd like to announce that SOF v1.3 has now been released and is available for download here. https://github.com/thesofproject/sof/releases/tag/v1.3 The big ticket items in v1.3 are o Kconfig build support - Individual features/components can be added or removed. o HDMI, HDA support. o Improved PM support on Intel platforms. o NXP iMX8 - Initial DSP support added for iMX8. o GDB - Initial support for debugging firmware via GDB. Alongside bug fixes and improved stability. This firmware version will be the first version to upstream binaries to the Linux firmware repository. This includes signed binaries for some Intel platforms. Thanks Liam

1 0

[Sound-open-firmware] Commits in SOF (part 2)
by Daniel Baluta 07 Jun '19

07 Jun '19

Hello all, This is a follow up of email thread started [1]. My major request in the first email was for the commit message to explain WHY the change is needed. Things are looking good! Patches are easier to review and understand. This will also help newcomers trying to understand the code and contribute. Next request: Better split of the code into separate patches. Please create a patch for each logical change. Do not put small fixes (e.g whitespaces, tabs, code removal) together with a bigger patch. Just create a separate patch. Make sure each individual patch compiles so that we don't break bisection! Thanks, Daniel. [1] https://mailman.alsa-project.org/pipermail/sound-open-firmware/2019-May/003…

1 0

[Sound-open-firmware] What is the correct loopback configuration for ASoC machine driver DAI links?
by Thomas Preston 30 May '19

30 May '19

Hi, I have a question about configuring a physical loopback on a custom board for the Intel Skylake platform driver. I have also asked on freenode/#alsa-dev but they directed me here. We have the following physical SSP layout: A2B axillary audio + SSP0 Tx (connected to SSP5 Rx, for debug) + SSP0 Rx Main speaker output + loopback from A2B + SSP5 Tx + SSP5 Rx (connected to SSP0 Tx) We have a board-level hardware loopback where the output signals and clock (slave) on SSP0 are connected to the input signals and clock (master) on SSP5. I'm trying to configure the DAI links in the machine driver so that they link against SSP0 Pin CPU DAI correctly but I have three problematic configurations: 1. Separate BE DAI links for SSP5 playback and capture, linking against the same Skylake CPU DAI "SSP5 Tx". This crashes the kernel with a NULL pointer dereference (I'm looking into this). Presumably this is an invalid configuration because I have multiple DAI links linking against one CPU DAI. See machine1.c 2. One BE DAI link for SSP5 playback + capture, linking against the same Skylake CPU DAI. This silences my SSP5 Tx main audio output (which appears to be muted) when I try to arecord on the SSP5 Rx A2B debug loopback. The recording is a perfect copy of SSP0 Tx so the loopback part works. I can recover by restarting my whole audio stack. See machine2.c 3. Separate BE DAI links for SSP playback and loopback, linking against a separated SSP5 Skylake CPU DAI (SSP5 Pin with ssp5 Tx, SSP5 Pin Loopback with ssp5 Rx). This configuration works but requires a modification to the Skylake platform driver - which I'd rather avoid. See machine3.c, skylake.diff Configuration 2 is closest to what I want, and configuration 3 is my work-around for now. What is the correct way to link CPU DAIs for this kind of loopback? I have attached example code. Many thanks, Thomas

2 3

[Sound-open-firmware] Commits in SOF
by Daniel Baluta 29 May '19

29 May '19

Hello all, I have few comments about commits in SOF FW which I think might improve the review quality. 1) I've seen commit messages that do not explain WHY the change is needed but mostly saying WHAT the change is doing. Explaining WHAT the change is doing is good when the code is fairly complicated. Anyhow, I would prefer to see more of WHY do we need that change. Lets try to keep this in mind. 2) Commit messages do not contain a verb. Commits should be seen as actions thus should contain a verb. More than that we should use imperative mood. Not added, fixed, etc but Add, Fix, etc! 3) Capitalize the subject line First letter from commit subject after the subsystem tag should be capital. e.g. buffer: add new interface -> buffer: Add new interface I think we should turn our attention to: https://chris.beams.io/posts/git-commit/#seven-rules thanks, Daniel.

4 4