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

[Sound-open-firmware] Machine drivers for SOF/non-SOF Intel configurations
by Daniel Baluta 26 Aug '19

26 Aug '19

Hello, As far as I understand Intel uses the same machine drivers for SOF/non-SOF configurations. I don't exactly understand how this works. 1) Can SOF/non-SOF sound cards co-exist? 2) In SOF the DAI is managed by the FW, how one prevents Linux DAI driver to be loaded in SOF. 3) Is there any SOF related information in ACPI tables. I am still trying to wrap my head around the idea implemented in sof-acpi-dev.c to make it work in the same way for sof-of-dev.c so sorry if the questions are not clear. thanks, Daniel.

4 4

Re: [Sound-open-firmware] [PATCH v4] firmware: imx: Add DSP IPC protocol interface
by Daniel Baluta 11 Aug '19

11 Aug '19

Hi Shawn, Can you please have a look at this when you have some time? Basically, we need this patch for imx8 SOF Linux driver: https://github.com/thesofproject/linux/pull/1048 I already got: Reviewed-by: Oleksij Rempel <o.rempel(a)pengutronix.de> For an older version of this patch. thanks, Daniel. On Thu, Aug 1, 2019 at 1:02 PM Daniel Baluta <daniel.baluta(a)nxp.com> wrote: > > Some of i.MX8 processors (e.g i.MX8QM, i.MX8QXP) contain > the Tensilica HiFi4 DSP for advanced pre- and post-audio > processing. > > The communication between Host CPU and DSP firmware is > taking place using a shared memory area for message passing > and a dedicated Messaging Unit for notifications. > > DSP IPC protocol offers a doorbell interface using > imx-mailbox API. > > We use 4 MU channels (2 x TXDB, 2 x RXDB) to implement a > request-reply protocol. > > Connection 0 (txdb0, rxdb0): > - Host writes messasge to shared memory [SHMEM] > - Host sends a request [MU] > - DSP handles request [SHMEM] > - DSP sends reply [MU] > > Connection 1 (txdb1, rxdb1): > - DSP writes a message to shared memory [SHMEM] > - DSP sends a request [MU] > - Host handles request [SHMEM] > - Host sends reply [MU] > > The protocol interface will be used by a Host client to > communicate with the DSP. First client will be the i.MX8 > part from Sound Open Firmware infrastructure. > > The protocol offers the following interface: > > On Tx: > - imx_dsp_ring_doorbell, will be called to notify the DSP > that it needs to handle a request. > > On Rx: > - clients need to provide two callbacks: > .handle_reply > .handle_request > - the callbacks will be used by the protocol on > notification arrival from DSP. > > Signed-off-by: Daniel Baluta <daniel.baluta(a)nxp.com> > --- > Changes since v3: > - Added remove function > > drivers/firmware/imx/Kconfig | 11 +++ > drivers/firmware/imx/Makefile | 1 + > drivers/firmware/imx/imx-dsp.c | 155 +++++++++++++++++++++++++++++++ > include/linux/firmware/imx/dsp.h | 67 +++++++++++++ > 4 files changed, 234 insertions(+) > create mode 100644 drivers/firmware/imx/imx-dsp.c > create mode 100644 include/linux/firmware/imx/dsp.h > > diff --git a/drivers/firmware/imx/Kconfig b/drivers/firmware/imx/Kconfig > index 42b566f8903f..0dbee32da4c6 100644 > --- a/drivers/firmware/imx/Kconfig > +++ b/drivers/firmware/imx/Kconfig > @@ -1,4 +1,15 @@ > # SPDX-License-Identifier: GPL-2.0-only > +config IMX_DSP > + bool "IMX DSP Protocol driver" > + depends on IMX_MBOX > + help > + This enables DSP IPC protocol between host AP (Linux) > + and the firmware running on DSP. > + DSP exists on some i.MX8 processors (e.g i.MX8QM, i.MX8QXP). > + > + It acts like a doorbell. Client might use shared memory to > + exchange information with DSP side. > + > config IMX_SCU > bool "IMX SCU Protocol driver" > depends on IMX_MBOX > diff --git a/drivers/firmware/imx/Makefile b/drivers/firmware/imx/Makefile > index 802c4ad8e8f9..08bc9ddfbdfb 100644 > --- a/drivers/firmware/imx/Makefile > +++ b/drivers/firmware/imx/Makefile > @@ -1,3 +1,4 @@ > # SPDX-License-Identifier: GPL-2.0 > +obj-$(CONFIG_IMX_DSP) += imx-dsp.o > obj-$(CONFIG_IMX_SCU) += imx-scu.o misc.o imx-scu-irq.o > obj-$(CONFIG_IMX_SCU_PD) += scu-pd.o > diff --git a/drivers/firmware/imx/imx-dsp.c b/drivers/firmware/imx/imx-dsp.c > new file mode 100644 > index 000000000000..a43d2db5cbdb > --- /dev/null > +++ b/drivers/firmware/imx/imx-dsp.c > @@ -0,0 +1,155 @@ > +// SPDX-License-Identifier: GPL-2.0+ > +/* > + * Copyright 2019 NXP > + * Author: Daniel Baluta <daniel.baluta(a)nxp.com> > + * > + * Implementation of the DSP IPC interface (host side) > + */ > + > +#include <linux/firmware/imx/dsp.h> > +#include <linux/kernel.h> > +#include <linux/mailbox_client.h> > +#include <linux/module.h> > +#include <linux/of_platform.h> > +#include <linux/platform_device.h> > +#include <linux/slab.h> > + > +/* > + * imx_dsp_ring_doorbell - triggers an interrupt on the other side (DSP) > + * > + * @dsp: DSP IPC handle > + * @chan_idx: index of the channel where to trigger the interrupt > + * > + * Returns non-negative value for success, negative value for error > + */ > +int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc, unsigned int idx) > +{ > + int ret; > + struct imx_dsp_chan *dsp_chan; > + > + if (idx >= DSP_MU_CHAN_NUM) > + return -EINVAL; > + > + dsp_chan = &ipc->chans[idx]; > + ret = mbox_send_message(dsp_chan->ch, NULL); > + if (ret < 0) > + return ret; > + > + return 0; > +} > +EXPORT_SYMBOL(imx_dsp_ring_doorbell); > + > +/* > + * imx_dsp_handle_rx - rx callback used by imx mailbox > + * > + * @c: mbox client > + * @msg: message received > + * > + * Users of DSP IPC will need to privde handle_reply and handle_request > + * callbacks. > + */ > +static void imx_dsp_handle_rx(struct mbox_client *c, void *msg) > +{ > + struct imx_dsp_chan *chan = container_of(c, struct imx_dsp_chan, cl); > + > + if (chan->idx == 0) { > + chan->ipc->ops->handle_reply(chan->ipc); > + } else { > + chan->ipc->ops->handle_request(chan->ipc); > + imx_dsp_ring_doorbell(chan->ipc, 1); > + } > +} > + > +static int imx_dsp_probe(struct platform_device *pdev) > +{ > + struct device *dev = &pdev->dev; > + struct imx_dsp_ipc *dsp_ipc; > + struct imx_dsp_chan *dsp_chan; > + struct mbox_client *cl; > + char *chan_name; > + int ret; > + int i, j; > + > + device_set_of_node_from_dev(&pdev->dev, pdev->dev.parent); > + > + dsp_ipc = devm_kzalloc(dev, sizeof(*dsp_ipc), GFP_KERNEL); > + if (!dsp_ipc) > + return -ENOMEM; > + > + for (i = 0; i < DSP_MU_CHAN_NUM; i++) { > + if (i < 2) > + chan_name = kasprintf(GFP_KERNEL, "txdb%d", i); > + else > + chan_name = kasprintf(GFP_KERNEL, "rxdb%d", i - 2); > + > + if (!chan_name) > + return -ENOMEM; > + > + dsp_chan = &dsp_ipc->chans[i]; > + cl = &dsp_chan->cl; > + cl->dev = dev; > + cl->tx_block = false; > + cl->knows_txdone = true; > + cl->rx_callback = imx_dsp_handle_rx; > + > + dsp_chan->ipc = dsp_ipc; > + dsp_chan->idx = i % 2; > + dsp_chan->ch = mbox_request_channel_byname(cl, chan_name); > + if (IS_ERR(dsp_chan->ch)) { > + ret = PTR_ERR(dsp_chan->ch); > + if (ret != -EPROBE_DEFER) > + dev_err(dev, "Failed to request mbox chan %s ret %d\n", > + chan_name, ret); > + goto out; > + } > + > + dev_dbg(dev, "request mbox chan %s\n", chan_name); > + /* chan_name is not used anymore by framework */ > + kfree(chan_name); > + } > + > + dsp_ipc->dev = dev; > + > + dev_set_drvdata(dev, dsp_ipc); > + > + dev_info(dev, "NXP i.MX DSP IPC initialized\n"); > + > + return devm_of_platform_populate(dev); > +out: > + kfree(chan_name); > + for (j = 0; j < i; j++) { > + dsp_chan = &dsp_ipc->chans[j]; > + mbox_free_channel(dsp_chan->ch); > + } > + > + return ret; > +} > + > +static int imx_dsp_remove(struct platform_device *pdev) > +{ > + struct imx_dsp_chan *dsp_chan; > + struct imx_dsp_ipc *dsp_ipc; > + int i; > + > + dsp_ipc = dev_get_drvdata(&pdev->dev); > + > + for (i = 0; i < DSP_MU_CHAN_NUM; i++) { > + dsp_chan = &dsp_ipc->chans[i]; > + mbox_free_channel(dsp_chan->ch); > + } > + > + return 0; > +} > + > +static struct platform_driver imx_dsp_driver = { > + .driver = { > + .name = "imx-dsp", > + }, > + .probe = imx_dsp_probe, > + .remove = imx_dsp_remove, > +}; > +builtin_platform_driver(imx_dsp_driver); > + > +MODULE_AUTHOR("Daniel Baluta <daniel.baluta(a)nxp.com>"); > +MODULE_DESCRIPTION("IMX DSP IPC protocol driver"); > +MODULE_LICENSE("GPL v2"); > diff --git a/include/linux/firmware/imx/dsp.h b/include/linux/firmware/imx/dsp.h > new file mode 100644 > index 000000000000..7562099c9e46 > --- /dev/null > +++ b/include/linux/firmware/imx/dsp.h > @@ -0,0 +1,67 @@ > +/* SPDX-License-Identifier: GPL-2.0+ */ > +/* > + * Copyright 2019 NXP > + * > + * Header file for the DSP IPC implementation > + */ > + > +#ifndef _IMX_DSP_IPC_H > +#define _IMX_DSP_IPC_H > + > +#include <linux/device.h> > +#include <linux/types.h> > +#include <linux/mailbox_client.h> > + > +#define DSP_MU_CHAN_NUM 4 > + > +struct imx_dsp_chan { > + struct imx_dsp_ipc *ipc; > + struct mbox_client cl; > + struct mbox_chan *ch; > + char *name; > + int idx; > +}; > + > +struct imx_dsp_ops { > + void (*handle_reply)(struct imx_dsp_ipc *ipc); > + void (*handle_request)(struct imx_dsp_ipc *ipc); > +}; > + > +struct imx_dsp_ipc { > + /* Host <-> DSP communication uses 2 txdb and 2 rxdb channels */ > + struct imx_dsp_chan chans[DSP_MU_CHAN_NUM]; > + struct device *dev; > + struct imx_dsp_ops *ops; > + void *private_data; > +}; > + > +static inline void imx_dsp_set_data(struct imx_dsp_ipc *ipc, void *data) > +{ > + if (!ipc) > + return; > + > + ipc->private_data = data; > +} > + > +static inline void *imx_dsp_get_data(struct imx_dsp_ipc *ipc) > +{ > + if (!ipc) > + return NULL; > + > + return ipc->private_data; > +} > + > +#if IS_ENABLED(CONFIG_IMX_DSP) > + > +int imx_dsp_ring_doorbell(struct imx_dsp_ipc *dsp, unsigned int chan_idx); > + > +#else > + > +static inline int imx_dsp_ring_doorbell(struct imx_dsp_ipc *ipc, > + unsigned int chan_idx) > +{ > + return -ENOTSUPP; > +} > + > +#endif > +#endif /* _IMX_DSP_IPC_H */ > -- > 2.17.1 >

1 0

[Sound-open-firmware] [PATCH v2 0/5] Add DSP node for i.MX8QXP board to be used by DSP SOF driver
by Daniel Baluta 08 Aug '19

08 Aug '19

i.MX8QXP boards feature an Hifi4 DSP from Tensilica. This patch series aims on adding the DT node describing the DSP, but it also contains the Linux SOF DSP driver that will use the DT node for easier review. Note that we switched to the new yaml format for bindings documentation. The DSP will run SOF Firmware [1]. Patches 1,2,3 are adding support for Linux DSP driver are already sent for review to SOF folks [2] [1] https://github.com/thesofproject/sof [2] https://github.com/thesofproject/linux/pull/1048/commits Changes since v1: - removed 'clk: imx8: Add DSP related clocks' as it was already applied by Shawn - add patches adding support for Linux DSP driver to make things clear for review - add maxItems property for PM in DT bindings doc Daniel Baluta (5): ASoC: SOF: imx: Add i.MX8 HW support ASoC: SOF: topology: Add dummy support for i.MX8 DAIs ASoC: SOF: Add DT DSP device support 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 ++ include/sound/sof/dai.h | 2 + include/uapi/sound/sof/tokens.h | 8 + sound/soc/sof/Kconfig | 10 + sound/soc/sof/Makefile | 4 + sound/soc/sof/imx/Kconfig | 21 + sound/soc/sof/imx/Makefile | 7 + sound/soc/sof/imx/imx8.c | 464 ++++++++++++++++++ sound/soc/sof/sof-dt-dev.c | 159 ++++++ sound/soc/sof/topology.c | 30 ++ 12 files changed, 828 insertions(+) create mode 100644 Documentation/devicetree/bindings/dsp/fsl,dsp.yaml create mode 100644 sound/soc/sof/imx/Kconfig create mode 100644 sound/soc/sof/imx/Makefile create mode 100644 sound/soc/sof/imx/imx8.c create mode 100644 sound/soc/sof/sof-dt-dev.c -- 2.17.1

5 18

[Sound-open-firmware] [PATCH v3 0/5] Add DSP node for i.MX8QXP board to be used by DSP SOF driver
by Daniel Baluta 07 Aug '19

07 Aug '19

i.MX 8QXP boards feature an Hifi4 DSP from Tensilica. This patch series aims on adding the DT node describing the DSP, but it also contains the Linux SOF DSP driver code that will use the DT node for easier review. Note that we switched to the new yaml format for bindings documentation. The DSP will run SOF Firmware [1]. Patches 1,2,3 are adding support for Linux DSP driver are already sent for review to SOF folks [2] Ideally, patches 4/5 and 5/5 will go upstream through Shawn's tree while 1-3/5 will go upstream via Pierre's tree -> ASoC tree. Mind that SOF DSP support depends on IMX DSP communication protocol up for review here: https://lkml.org/lkml/2019/8/1/260 Shawn, can you pick this up first? Symbol dependencies are hopefully set correct so even if one of the patches is not in a tree the compilation will not fail because the symbols depending on that patches will not be selected. [1] https://github.com/thesofproject/sof [2] https://github.com/thesofproject/linux/pull/1048/commits Daniel Baluta (5): ASoC: SOF: Add OF DSP device support ASoC: SOF: imx: Add i.MX8 HW support ASoC: SOF: topology: Add dummy support for i.MX8 DAIs arm64: dts: imx8qxp: Add DSP DT node dt-bindings: dsp: fsl: Add DSP core binding support .../devicetree/bindings/dsp/fsl,dsp.yaml | 88 ++++ arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4 + arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 32 ++ include/sound/sof/dai.h | 2 + include/uapi/sound/sof/tokens.h | 8 + sound/soc/sof/Kconfig | 11 + sound/soc/sof/Makefile | 4 + sound/soc/sof/imx/Kconfig | 22 + sound/soc/sof/imx/Makefile | 4 + sound/soc/sof/imx/imx8.c | 394 ++++++++++++++++++ sound/soc/sof/sof-of-dev.c | 143 +++++++ sound/soc/sof/topology.c | 30 ++ 12 files changed, 742 insertions(+) create mode 100644 Documentation/devicetree/bindings/dsp/fsl,dsp.yaml create mode 100644 sound/soc/sof/imx/Kconfig create mode 100644 sound/soc/sof/imx/Makefile create mode 100644 sound/soc/sof/imx/imx8.c create mode 100644 sound/soc/sof/sof-of-dev.c -- 2.17.1

1 5

[Sound-open-firmware] host_dma_cb() error: Wrong callback type = 3
by Paul Olaru 06 Aug '19

06 Aug '19

Hello, I'm currently implementing the DMA driver for the IMX platform (Dummy DMA). With this partial implementation I have noticed the error message in the title. The thing is, within host.c I see that dma_set_cb is called with the type as DMA_CB_TYPE_IRQ | DMA_CB_TYPE_COPY (which is 3), yet in host_dma_cb itself I only see the cases for these bits individually, and it falls into the default case. I've also noticed this in the dai.c file.

3 6

[Sound-open-firmware] Signed firmware availability for kbl/cnl
by Daniel Drake 05 Aug '19

05 Aug '19

Hi, Thanks for all the hard work on SOF! We are hoping to try it on consumer products in order to support the internal digital mic, which is not supported when running in HDA mode. Specifically Acer AIO Aspire Z24-890 (Intel i3-8100T) and ASUS MJ401TA (Intel m3-8100Y) are two models we have in hand right now. I gather from previous discussions that even though the sof source code is public, the resultant binary files need to be signed by Intel before they can be used. Is that correct? If so, when will these be made available? The files that Linux 5.2 is looking for here are: sof-cnl.ri sof-cnl-nocodec.tplg sof-kbl.ri sof-kbl-nocodec.tplg Thanks

6 28

Re: [Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries
by Liam Girdwood 31 Jul '19

31 Jul '19

On Tue, 2019-07-30 at 17:19 -0400, Josh Boyer wrote: > > I don't understand what you're suggesting nor how it would work > > with the > > way the kernel deals with directories. I tried to explain that we > > need > > an intel/sof-production and intel/sof directories, each with > > generic > > names that are symlinked to another location. This helps if you > > want to > > build quirks that select one or the other capabilities by just > > changing > > the firmware directory prefix. Pointers below. > > > > https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4… > > > > https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4… > > > > https://github.com/thesofproject/linux/blob/9d7da69a1e85db2cdbbaae78dd7eda4… So the commit did support this, but it would put all "production" signed binaries at the intel/sof/ level via soft links (to be automatically loaded by the driver as the default). A subsequent commit would have added the community signed images. I planned to link community signed binaries at the intel/sof/community level since most users would use the production signed images by default (and would not need to use a module param to select). My assumption was that machines using community signed by default would have this in their default_fw_path ? > > > > I guess we need to talk off-line since we are evidently not on the > > same > > page or something is missing for people to use this pull request. > > I suggest you guys do that. At the moment, I'm not pulling anything > related to this until it has a signoff from both you and Liam in the > commit logs at a minimum. Yep, no problem - Pierre and I will refine and resend shortly. I also need to remove links for aliases. Thanks Liam

1 0

[Sound-open-firmware] Audio miniconf + sof meeting at ELCE, Lyon
by Daniel Baluta 31 Jul '19

31 Jul '19

Hi Mark, Pierre, Liam, Ranjani, Will you be in Lyon for ELCE this year? I'm very interested in participating to an (eventual) audio miniconf meeting. Maybe we can also do a separate SOF meeting if they are enough people interested.

2 1

[Sound-open-firmware] [GIT PULL] SOF v1.3 firmware binaries
by Liam Girdwood 30 Jul '19

30 Jul '19

The following changes since commit dff98c6c57383fe343407bcb7b6e775e0b87274f: Merge branch 'master' of git://github.com/skeggsb/linux-firmware (2019-07-26 07:32:37 -0400) are available in the Git repository at: https://github.com/thesofproject/linux-firmware.git sof-v1.3 for you to fetch changes up to cde3a116cea96976125b9215b303edfda85c9b54: sof: Add Intel SOF V1.3 release firmware binaries. (2019-07-30 16:06:41 +0100) ---------------------------------------------------------------- Liam Girdwood (1): sof: Add Intel SOF V1.3 release firmware binaries. LICENCE.sof | 1090 ++++++++++++++++++++++++++ WHENCE | 33 + intel/sof/apl/intel/sof-apl-v1.3.ri | Bin 0 -> 270336 bytes intel/sof/bdw/sof-bdw-v1.3.ri | Bin 0 -> 100144 bytes intel/sof/byt/sof-byt-v1.3.ri | Bin 0 -> 89668 bytes intel/sof/cht/sof-cht-v1.3.ri | Bin 0 -> 90484 bytes intel/sof/cnl/intel/sof-cnl-v1.3-6cc8da10.ri | Bin 0 -> 274432 bytes intel/sof/icl/intel/sof-icl-v1.3.ri | Bin 0 -> 278528 bytes intel/sof/sof-apl.ri | 1 + intel/sof/sof-bdw.ri | 1 + intel/sof/sof-byt.ri | 1 + intel/sof/sof-cht.ri | 1 + intel/sof/sof-cml.ri | 1 + intel/sof/sof-cnl.ri | 1 + intel/sof/sof-glk.ri | 1 + intel/sof/sof-icl.ri | 1 + intel/sof/sof-whl.ri | 1 + 17 files changed, 1132 insertions(+) create mode 100644 LICENCE.sof create mode 100644 intel/sof/apl/intel/sof-apl-v1.3.ri create mode 100644 intel/sof/bdw/sof-bdw-v1.3.ri create mode 100644 intel/sof/byt/sof-byt-v1.3.ri create mode 100644 intel/sof/cht/sof-cht-v1.3.ri create mode 100644 intel/sof/cnl/intel/sof-cnl-v1.3-6cc8da10.ri create mode 100644 intel/sof/icl/intel/sof-icl-v1.3.ri create mode 120000 intel/sof/sof-apl.ri create mode 120000 intel/sof/sof-bdw.ri create mode 120000 intel/sof/sof-byt.ri create mode 120000 intel/sof/sof-cht.ri create mode 120000 intel/sof/sof-cml.ri create mode 120000 intel/sof/sof-cnl.ri create mode 120000 intel/sof/sof-glk.ri create mode 120000 intel/sof/sof-icl.ri create mode 120000 intel/sof/sof-whl.ri

2 3

[Sound-open-firmware] Questions about the SOF coredump reader
by Paul Olaru 26 Jul '19

26 Jul '19

I'm trying to diagnose a few issues on the IMX platform and it would be nice if I would be able to interpret panics and exceptions. I have just fixed a minor issue so that the debugfs "exception" entry is correct. I would like to know if the tool in sof/tools/coredumper/sof-coredump-reader.py is usable for interpreting such dumps and how it should be used. Right now, I have inserted a "panic" call in my code (that makes a dump which seems to be in the proper format), but whenever I try to run this tool on that /sys/kernel/debug/sof/exception file it gets exceptions (one about exccause and, if I remove the corresponding code, it messes up the pathname interpretation too, complaining about UTF-8 being invalid - I suspect wrong offsets?). So, how is this tool supposed to be used?

2 2