[RFC] Use virtual bus implementation in SOF #1841

ranj063 · 2020-02-28T19:18:36Z

This PR just shows the use virtual bus devices in SOF. The virtbus dev is encapsulated within a sof_client_dev to enable extending the ops supported by the virtbus_dev to include SOF client specific ops and data. This PR is now updated with the complete implementation for the dummy IPC client.

Please note that the first patch is still under review here:
http://patchwork.ozlabs.org/patch/1247882/

plbossart

Looks like a good start to me. Thanks @ranj063

sound/soc/sof/core.c

sound/soc/sof/Makefile

sound/soc/sof/sof-ipc-test.c

sound/soc/sof/core.c

lgirdwood

I do need to read the virtio bus patches, but some questions that may impact the client PM.

sound/soc/sof/core.c

kv2019i

Looks ok so far. Biggest thing seems to be how we manage the sof_virtbus_dev objects as part of sdev and how we link back.

ranj063 · 2020-03-05T21:48:03Z

@plbossart @lgirdwood @lyakh @kv2019i this PR is now updated to include the second step ir registering a client drv and probing client devices after FW boot is done. The client device probe still does nothing atm but once we agree upon the registration model, I will add that to this PR.

sound/soc/sof/sof-client.c

lyakh · 2020-03-06T09:31:27Z

sound/soc/sof/sof-client.c

+
+	mutex_lock(&sof_client_mutex);
+	list_for_each_entry_safe(cdev, _cdev, &client_list, list) {
+		if (cdev->drv == drv) {


Your client_list is global, and as far as I understand we can in theory at some point get multiple DSPs. Would they then possibly use the same driver? Then this matching would break?

@lyakh I'm not sure about this case. But my guess would be that if there are multiple DSP, they possibly should not share the same driver. @lgirdwood could you please chime in?

the same driver can be used for multiple devices, but each would need to have its own context and not a shared variable.

@plbossart How would that work though? If you look at sof_client_drv_register() today, we create a client device for each client drv that is registered. If multiple devices share the same driver, then we probably need some kind of id table just like the virtbus driver, right?

We can create a new global context (which can hold lists etc) per detected DSP device, i.e. on PCI/ACPI probe.

sound/soc/sof/sof-ipc-test.c

sound/soc/sof/core.c

plbossart · 2020-03-09T20:27:18Z

@ranj063 I must be missing something here.

If I look at the IPC, there is first layer that probes/removed the virtbus driver. And then the probe registers an SOF client, which results in a second level probe.

Is this really necessary? seems to me you are bolting a bus on top of a bus?

ranj063 · 2020-03-10T15:59:11Z

@ranj063 I must be missing something here.

If I look at the IPC, there is first layer that probes/removed the virtbus driver. And then the probe registers an SOF client, which results in a second level probe.

Is this really necessary? seems to me you are bolting a bus on top of a bus?

@plbossart the virtbus devices are actually only virtual devices. They need to be probed first before they can register with SOF for IPC. And we can probe the client devices only after the SOF core device has finished booting the DSP. So I cant imagine how we can avoid the 2-level probe that we have here.
Besides, for a non-virtbus device, we will be calling just the client_drv_register() when it is probed and then handle all client device initialization in the client_dev_probe().

plbossart · 2020-03-10T20:51:45Z

@ranj063 I must be missing something here.
If I look at the IPC, there is first layer that probes/removed the virtbus driver. And then the probe registers an SOF client, which results in a second level probe.
Is this really necessary? seems to me you are bolting a bus on top of a bus?

@plbossart the virtbus devices are actually only virtual devices. They need to be probed first before they can register with SOF for IPC. And we can probe the client devices only after the SOF core device has finished booting the DSP. So I cant imagine how we can avoid the 2-level probe that we have here.
Besides, for a non-virtbus device, we will be calling just the client_drv_register() when it is probed and then handle all client device initialization in the client_dev_probe().

It was my understanding that all clients would be represented with a device that's a child of the PCI/ACPI/DT parent, which would by construction guarantee that the parent remains active as long as any of its children is active.
Your last sentence 'for a non-virtbus device' suggests otherwise?

ranj063 · 2020-03-23T21:49:00Z

@lgirdwood @plbossart I've updated this PR based on our discussions last week. The last 3 patches are the ones relevant for SOF. Please let me know what you think

plbossart

Thanks @ranj063 I must be missing a bit of context on the need for a list and the pointer v. structure nesting.

sound/soc/sof/sof-client.c

sound/soc/sof/sof-client.h

Documentation/driver-api/virtual_bus.rst

kv2019i

Looks good @ranj063 . Really the only thing in the documentation was use of MFD versus PCI multifunction. Otherwise seems good.

Documentation/driver-api/virtual_bus.rst

plbossart

Sorry for chiming in late, the PCI part is just completely wrong.

Documentation/driver-api/virtual_bus.rst

shirazsaleem · 2020-06-03T17:41:55Z

Documentation/driver-api/virtual_bus.rst

+
+Virtual bus devices are created and registered by a multi-function PCI device.
+Therefore, they are typically encapsulated within a structure defined by
+parent PCI device which contains the virtual bus device and any associated


defined by the device or driver?

shirazsaleem · 2020-06-03T17:42:17Z

Documentation/driver-api/virtual_bus.rst

+                void *data;
+        };
+
+The parent PCI device would then register the virtual bus device by calling


The 'core' driver does the registration...

Documentation/driver-api/virtual_bus.rst

kv2019i

A few minor notes on doc, but looks good. At least this now explicitly discussed the platform bus and MFD and why virtbus is added.

Documentation/driver-api/virtual_bus.rst

plbossart

Nice improvement on the documentation @ranj063
a couple of comments below to make it even nicer

Documentation/driver-api/index.rst

Documentation/driver-api/virtual_bus.rst

This is the initial implementation of the Virtual Bus, virtbus_device and virtbus_driver. The virtual bus is a software based bus intended to support splitting the functionality of a subsystem's core device into orthogonal parts. This bus is also meant to be generic and be available to be used by any type of parent device (PCI/ACPI/DT). Signed-off-by: Dave Ertman <david.m.ertman@intel.com> Signed-off-by: Kiran Patil <kiran.patil@intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com> Tested-by: Andrew Bowers <andrewx.bowers@intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com> Signed-off-by: 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. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Fred Oh <fred.oh@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

Create an SOF client driver for IPC flood test. This driver is used to set up the debugfs entries and the read/write ops for initiating the IPC flood test that would be used to measure the min/max/avg response times for sending IPCs to the DSP. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Fred Oh <fred.oh@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

Add a new op for registering clients. The clients to be registered depend on the DSP capabilities and the ACPI/DT information. For now, we only add 2 IPC test clients that will be used for run tandem IPC flood tests for all Intel platforms. For ACPI platforms, change the Kconfig to select SND_SOC_SOF_PROBE_WORK_QUEUE to allow the virtbus driver to probe when the client is registered. Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com> Signed-off-by: Fred Oh <fred.oh@linux.intel.com> Reviewed-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>

Remove the IPC flood test support in the SOF core as it is now added in the IPC flood test client. Signed-off-by: Fred Oh <fred.oh@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

lyakh

if you decide to fix the presumable '?' typo, this would be a perfect case for a "fixup" patch.

lyakh · 2020-06-05T07:16:40Z

Documentation/driver-api/virtual_bus.rst

+
+Virtbus drivers register themselves with the bus by calling
+virtbus_register_driver(). The id_table contains the names of virtbus devices
+that a driver can bind with?


why a question mark? A typo?

I think it was my suggestion with a question mark that was copied verbatim...

yes, sorry about that. The documentation is so verbose now that I missed it :(

kv2019i · 2020-10-22T09:01:28Z

@ranj063 Can we close this, seems obsolete now...?

ranj063 requested review from dbaluta, juimonen, keyonjie, kv2019i, lgirdwood, libinyang, lyakh and plbossart as code owners February 28, 2020 19:18

plbossart reviewed Feb 28, 2020

View reviewed changes

sound/soc/sof/core.c Outdated Show resolved Hide resolved

sound/soc/sof/Makefile Outdated Show resolved Hide resolved

sound/soc/sof/sof-ipc-test.c Outdated Show resolved Hide resolved

sound/soc/sof/sof-ipc-test.c Outdated Show resolved Hide resolved

lyakh requested changes Mar 2, 2020

View reviewed changes

sound/soc/sof/core.c Outdated Show resolved Hide resolved

sound/soc/sof/core.c Outdated Show resolved Hide resolved

sound/soc/sof/core.c Outdated Show resolved Hide resolved

lgirdwood reviewed Mar 2, 2020

View reviewed changes

sound/soc/sof/core.c Outdated Show resolved Hide resolved

kv2019i reviewed Mar 2, 2020

View reviewed changes

ranj063 force-pushed the virtual-bus-sof branch from 80aeb71 to b071bc4 Compare March 5, 2020 21:46

lyakh requested changes Mar 6, 2020

View reviewed changes

ranj063 force-pushed the virtual-bus-sof branch 6 times, most recently from 145d738 to c0251fe Compare March 6, 2020 18:33

ranj063 force-pushed the virtual-bus-sof branch from c0251fe to b7cfa48 Compare March 23, 2020 21:44

ranj063 force-pushed the virtual-bus-sof branch from b7cfa48 to 0e1b090 Compare March 23, 2020 22:13

plbossart reviewed Mar 23, 2020

View reviewed changes

sound/soc/sof/sof-client.c Outdated Show resolved Hide resolved

sound/soc/sof/sof-client.c Show resolved Hide resolved

sound/soc/sof/sof-client.h Outdated Show resolved Hide resolved

sound/soc/sof/sof-client.h Outdated Show resolved Hide resolved

ranj063 force-pushed the virtual-bus-sof branch 2 times, most recently from 48cd91f to d120705 Compare March 23, 2020 23:13

ranj063 force-pushed the virtual-bus-sof branch 3 times, most recently from b71cc9c to 2df63f4 Compare June 3, 2020 05:09

bardliao reviewed Jun 3, 2020

View reviewed changes

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

kv2019i reviewed Jun 3, 2020

View reviewed changes

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

plbossart requested changes Jun 3, 2020

View reviewed changes

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

shirazsaleem reviewed Jun 3, 2020

View reviewed changes

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

shirazsaleem reviewed Jun 3, 2020

View reviewed changes

ranj063 force-pushed the virtual-bus-sof branch from 2df63f4 to 7b171c5 Compare June 3, 2020 21:48

shirazsaleem reviewed Jun 3, 2020

View reviewed changes

ranj063 force-pushed the virtual-bus-sof branch from 7b171c5 to 2f729a7 Compare June 3, 2020 23:11

ranj063 requested review from bardliao, kv2019i and plbossart June 3, 2020 23:11

kv2019i reviewed Jun 4, 2020

View reviewed changes

Documentation/driver-api/virtual_bus.rst Show resolved Hide resolved

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

Documentation/driver-api/virtual_bus.rst Outdated Show resolved Hide resolved

ranj063 force-pushed the virtual-bus-sof branch from 2f729a7 to 7793968 Compare June 4, 2020 18:54

plbossart requested changes Jun 4, 2020

View reviewed changes

ranj063 force-pushed the virtual-bus-sof branch from 7793968 to cd3ca65 Compare June 4, 2020 19:30

dmertman and others added 5 commits June 4, 2020 13:03

ASoC: SOF: debug: Remove IPC flood test support in SOF core

61a5a04

Remove the IPC flood test support in the SOF core as it is now added in the IPC flood test client. Signed-off-by: Fred Oh <fred.oh@linux.intel.com> Signed-off-by: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>

ranj063 force-pushed the virtual-bus-sof branch from cd3ca65 to 61a5a04 Compare June 4, 2020 20:04

lyakh approved these changes Jun 5, 2020

View reviewed changes

fredoh9 mentioned this pull request Jul 9, 2020

[RFC] Use Ancillary bus implementation in SOF #2265

Closed

ranj063 closed this Oct 23, 2020

ranj063 deleted the virtual-bus-sof branch February 13, 2022 05:07

marc-hb mentioned this pull request Aug 13, 2024

Auxiliary devices in SOF break check-ipc-flood.sh (IPC3) thesofproject/sof-test#467

Closed

[RFC] Use virtual bus implementation in SOF #1841

[RFC] Use virtual bus implementation in SOF #1841

Uh oh!

Conversation

ranj063 commented Feb 28, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

lgirdwood left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

ranj063 commented Mar 5, 2020

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

plbossart commented Mar 9, 2020

Uh oh!

ranj063 commented Mar 10, 2020

Uh oh!

plbossart commented Mar 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ranj063 commented Mar 23, 2020

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

kv2019i left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

plbossart left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

ranj063 commented Feb 28, 2020 •

edited

Loading

plbossart commented Mar 10, 2020 •

edited

Loading