| Message ID | 20200930225051.889607-3-david.m.ertman@intel.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Ancillary bus implementation and SOF multi-client support | expand |
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? > + 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? > + 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? > + > + ancillary_device_unregister(&cdev->ancildev); Does this free the expected memory? I think so, but commenting that it does is nice :) > +} > +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 "()"? thanks, greg k-h
On Wed, Sep 30, 2020 at 03:50:47PM -0700, Dave Ertman wrote: > + 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); It would be nice to have the ida_simple_remove() done in this unwind section here too for consistency. > +int sof_client_dev_register(struct snd_sof_dev *sdev, const char *name, struct ida *client_ida) > +{ I know the hard limit on line length got raised but can we wrap this please?
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
On Thu, 2020-10-01 at 14:38 +0100, Mark Brown wrote: > On Wed, Sep 30, 2020 at 03:50:47PM -0700, Dave Ertman wrote: > > > + 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); > > It would be nice to have the ida_simple_remove() done in this unwind > section here too for consistency. ack > > > +int sof_client_dev_register(struct snd_sof_dev *sdev, const char > > *name, struct ida *client_ida) > > +{ > > I know the hard limit on line length got raised but can we wrap this > please? ack. Thanks,Ranjani
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 :( Hi Greg, We are not adding any sysfs entries in this series. Thanks, Ranjani
On Thu, Oct 01, 2020 at 10:16:00PM +0000, Sridharan, Ranjani wrote: > 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 :( > Hi Greg, > > We are not adding any sysfs entries in this series. You added directories in sysfs, right?
On Fri, 2020-10-02 at 06:53 +0200, gregkh@linuxfoundation.org wrote: > On Thu, Oct 01, 2020 at 10:16:00PM +0000, Sridharan, Ranjani wrote: > > 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 :( > > Hi Greg, > > > > We are not adding any sysfs entries in this series. > > You added directories in sysfs, right? Hi Greg, We are not adding any sysfs directories. The only change in the /sys directory will be the new ancillary devices created in the /sys/bus/ancillary/devices directory ie snd_sof_client.ipc_test.0 and snd_sof_client.ipc_test.1. In the following patches, we're adding debugfs entries for the ipc test clients but no other sysfs changes. Is it required to add documentation for these as well? Thanks, Ranjani
On Fri, Oct 02, 2020 at 05:07:13PM +0000, Sridharan, Ranjani wrote: > On Fri, 2020-10-02 at 06:53 +0200, gregkh@linuxfoundation.org wrote: > > On Thu, Oct 01, 2020 at 10:16:00PM +0000, Sridharan, Ranjani wrote: > > > 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 :( > > > Hi Greg, > > > > > > We are not adding any sysfs entries in this series. > > > > You added directories in sysfs, right? > Hi Greg, > > We are not adding any sysfs directories. Really? Then what does creating these new devices do in sysfs? If nothing, then why are they being used at all? :) > The only change in the /sys directory will be the new ancillary > devices created in the /sys/bus/ancillary/devices directory ie > snd_sof_client.ipc_test.0 and snd_sof_client.ipc_test.1. That is what I was referring to. > In the following patches, we're adding debugfs entries for the ipc > test clients but no other sysfs changes. > > Is it required to add documentation for these as well? Why would you not document them? If you don't do anything with these devices, then why even use them? debugfs does not require sysfs entries, so I fail to see the need for using this api at all here... thanks, greg k-h
On Sat, 2020-10-03 at 11:02 +0200, gregkh@linuxfoundation.org wrote: > On Fri, Oct 02, 2020 at 05:07:13PM +0000, Sridharan, Ranjani wrote: > > On Fri, 2020-10-02 at 06:53 +0200, gregkh@linuxfoundation.org > > wrote: > > > On Thu, Oct 01, 2020 at 10:16:00PM +0000, Sridharan, Ranjani > > > wrote: > > > > 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 :( > > > > Hi Greg, > > > > > > > > We are not adding any sysfs entries in this series. > > > > > > You added directories in sysfs, right? > > Hi Greg, > > > > We are not adding any sysfs directories. > > Really? Then what does creating these new devices do in sysfs? If > nothing, then why are they being used at all? :) > > > The only change in the /sys directory will be the new ancillary > > devices created in the /sys/bus/ancillary/devices directory ie > > snd_sof_client.ipc_test.0 and snd_sof_client.ipc_test.1. > > That is what I was referring to. > > > In the following patches, we're adding debugfs entries for the ipc > > test clients but no other sysfs changes. > > > > Is it required to add documentation for these as well? > > Why would you not document them? If you don't do anything with these > devices, then why even use them? debugfs does not require sysfs > entries, so I fail to see the need for using this api at all here... Hi Greg, Pardon my ignorance here a bit. Typically, when registering platform devices, we've not added any documentation to highlight how they are used. Of course thats no excuse for not doing this right. But just to clarify so that we can fix this properly in the next version, are we expected to add documentation for the directories added in the /sys/bus (ie /sys/bus/ancillary, /sys/bus/ancillary/devices, /sys/bus/ancillary/drivers etc) and also for the devices and drivers added by the SOF driver? Thanks, Ranjani
On Mon, Oct 05, 2020 at 02:35:09AM +0000, Sridharan, Ranjani wrote: > On Sat, 2020-10-03 at 11:02 +0200, gregkh@linuxfoundation.org wrote: > > On Fri, Oct 02, 2020 at 05:07:13PM +0000, Sridharan, Ranjani wrote: > > > On Fri, 2020-10-02 at 06:53 +0200, gregkh@linuxfoundation.org > > > wrote: > > > > On Thu, Oct 01, 2020 at 10:16:00PM +0000, Sridharan, Ranjani > > > > wrote: > > > > > 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 :( > > > > > Hi Greg, > > > > > > > > > > We are not adding any sysfs entries in this series. > > > > > > > > You added directories in sysfs, right? > > > Hi Greg, > > > > > > We are not adding any sysfs directories. > > > > Really? Then what does creating these new devices do in sysfs? If > > nothing, then why are they being used at all? :) > > > > > The only change in the /sys directory will be the new ancillary > > > devices created in the /sys/bus/ancillary/devices directory ie > > > snd_sof_client.ipc_test.0 and snd_sof_client.ipc_test.1. > > > > That is what I was referring to. > > > > > In the following patches, we're adding debugfs entries for the ipc > > > test clients but no other sysfs changes. > > > > > > Is it required to add documentation for these as well? > > > > Why would you not document them? If you don't do anything with these > > devices, then why even use them? debugfs does not require sysfs > > entries, so I fail to see the need for using this api at all here... > Hi Greg, > > Pardon my ignorance here a bit. Typically, when registering platform > devices, we've not added any documentation to highlight how they are > used. Of course thats no excuse for not doing this right. > > But just to clarify so that we can fix this properly in the next > version, are we expected to add documentation for the directories added > in the /sys/bus (ie /sys/bus/ancillary, /sys/bus/ancillary/devices, > /sys/bus/ancillary/drivers etc) and also for the devices and drivers > added by the SOF driver? You are using a brand-new interface, which is designed to represent things in the driver model and sysfs properly, and yet your usage doesn't actually take advantage of the driver model or sysfs at all? That implies to me that you are using this incorrectly. greg k-h
>>>>>>> As you are creating new sysfs directories, you should have >>>>>>> some >>>>>>> documentation for them :( >>>>>> Hi Greg, >>>>>> >>>>>> We are not adding any sysfs entries in this series. >>>>> >>>>> You added directories in sysfs, right? >>>> Hi Greg, >>>> >>>> We are not adding any sysfs directories. >>> >>> Really? Then what does creating these new devices do in sysfs? If >>> nothing, then why are they being used at all? :) >>> >>>> The only change in the /sys directory will be the new ancillary >>>> devices created in the /sys/bus/ancillary/devices directory ie >>>> snd_sof_client.ipc_test.0 and snd_sof_client.ipc_test.1. >>> >>> That is what I was referring to. >>> >>>> In the following patches, we're adding debugfs entries for the ipc >>>> test clients but no other sysfs changes. >>>> >>>> Is it required to add documentation for these as well? >>> >>> Why would you not document them? If you don't do anything with these >>> devices, then why even use them? debugfs does not require sysfs >>> entries, so I fail to see the need for using this api at all here... >> Hi Greg, >> >> Pardon my ignorance here a bit. Typically, when registering platform >> devices, we've not added any documentation to highlight how they are >> used. Of course thats no excuse for not doing this right. >> >> But just to clarify so that we can fix this properly in the next >> version, are we expected to add documentation for the directories added >> in the /sys/bus (ie /sys/bus/ancillary, /sys/bus/ancillary/devices, >> /sys/bus/ancillary/drivers etc) and also for the devices and drivers >> added by the SOF driver? > > You are using a brand-new interface, which is designed to represent > things in the driver model and sysfs properly, and yet your usage > doesn't actually take advantage of the driver model or sysfs at all? > > That implies to me that you are using this incorrectly. We are taking advantage of 'standard' sysfs capabilities, e.g. we get a power/ directory and can disable pm_runtime if we chose to do so. But the point is that for now we haven't added domain specific properties with attributes. For example, I noodled with this code last week to replace the platform devices with ancillary devices in the Intel SoundWire code, and I get this in sysfs: root@plb:/sys/bus/ancillary/devices/soundwire_intel.link.0# ls -l total 0 lrwxrwxrwx 1 root root 0 Oct 2 15:48 driver -> ../../../../bus/ancillary/drivers/intel-sdw lrwxrwxrwx 1 root root 0 Oct 5 10:12 firmware_node -> ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:63/PRP00001:00 drwxr-xr-x 2 root root 0 Oct 5 10:12 power drwxr-xr-x 5 root root 0 Oct 2 15:48 sdw-master-0 lrwxrwxrwx 1 root root 0 Oct 2 15:48 subsystem -> ../../../../bus/ancillary -rw-r--r-- 1 root root 4096 Oct 2 15:48 uevent What would you want us to document here?
On Mon, Oct 05, 2020 at 10:18:21AM -0500, Pierre-Louis Bossart wrote: > > > > > > > > > As you are creating new sysfs directories, you should have > > > > > > > > some > > > > > > > > documentation for them :( > > > > > > > Hi Greg, > > > > > > > > > > > > > > We are not adding any sysfs entries in this series. > > > > > > > > > > > > You added directories in sysfs, right? > > > > > Hi Greg, > > > > > > > > > > We are not adding any sysfs directories. > > > > > > > > Really? Then what does creating these new devices do in sysfs? If > > > > nothing, then why are they being used at all? :) > > > > > > > > > The only change in the /sys directory will be the new ancillary > > > > > devices created in the /sys/bus/ancillary/devices directory ie > > > > > snd_sof_client.ipc_test.0 and snd_sof_client.ipc_test.1. > > > > > > > > That is what I was referring to. > > > > > > > > > In the following patches, we're adding debugfs entries for the ipc > > > > > test clients but no other sysfs changes. > > > > > > > > > > Is it required to add documentation for these as well? > > > > > > > > Why would you not document them? If you don't do anything with these > > > > devices, then why even use them? debugfs does not require sysfs > > > > entries, so I fail to see the need for using this api at all here... > > > Hi Greg, > > > > > > Pardon my ignorance here a bit. Typically, when registering platform > > > devices, we've not added any documentation to highlight how they are > > > used. Of course thats no excuse for not doing this right. > > > > > > But just to clarify so that we can fix this properly in the next > > > version, are we expected to add documentation for the directories added > > > in the /sys/bus (ie /sys/bus/ancillary, /sys/bus/ancillary/devices, > > > /sys/bus/ancillary/drivers etc) and also for the devices and drivers > > > added by the SOF driver? > > > > You are using a brand-new interface, which is designed to represent > > things in the driver model and sysfs properly, and yet your usage > > doesn't actually take advantage of the driver model or sysfs at all? > > > > That implies to me that you are using this incorrectly. > > We are taking advantage of 'standard' sysfs capabilities, e.g. we get a > power/ directory and can disable pm_runtime if we chose to do so. > > But the point is that for now we haven't added domain specific properties > with attributes. > > For example, I noodled with this code last week to replace the platform > devices with ancillary devices in the Intel SoundWire code, and I get this > in sysfs: > > root@plb:/sys/bus/ancillary/devices/soundwire_intel.link.0# ls -l > total 0 > lrwxrwxrwx 1 root root 0 Oct 2 15:48 driver -> > ../../../../bus/ancillary/drivers/intel-sdw > lrwxrwxrwx 1 root root 0 Oct 5 10:12 firmware_node -> > ../../../LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:63/PRP00001:00 > drwxr-xr-x 2 root root 0 Oct 5 10:12 power > drwxr-xr-x 5 root root 0 Oct 2 15:48 sdw-master-0 > lrwxrwxrwx 1 root root 0 Oct 2 15:48 subsystem -> > ../../../../bus/ancillary > -rw-r--r-- 1 root root 4096 Oct 2 15:48 uevent > > What would you want us to document here? What you think should be in the documentation to help people out with these devices... Anyway, this thread is long-dead due to it being only on alsa-devel, I'm not going to respond anymore here, thanks. greg k-h
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; + cdev->client_ida = client_ida; + ancildev = &cdev->ancildev; + ancildev->name = name; + ancildev->dev.parent = sdev->dev; + 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); + if (ret < 0) { + dev_err(sdev->dev, "error: failed to add client dev %s\n", name); + put_device(&cdev->ancildev.dev); + 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); + + ancillary_device_unregister(&cdev->ancildev); +} +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) */ + +#ifndef __SOUND_SOC_SOF_CLIENT_H +#define __SOUND_SOC_SOF_CLIENT_H + +#include <linux/ancillary_bus.h> + +#define SOF_CLIENT_PROBE_TIMEOUT_MS 2000 + +struct snd_sof_dev; + +/* SOF client device */ +struct sof_client_dev { + struct ancillary_device ancildev; + struct snd_sof_dev *sdev; + struct list_head list; /* item in SOF core client dev list */ + struct ida *client_ida; + void *data; +}; + +/* client-specific ops, all optional */ +struct sof_client_ops { + int (*client_ipc_rx)(struct sof_client_dev *cdev, u32 msg_cmd); +}; + +struct sof_client_drv { + const char *name; + const struct sof_client_ops ops; + struct ancillary_driver ancillary_drv; +}; + +#define ancillary_dev_to_sof_client_dev(ancillary_dev) \ + container_of(ancillary_dev, struct sof_client_dev, ancildev) + +static inline int sof_client_drv_register(struct sof_client_drv *drv) +{ + return ancillary_driver_register(&drv->ancillary_drv); +} + +static inline void sof_client_drv_unregister(struct sof_client_drv *drv) +{ + ancillary_driver_unregister(&drv->ancillary_drv); +} + +int sof_client_dev_register(struct snd_sof_dev *sdev, const char *name, struct ida *client_ida); +void sof_client_dev_unregister(struct sof_client_dev *cdev); + +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); + +struct dentry *sof_client_get_debugfs_root(struct sof_client_dev *cdev); + +/** + * module_sof_client_driver() - Helper macro for registering an SOF Client + * driver + * @__sof_client_driver: SOF client driver struct + * + * Helper macro for SOF client drivers which do not do anything special in + * module init/exit. This eliminates a lot of boilerplate. Each module may only + * use this macro once, and calling it replaces module_init() and module_exit() + */ +#define module_sof_client_driver(__sof_client_driver) \ + module_driver(__sof_client_driver, sof_client_drv_register, sof_client_drv_unregister) + +#endif diff --git a/sound/soc/sof/sof-priv.h b/sound/soc/sof/sof-priv.h index 64f28e082049..043fcec5a288 100644 --- a/sound/soc/sof/sof-priv.h +++ b/sound/soc/sof/sof-priv.h @@ -438,6 +438,12 @@ struct snd_sof_dev { bool msi_enabled; + /* list of client devices */ + struct list_head client_list; + + /* mutex to protect client list */ + struct mutex client_mutex; + void *private; /* core does not touch this */ };