linux-rdma.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ranjani Sridharan <ranjani.sridharan@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>,
	Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Cc: davem@davemloft.net, gregkh@linuxfoundation.org,
	netdev@vger.kernel.org, linux-rdma@vger.kernel.org,
	nhorman@redhat.com, sassmann@redhat.com,
	pierre-louis.bossart@linux.intel.com,
	Fred Oh <fred.oh@linux.intel.com>
Subject: Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF client
Date: Thu, 21 May 2020 14:11:37 -0700	[thread overview]
Message-ID: <08fa562783e8a47f857d7f96859ab3617c47e81c.camel@linux.intel.com> (raw)
In-Reply-To: <20200520125437.GH31189@ziepe.ca>

On Wed, 2020-05-20 at 09:54 -0300, Jason Gunthorpe wrote:
> On Wed, May 20, 2020 at 12:02:25AM -0700, Jeff Kirsher 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.
> 
> If you want to use sound as the rational for virtual bus then drop
> the
> networking stuff and present a complete device/driver pairing based
> on
> this sound stuff instead.
> 
> > +int sof_client_dev_register(struct snd_sof_dev *sdev,
> > +			    const char *name)
> > +{
> > +	struct sof_client_dev *cdev;
> > +	struct virtbus_device *vdev;
> > +	unsigned long time, timeout;
> > +	int ret;
> > +
> > +	cdev = kzalloc(sizeof(*cdev), GFP_KERNEL);
> > +	if (!cdev)
> > +		return -ENOMEM;
> > +
> > +	cdev->sdev = sdev;
> > +	init_completion(&cdev->probe_complete);
> > +	vdev = &cdev->vdev;
> > +	vdev->match_name = name;
> > +	vdev->dev.parent = sdev->dev;
> > +	vdev->release = sof_client_virtdev_release;
> > +
> > +	/*
> > +	 * Register virtbus device for the client.
> > +	 * The error path in virtbus_register_device() calls
> > put_device(),
> > +	 * which will free cdev in the release callback.
> > +	 */
> > +	ret = virtbus_register_device(vdev);
> > +	if (ret < 0)
> > +		return ret;
> > +
> > +	/* make sure the probe is complete before updating client list
> > */
> > +	timeout = msecs_to_jiffies(SOF_CLIENT_PROBE_TIMEOUT_MS);
> > +	time = wait_for_completion_timeout(&cdev->probe_complete,
> > timeout);
> 
> This seems bonkers - the whole point of something like virtual bus is
> to avoid madness like this.

Thanks for your review, Jason. The idea of the times wait here is to
make the registration of the virtbus devices synchronous so that the
SOF core device has knowledge of all the clients that have been able to
probe successfully. This part is domain-specific and it works very well
in the audio driver case.

Could you please elaborate on why you think this is a bad idea?

Thanks,
Ranjani


  parent reply	other threads:[~2020-05-21 21:11 UTC|newest]

Thread overview: 69+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-20  7:02 [net-next v4 00/12][pull request] 100GbE Intel Wired LAN Driver Updates 2020-05-19 Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 01/12] Implementation of Virtual Bus Jeff Kirsher
2020-05-21 14:57   ` Parav Pandit
2020-05-21 17:43     ` gregkh
2020-05-21 20:10       ` Jason Gunthorpe
2020-05-20  7:02 ` [net-next v4 02/12] ice: Create and register virtual bus for RDMA Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 03/12] ice: Complete RDMA peer registration Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 04/12] ice: Support resource allocation requests Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 05/12] ice: Enable event notifications Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 06/12] ice: Allow reset operations Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 07/12] ice: Pass through communications to VF Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 08/12] i40e: Move client header location Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 09/12] i40e: Register a virtbus device to provide RDMA Jeff Kirsher
2020-05-20  7:02 ` [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF client Jeff Kirsher
2020-05-20  7:20   ` Greg KH
2020-05-20 12:54   ` Jason Gunthorpe
2020-05-20 12:57     ` Jason Gunthorpe
2020-05-21 21:11     ` Ranjani Sridharan [this message]
2020-05-21 23:34       ` Jason Gunthorpe
2020-05-22 14:29         ` Pierre-Louis Bossart
2020-05-22 14:55           ` Jason Gunthorpe
2020-05-22 15:33             ` Pierre-Louis Bossart
2020-05-22 17:10               ` Jason Gunthorpe
2020-05-22 18:35                 ` Pierre-Louis Bossart
2020-05-22 18:40                   ` Jason Gunthorpe
2020-05-22 18:48                     ` Pierre-Louis Bossart
2020-05-22 19:44                       ` Jason Gunthorpe
2020-05-22 21:05                         ` Pierre-Louis Bossart
2020-06-29 20:59               ` Mark Brown
2020-05-23  6:23           ` Greg KH
2020-05-23 19:41             ` Pierre-Louis Bossart
2020-05-24  6:35               ` Greg KH
2020-05-26 13:15                 ` Pierre-Louis Bossart
2020-05-26 13:37                   ` Takashi Iwai
2020-05-27  7:17                     ` Greg KH
2020-05-27 14:05                       ` Pierre-Louis Bossart
2020-06-29 20:33                       ` Mark Brown
2020-06-29 22:59                         ` Jason Gunthorpe
2020-06-29 23:13                           ` Kirsher, Jeffrey T
2020-06-30 10:31                           ` Mark Brown
2020-06-30 11:32                             ` Jason Gunthorpe
2020-06-30 14:16                               ` Mark Brown
2020-06-30 17:24                               ` Ranjani Sridharan
2020-06-30 17:27                                 ` Jason Gunthorpe
2020-07-01  9:50                                   ` Mark Brown
2020-07-01 23:32                                     ` Jason Gunthorpe
2020-07-02 11:15                                       ` Mark Brown
2020-07-02 12:11                                         ` Jason Gunthorpe
2020-07-02 12:20                                           ` Mark Brown
2020-07-01  6:59                                 ` Greg KH
2020-07-02 13:43                                   ` Ranjani Sridharan
2020-07-06 23:02                                     ` Dan Williams
2020-07-07 14:16                                       ` Greg KH
2020-05-25 16:55               ` Jason Gunthorpe
2020-06-29 20:21             ` Mark Brown
2020-06-29 17:36   ` Mark Brown
2020-05-20  7:02 ` [net-next v4 11/12] ASoC: SOF: Create client driver for IPC test Jeff Kirsher
2020-05-20  7:22   ` Greg KH
2020-05-20 12:56   ` Jason Gunthorpe
2020-05-27 20:18     ` Ranjani Sridharan
2020-05-28  0:12       ` Jason Gunthorpe
2020-05-28  1:40         ` Ranjani Sridharan
2020-05-28 10:45           ` Greg KH
2020-06-29 20:37             ` Mark Brown
2020-05-20  7:02 ` [net-next v4 12/12] ASoC: SOF: ops: Add new op for client registration Jeff Kirsher
2020-05-20  7:23   ` Greg KH
2020-05-20  7:17 ` [net-next v4 00/12][pull request] 100GbE Intel Wired LAN Driver Updates 2020-05-19 Greg KH
2020-05-20  7:25   ` Kirsher, Jeffrey T
2020-05-20  9:08     ` Greg KH

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=08fa562783e8a47f857d7f96859ab3617c47e81c.camel@linux.intel.com \
    --to=ranjani.sridharan@linux.intel.com \
    --cc=davem@davemloft.net \
    --cc=fred.oh@linux.intel.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=jeffrey.t.kirsher@intel.com \
    --cc=jgg@ziepe.ca \
    --cc=linux-rdma@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@redhat.com \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=sassmann@redhat.com \
    --subject='Re: [net-next v4 10/12] ASoC: SOF: Introduce descriptors for SOF client' \
    /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

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox