alsa-devel.alsa-project.org archive mirror
 help / color / mirror / Atom feed
From: "Sridharan, Ranjani" <ranjani.sridharan@intel.com>
To: "Ertman, David M" <david.m.ertman@intel.com>,
	"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
	"tiwai@suse.de" <tiwai@suse.de>,
	"pierre-louis.bossart@linux.intel.com"
	<pierre-louis.bossart@linux.intel.com>,
	"fred.oh@linux.intel.com" <fred.oh@linux.intel.com>,
	"broonie@kernel.org" <broonie@kernel.org>,
	"parav@nvidia.com" <parav@nvidia.com>,
	"jgg@nvidia.com" <jgg@nvidia.com>
Subject: Re: [PATCH 2/6] ASoC: SOF: Introduce descriptors for SOF client
Date: Thu, 1 Oct 2020 15:59:27 +0000	[thread overview]
Message-ID: <afb06d91c6ad5facbac3d9059075a0c32f7ed831.camel@intel.com> (raw)
In-Reply-To: <20201001130245.GB2378679@kroah.com>

On Thu, 2020-10-01 at 15:02 +0200, Greg KH wrote:
> On Wed, Sep 30, 2020 at 03:50:47PM -0700, Dave Ertman wrote:
> > From: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> > 
> > A client in the SOF (Sound Open Firmware) context is a
> > device that needs to communicate with the DSP via IPC
> > messages. The SOF core is responsible for serializing the
> > IPC messages to the DSP from the different clients. One
> > example of an SOF client would be an IPC test client that
> > floods the DSP with test IPC messages to validate if the
> > serialization works as expected. Multi-client support will
> > also add the ability to split the existing audio cards
> > into multiple ones, so as to e.g. to deal with HDMI with a
> > dedicated client instead of adding HDMI to all cards.
> > 
> > This patch introduces descriptors for SOF client driver
> > and SOF client device along with APIs for registering
> > and unregistering a SOF client driver, sending IPCs from
> > a client device and accessing the SOF core debugfs root entry.
> > 
> > Along with this, add a couple of new members to struct
> > snd_sof_dev that will be used for maintaining the list of
> > clients.
> > 
> > Reviewed-by: Pierre-Louis Bossart <
> > pierre-louis.bossart@linux.intel.com>
> > Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com
> > >
> > Co-developed-by: Fred Oh <fred.oh@linux.intel.com>
> > Signed-off-by: Fred Oh <fred.oh@linux.intel.com>
> > Signed-off-by: Dave Ertman <david.m.ertman@intel.com>
> > ---
> >  sound/soc/sof/Kconfig      |  19 ++++++
> >  sound/soc/sof/Makefile     |   3 +
> >  sound/soc/sof/core.c       |   2 +
> >  sound/soc/sof/sof-client.c | 117
> > +++++++++++++++++++++++++++++++++++++
> >  sound/soc/sof/sof-client.h |  65 +++++++++++++++++++++
> >  sound/soc/sof/sof-priv.h   |   6 ++
> >  6 files changed, 212 insertions(+)
> >  create mode 100644 sound/soc/sof/sof-client.c
> >  create mode 100644 sound/soc/sof/sof-client.h
> 
> As you are creating new sysfs directories, you should have some
> documentation for them :(
> 
> > diff --git a/sound/soc/sof/Kconfig b/sound/soc/sof/Kconfig
> > index 4dda4b62509f..cea7efedafef 100644
> > --- a/sound/soc/sof/Kconfig
> > +++ b/sound/soc/sof/Kconfig
> > @@ -50,6 +50,24 @@ config SND_SOC_SOF_DEBUG_PROBES
> >  	  Say Y if you want to enable probes.
> >  	  If unsure, select "N".
> >  
> > +config SND_SOC_SOF_CLIENT
> > +	tristate
> > +	select ANCILLARY_BUS
> > +	help
> > +	  This option is not user-selectable but automagically handled
> > by
> > +	  'select' statements at a higher level
> > +
> > +config SND_SOC_SOF_CLIENT_SUPPORT
> > +	bool "SOF enable clients"
> > +	depends on SND_SOC_SOF
> > +	help
> > +	  This adds support for ancillary client devices to separate
> > out the debug
> > +	  functionality for IPC tests, probes etc. into separate
> > devices. This
> > +	  option would also allow adding client devices based on DSP FW
> > +	  capabilities and ACPI/OF device information.
> > +	  Say Y if you want to enable clients with SOF.
> > +	  If unsure select "N".
> > +
> >  config SND_SOC_SOF_DEVELOPER_SUPPORT
> >  	bool "SOF developer options support"
> >  	depends on EXPERT
> > @@ -186,6 +204,7 @@ endif ## SND_SOC_SOF_DEVELOPER_SUPPORT
> >  
> >  config SND_SOC_SOF
> >  	tristate
> > +	select SND_SOC_SOF_CLIENT if SND_SOC_SOF_CLIENT_SUPPORT
> >  	select SND_SOC_TOPOLOGY
> >  	select SND_SOC_SOF_NOCODEC if SND_SOC_SOF_NOCODEC_SUPPORT
> >  	help
> > diff --git a/sound/soc/sof/Makefile b/sound/soc/sof/Makefile
> > index 05718dfe6cd2..5e46f25a3851 100644
> > --- a/sound/soc/sof/Makefile
> > +++ b/sound/soc/sof/Makefile
> > @@ -2,6 +2,7 @@
> >  
> >  snd-sof-objs := core.o ops.o loader.o ipc.o pcm.o pm.o debug.o
> > topology.o\
> >  		control.o trace.o utils.o sof-audio.o
> > +snd-sof-client-objs := sof-client.o
> >  snd-sof-$(CONFIG_SND_SOC_SOF_DEBUG_PROBES) += probe.o compress.o
> >  
> >  snd-sof-pci-objs := sof-pci-dev.o
> > @@ -18,6 +19,8 @@ obj-$(CONFIG_SND_SOC_SOF_ACPI) += snd-sof-acpi.o
> >  obj-$(CONFIG_SND_SOC_SOF_OF) += snd-sof-of.o
> >  obj-$(CONFIG_SND_SOC_SOF_PCI) += snd-sof-pci.o
> >  
> > +obj-$(CONFIG_SND_SOC_SOF_CLIENT) += snd-sof-client.o
> > +
> >  obj-$(CONFIG_SND_SOC_SOF_INTEL_TOPLEVEL) += intel/
> >  obj-$(CONFIG_SND_SOC_SOF_IMX_TOPLEVEL) += imx/
> >  obj-$(CONFIG_SND_SOC_SOF_XTENSA) += xtensa/
> > diff --git a/sound/soc/sof/core.c b/sound/soc/sof/core.c
> > index adc7c37145d6..72a97219395f 100644
> > --- a/sound/soc/sof/core.c
> > +++ b/sound/soc/sof/core.c
> > @@ -314,8 +314,10 @@ int snd_sof_device_probe(struct device *dev,
> > struct snd_sof_pdata *plat_data)
> >  	INIT_LIST_HEAD(&sdev->widget_list);
> >  	INIT_LIST_HEAD(&sdev->dai_list);
> >  	INIT_LIST_HEAD(&sdev->route_list);
> > +	INIT_LIST_HEAD(&sdev->client_list);
> >  	spin_lock_init(&sdev->ipc_lock);
> >  	spin_lock_init(&sdev->hw_lock);
> > +	mutex_init(&sdev->client_mutex);
> >  
> >  	if (IS_ENABLED(CONFIG_SND_SOC_SOF_PROBE_WORK_QUEUE))
> >  		INIT_WORK(&sdev->probe_work, sof_probe_work);
> > diff --git a/sound/soc/sof/sof-client.c b/sound/soc/sof/sof-
> > client.c
> > new file mode 100644
> > index 000000000000..f7e476d99ff6
> > --- /dev/null
> > +++ b/sound/soc/sof/sof-client.c
> > @@ -0,0 +1,117 @@
> > +// SPDX-License-Identifier: GPL-2.0-only
> > +//
> > +// Copyright(c) 2020 Intel Corporation. All rights reserved.
> > +//
> > +// Author: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
> > +//
> > +
> > +#include <linux/debugfs.h>
> > +#include <linux/errno.h>
> > +#include <linux/list.h>
> > +#include <linux/module.h>
> > +#include <linux/mutex.h>
> > +#include <linux/slab.h>
> > +#include "sof-client.h"
> > +#include "sof-priv.h"
> > +
> > +static void sof_client_ancildev_release(struct device *dev)
> > +{
> > +	struct ancillary_device *ancildev = to_ancillary_dev(dev);
> > +	struct sof_client_dev *cdev =
> > ancillary_dev_to_sof_client_dev(ancildev);
> > +
> > +	ida_simple_remove(cdev->client_ida, ancildev->id);
> > +	kfree(cdev);
> > +}
> > +
> > +static struct sof_client_dev *sof_client_dev_alloc(struct
> > snd_sof_dev *sdev, const char *name,
> > +						   struct ida
> > *client_ida)
> > +{
> > +	struct sof_client_dev *cdev;
> > +	struct ancillary_device *ancildev;
> > +	int ret;
> > +
> > +	cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
> > +	if (!cdev)
> > +		return NULL;
> > +
> > +	cdev->sdev = sdev;
> 
> No reference counting?  How can you guarantee the lifespan is ok?
> 
> > +	cdev->client_ida = client_ida;
> > +	ancildev = &cdev->ancildev;
> > +	ancildev->name = name;
> > +	ancildev->dev.parent = sdev->dev;
> 
> Ah, you guarantee it by making it the parent.  Sneaky, but is it
> really
> needed?
Thanks for your review, Greg.
This is needed because ancillary_device_initialize() actually requires
the parent to be set as a precondition for it to succeed.
> 
> > +	ancildev->dev.release = sof_client_ancildev_release;
> > +
> > +	ancildev->id = ida_alloc(client_ida, GFP_KERNEL);
> > +	if (ancildev->id < 0) {
> > +		dev_err(sdev->dev, "error: get IDA idx for ancillary
> > device %s failed\n", name);
> > +		ret = ancildev->id;
> > +		goto err_free;
> > +	}
> > +
> > +	ret = ancillary_device_initialize(ancildev);
> > +	if (ret < 0) {
> > +		dev_err(sdev->dev, "error: failed to initialize client
> > dev %s\n", name);
> > +		ida_simple_remove(client_ida, ancildev->id);
> > +		goto err_free;
> > +	}
> > +
> > +	return cdev;
> > +
> > +err_free:
> > +	kfree(cdev);
> > +	return NULL;
> > +}
> > +
> > +int sof_client_dev_register(struct snd_sof_dev *sdev, const char
> > *name, struct ida *client_ida)
> > +{
> > +	struct sof_client_dev *cdev;
> > +	int ret;
> > +
> > +	cdev = sof_client_dev_alloc(sdev, name, client_ida);
> > +	if (!cdev)
> > +		return -ENODEV;
> > +
> > +	ret = ancillary_device_add(&cdev->ancildev);
> 
> Why have you split this up into two calls?  Why not just
> "sof_client_dev_create() or something like that?
> 
> Having to make a sof_* call, and then a separate ancillary_device_*
> call
> feels pretty ackward, right?
The split was suggested to make the error unwind calls more intuitive.
In the case of sof_client_dev_alloc() failure, we'd free the IDA and
free the cdev. Whereas in the case of ancillary_device_add() failure,
we'd rely upon put_device() to free the memory.

But as far as users go, they only call they'd need to make to register
a client is sof_client_dev_register().
> 
> 
> > +	if (ret < 0) {
> > +		dev_err(sdev->dev, "error: failed to add client dev
> > %s\n", name);
> > +		put_device(&cdev->ancildev.dev);
> 
> Ugh that's a deep knowledge of the ancil code, would be nicer if the
> caller function handled all of that for you, right?
> 
> > +		return ret;
> > +	}
> > +
> > +	/* add to list of SOF client devices */
> > +	mutex_lock(&sdev->client_mutex);
> > +	list_add(&cdev->list, &sdev->client_list);
> > +	mutex_unlock(&sdev->client_mutex);
> > +
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(sof_client_dev_register, SND_SOC_SOF_CLIENT);
> > +
> > +void sof_client_dev_unregister(struct sof_client_dev *cdev)
> > +{
> > +	struct snd_sof_dev *sdev = cdev->sdev;
> > +
> > +	/* remove from list of SOF client devices */
> > +	mutex_lock(&sdev->client_mutex);
> > +	list_del(&cdev->list);
> > +	mutex_unlock(&sdev->client_mutex);
> 
> So you add and remove things from the list, but do not do anything
> with
> that list?  Why a list at all?
In the current implementation, we dont really use the list but as we
add more clients SOF driver, the list will be used to determine which
client to pass the IPC messages from the DSP to for example.
> 
> > +
> > +	ancillary_device_unregister(&cdev->ancildev);
> 
> Does this free the expected memory?  I think so, but commenting that
> it
> does is nice :)
Sure, will do.
> 
> > +}
> > +EXPORT_SYMBOL_NS_GPL(sof_client_dev_unregister,
> > SND_SOC_SOF_CLIENT);
> > +
> > +int sof_client_ipc_tx_message(struct sof_client_dev *cdev, u32
> > header, void *msg_data,
> > +			      size_t msg_bytes, void *reply_data,
> > size_t reply_bytes)
> > +{
> > +	return sof_ipc_tx_message(cdev->sdev->ipc, header, msg_data,
> > msg_bytes,
> > +				  reply_data, reply_bytes);
> > +}
> > +EXPORT_SYMBOL_NS_GPL(sof_client_ipc_tx_message,
> > SND_SOC_SOF_CLIENT);
> > +
> > +struct dentry *sof_client_get_debugfs_root(struct sof_client_dev
> > *cdev)
> > +{
> > +	return cdev->sdev->debugfs_root;
> > +}
> > +EXPORT_SYMBOL_NS_GPL(sof_client_get_debugfs_root,
> > SND_SOC_SOF_CLIENT);
> > +
> > +MODULE_LICENSE("GPL");
> > diff --git a/sound/soc/sof/sof-client.h b/sound/soc/sof/sof-
> > client.h
> > new file mode 100644
> > index 000000000000..62212f69c236
> > --- /dev/null
> > +++ b/sound/soc/sof/sof-client.h
> > @@ -0,0 +1,65 @@
> > +/* SPDX-License-Identifier: (GPL-2.0-only) */
> 
> Why the "()"?
Will remove.

Thanks,
Ranjani

  reply	other threads:[~2020-10-01 16:00 UTC|newest]

Thread overview: 99+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-30 22:50 [PATCH 0/6] Ancillary bus implementation and SOF multi-client support Dave Ertman
2020-09-30 22:50 ` [PATCH 1/6] Add ancillary bus support Dave Ertman
2020-09-30 23:05   ` Jason Gunthorpe
2020-10-01 11:01   ` Greg KH
2020-10-01 11:46     ` Jason Gunthorpe
2020-10-01 11:54       ` Greg KH
2020-10-01 12:02         ` Jason Gunthorpe
2020-10-01 12:15           ` Greg KH
2020-10-01 18:26             ` Ertman, David M
2020-10-01 11:02   ` Greg KH
2020-10-01 16:30     ` Ertman, David M
2020-10-01 11:05   ` Greg KH
2020-10-01 11:58     ` Jason Gunthorpe
2020-10-01 12:14       ` Greg KH
2020-10-01 14:33         ` Jason Gunthorpe
2020-10-01 14:38           ` Greg KH
2020-10-01 16:06             ` Pierre-Louis Bossart
2020-10-01 17:42             ` Jason Gunthorpe
2020-10-01 14:39           ` Parav Pandit
2020-10-01 14:43             ` Greg KH
2020-10-01 13:27   ` Mark Brown
2020-09-30 22:50 ` [PATCH 2/6] ASoC: SOF: Introduce descriptors for SOF client Dave Ertman
2020-10-01 13:02   ` Greg KH
2020-10-01 15:59     ` Sridharan, Ranjani [this message]
2020-10-01 22:16     ` Sridharan, Ranjani
2020-10-02  4:53       ` gregkh
2020-10-02 17:07         ` Sridharan, Ranjani
2020-10-03  9:02           ` gregkh
2020-10-05  2:35             ` Sridharan, Ranjani
2020-10-05 11:27               ` gregkh
2020-10-05 15:18                 ` Pierre-Louis Bossart
2020-10-05 15:32                   ` gregkh
2020-10-01 13:38   ` Mark Brown
2020-10-01 16:48     ` Sridharan, Ranjani
2020-09-30 22:50 ` [PATCH 3/6] ASoC: SOF: Create client driver for IPC test Dave Ertman
2020-10-01 13:04   ` Greg KH
2020-10-01 16:46     ` Sridharan, Ranjani
2020-10-01 13:09   ` Greg KH
2020-10-01 13:55     ` Pierre-Louis Bossart
2020-10-01 16:48       ` Ertman, David M
2020-10-01 13:59   ` Mark Brown
2020-09-30 22:50 ` [PATCH 4/6] ASoC: SOF: ops: Add ops for client registration Dave Ertman
2020-09-30 22:50 ` [PATCH 5/6] ASoC: SOF: Intel: Define " Dave Ertman
2020-09-30 22:50 ` [PATCH 6/6] ASoC: SOF: debug: Remove IPC flood test support in SOF core Dave Ertman
2020-10-01  5:58 ` [PATCH 0/6] Ancillary bus implementation and SOF multi-client support Greg KH
2020-10-01 15:54   ` Ertman, David M
2020-10-01  7:14 ` Greg KH
2020-10-01 15:55   ` Ertman, David M
2020-10-01 16:10     ` Greg KH
2020-10-01 17:13       ` Ertman, David M
2020-10-02 20:23   ` Ertman, David M
2020-10-03  9:08     ` Greg KH
2020-10-03  9:09       ` Greg KH
2020-10-04  2:26       ` Parav Pandit
2020-10-04 23:45       ` Williams, Dan J
2020-10-05  1:18         ` Ertman, David M
2020-10-05  2:39           ` Parav Pandit
2020-10-05 11:25         ` gregkh
2020-10-06 22:40           ` Dan Williams
2020-10-07  9:14             ` gregkh
2020-10-07 16:19               ` Dan Williams
2020-10-07 16:22                 ` Mark Brown
2020-10-07 16:41                   ` Dan Williams
2020-10-07 16:42                   ` Pierre-Louis Bossart
2020-10-07 16:56                     ` Parav Pandit
2020-10-01 10:05 ` Rojewski, Cezary
2020-10-01 10:59   ` gregkh
2020-10-01 12:49     ` Jason Gunthorpe
2020-10-01 12:55       ` gregkh
2020-10-01 13:26         ` Jason Gunthorpe
2020-10-01 14:17           ` gregkh
2020-10-01 15:08         ` Parav Pandit
2020-10-01 12:50 ` Mark Brown
2020-10-01 13:12   ` Greg KH
2020-10-01 13:42     ` Jason Gunthorpe
2020-10-01 14:40     ` Mark Brown
2020-10-01 15:32       ` Greg KH
2020-10-01 16:03         ` Mark Brown
2020-10-01 18:16           ` Greg KH
2020-10-01 18:29             ` Ertman, David M
2020-10-01 19:38               ` Mark Brown
2020-10-01 19:54                 ` Ertman, David M
2020-10-01 20:17                   ` Mark Brown
2020-10-02  0:47                     ` Jason Gunthorpe
2020-10-02 11:19                       ` Mark Brown
2020-10-02 17:23                         ` Ertman, David M
2020-10-02 17:25                           ` Jason Gunthorpe
2020-10-02 17:44                             ` Mark Brown
2020-10-01 14:07   ` Pierre-Louis Bossart
2020-10-01 15:24     ` Mark Brown
2020-10-01 16:20       ` Pierre-Louis Bossart
2020-10-01 16:51         ` Mark Brown
2020-10-01 18:04           ` Jason Gunthorpe
2020-10-01 18:13             ` Greg KH
2020-10-01 19:23             ` Mark Brown
2020-10-01 16:50     ` Ertman, David M
2020-10-01 17:10       ` Mark Brown
2020-10-01 17:16         ` Ertman, David M
2020-10-01 17:52 ` Ertman, David M

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=afb06d91c6ad5facbac3d9059075a0c32f7ed831.camel@intel.com \
    --to=ranjani.sridharan@intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=broonie@kernel.org \
    --cc=david.m.ertman@intel.com \
    --cc=fred.oh@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jgg@nvidia.com \
    --cc=parav@nvidia.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=tiwai@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).