From: "Ertman, David M" <david.m.ertman@intel.com>
To: Greg KH <gregkh@linuxfoundation.org>, Mark Brown <broonie@kernel.org>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
"tiwai@suse.de" <tiwai@suse.de>,
"Sridharan, Ranjani" <ranjani.sridharan@intel.com>,
"pierre-louis.bossart@linux.intel.com"
<pierre-louis.bossart@linux.intel.com>,
"parav@nvidia.com" <parav@nvidia.com>,
"jgg@nvidia.com" <jgg@nvidia.com>
Subject: RE: [PATCH 0/6] Ancillary bus implementation and SOF multi-client support
Date: Thu, 1 Oct 2020 18:29:58 +0000 [thread overview]
Message-ID: <DM6PR11MB2841EB2B3699578E9FE2AB7BDD300@DM6PR11MB2841.namprd11.prod.outlook.com> (raw)
In-Reply-To: <20201001181624.GC3598943@kroah.com>
> -----Original Message-----
> From: Greg KH <gregkh@linuxfoundation.org>
> Sent: Thursday, October 1, 2020 11:16 AM
> To: Mark Brown <broonie@kernel.org>
> Cc: Ertman, David M <david.m.ertman@intel.com>; alsa-devel@alsa-
> project.org; tiwai@suse.de; pierre-louis.bossart@linux.intel.com; Sridharan,
> Ranjani <ranjani.sridharan@intel.com>; jgg@nvidia.com; parav@nvidia.com
> Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client
> support
>
> On Thu, Oct 01, 2020 at 05:03:16PM +0100, Mark Brown wrote:
> > On Thu, Oct 01, 2020 at 05:32:07PM +0200, Greg KH wrote:
> > > On Thu, Oct 01, 2020 at 03:40:19PM +0100, Mark Brown wrote:
> >
> > > > Right, so my concern is that as soon as we decide we want to pass some
> > > > resources or platform data through to one of the subdevices it needs to
> > > > move over into being a platform device and vice versa. That feels like
> > > > something that's going to add to the mess for some of the uses.
> >
> > > There shouldn't be a need for resources or platform data to be passed
> > > that way as they are all "owned" by the parent device that creates
> > > these.
> >
> > > I don't want to see platform devices become children of real devices
> > > (like PCI and USB and others), which is the goal here. platform devices
> > > are overloaded and abused enough as it is, let's not make it worse.
> >
> > How does this interact with the situation where someone makes a PCI
> > device that's basically a bunch of IPs glued together in a PCI memory
> > region (or similarly for other buses)? The IPs all have distinct
> > memory regions and other resources like interrupt lines which makes them
> > unsuitable for auxilliary devices as proposed, especially in cases where
> > there's more than one copy of the IP instantiated. There's a bunch of
> > PCI MFDs in tree already of admittedly varying degrees of taste, and
> > MFDs on other buses also use the resource passing stuff.
>
> I would like to move those PCI MFDs away from that, and into this bus
> instead.
>
> If there needs to have a way to pass/share resources, great, let's add
> it, there's no objection from me.
>
> thanks,
>
> greg k-h
The sharing of information is done by having the parent driver declare
the ancillary_device as an element in a parent_struct that also contains a
pointer to the shared information. This way, when the ancillary_driver
is probed, and a pointer to ancillary_device is passed, it can perform a
container_of on the ancillary_device and gain access to the shared data.
This keeps all requirements out of the ancillary bus code and it can be
as flexible as the implementer wants it to be.
-DaveE
next prev parent reply other threads:[~2020-10-01 18:31 UTC|newest]
Thread overview: 109+ 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
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 [this message]
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
2020-10-01 5:05 Dave Ertman
2020-10-03 9:04 ` Leon Romanovsky
2020-10-03 9:10 ` Greg KH
2020-10-03 9:10 ` Greg KH
2020-10-03 9:24 ` Leon Romanovsky
2020-10-03 9:24 ` Leon Romanovsky
2020-10-03 9:32 ` Greg KH
2020-10-03 9:32 ` Greg KH
2020-10-05 1:20 ` Ertman, David M
2020-10-01 5:08 Dave Ertman
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=DM6PR11MB2841EB2B3699578E9FE2AB7BDD300@DM6PR11MB2841.namprd11.prod.outlook.com \
--to=david.m.ertman@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jgg@nvidia.com \
--cc=parav@nvidia.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=ranjani.sridharan@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.