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

[Sound-open-firmware] Backport of SOF driver to 5.2.9 fixes
by Mark Pearson 25 Sep '19

25 Sep '19

Hi SOF folks, I've been able to address the issue I was seeing with 5.2.9 kernel and the SOF driver on our whiskeylake based system but would really appreciate a quick review from the experts to confirm that I've not missed anything important or add any extra insight. The problem was seen on boot - the driver suspends and resumes a couple of times during boot and during the second resume failed to load the firmware (err -110). After that point the driver, and hence the audio, isn't useable. I backported these commits to address the problem: https://github.com/thesofproject/linux/commit/bf705eaa7ce07f9c132f8e367fc2f… https://github.com/thesofproject/linux/commit/64632de9140e52b72781fefe54231… https://github.com/thesofproject/linux/commit/7623ae793c28cc0928c5d1292542d… https://github.com/thesofproject/linux/commit/f5dbba9fee801f4678a50d92c785f… https://github.com/thesofproject/linux/commit/bb1ea3b31c28a131a5f5a50dd3251… We're still doing some testing to get confidence the fix is correct and stable but so far it looks good - everything is working. Thanks Mark

3 3

[Sound-open-firmware] Questions about the pause-release flow
by Paul Olaru 16 Sep '19

16 Sep '19

Right now I have a working (but not yet cleaned up) set of drivers (host DMA, DAI DMA and DAI itself) and I figured I could test for pause-release (even if the rates seem incorrect; can't actually check for correctness until the codec driver is also ready). The issue I encountered is: I can pause, however whenever I press <SPACE> again on aplay, I get "pause release error: Invalid argument" and the SOF log shows "dai_comp_trigger(), PAUSE/STOP" immediately followed by a -22 (-EINVAL) return code from pipeline_trigger. Shouldn't unpausing actually send COMP_TRIGGER_RELEASE? I am doing my own state checking but I suspect it may be wrong. What should I look into, and is this actually correct behavior?

2 4

[Sound-open-firmware] Whiskeylake support and kernel version
by Mark Pearson 15 Sep '19

15 Sep '19

Hi, I'm working on bringing up Debian on a Whiskeylake based system and having some problems with the audio not working. I'm running a 5.2.9 kernel with the 1.3 SOF firmware - will that support whiskeylake or do I need to update to newer (I also have a cometlake system and I needed 5.3 there - but it was more obvious in the kernel configuration) Thanks! Mark

4 12

[Sound-open-firmware] Status of Braswell
by Curtis Malainey 11 Sep '19

11 Sep '19

Hello SOF team, I am just curious what the status of Braswell devices are right now. If the status is unknown that is fine. I may be doing some experimenting with them in the near future. Any known issues or caveats would be appreciated. :) Curtis

3 8

[Sound-open-firmware] Questions about the DAI DMA/pipeline flow
by Paul Olaru 05 Sep '19

05 Sep '19

Hello, I'm currently having issues with implementing the DAI DMA driver on my platform. Whenever the DAI component calls start(), the preload transfer finishes too quickly and The callback, pipeline_schedule_copy() (called by dai_cb), encounters an issue about the copy task being already queued. Then I see that the copy task doesn't run again (the scheduler must believe it's already done working and that extra schedule() needs to be ignored). What should be the way to go from this? Should I investigate why the preload finishes too quickly? Should I do some hacks to delay the finishing of the preload? Should I tweak the buffer sizes (the current transfer buffer size is exactly 384 bytes, which works out as 48 samples per channel, 2 channels, 4 byte wide samples, AKA exactly 1ms). Should I try to figure out a way to make the scheduler run pipeline_copy() again after the current (preload) one finishes?

3 5

[Sound-open-firmware] System Controller Unit firmware code inside SOF
by Daniel Baluta 03 Sep '19

03 Sep '19

Hi Liam / Pierre, I want to hear your take on the following. On some of our i.MX platforms most of the critical functions like PM, clocks, interrupts are handled by a special core name SCU (System Controller Unit). It runs a special firmware (SCFW). In order for our DSP core to communicate with SCU it needs to use a special interface exported by the SCFW. The interface is BSD-3 Clause licensed. Anyhow, as you might expect the coding style / file naming / organization is firmware like. That means very very different from what we have in SOF. Do you think such an interface would be acceptable to be merged in SOF? Or should we spent some time to rewrite it from scratch to match the quality of the existing SOF code? The bad part in rewriting it from scratch is that we need to update-it by hand each time the SCFW interface changes. thanks, Daniel.

3 2

[Sound-open-firmware] Machine driver for pcm512x
by Daniel Baluta 03 Sep '19

03 Sep '19

Hi all, I'm looking at sof-apl-pcm512x-nohdmi.m4 scenario in SOF (I choose this because it looks to be the simplest scenario that also involves a codec). But I couldn't find the machine driver corresponding to this in Linux kernel code. Any idea? Daniel.

3 2

[Sound-open-firmware] Questions about the DMA driver flow in SOF
by Paul Olaru 30 Aug '19

30 Aug '19

I need to understand the general flow on how a DMA driver should Work in SOF. In particular what each callback should do. I get channel_get, channel_put, start, stop, pause, release (although I don't quite get the nuance between stop and pause, or between start and release; thankfully I hope it's not important if I treat them the same). I get most of the others too, at least for the most part. What I don't get at all is how the copy callback should work. In the DW DMA driver it seems to just run the callback and do something based on what the callback set in next, in HDA it seems to wait for the host buffer to be full or empty (I think this one may be the more intuitive one?) and the link HDA DMA seems to again just run the callback. What should the copy callback really do? Is it different between a host DMA and a DAI DMA?

2 4

[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