All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Dave Ertman <david.m.ertman@intel.com>
Cc: alsa-devel@alsa-project.org, tiwai@suse.de,
	gregkh@linuxfoundation.org, ranjani.sridharan@intel.com,
	pierre-louis.bossart@linux.intel.com, parav@nvidia.com,
	jgg@nvidia.com
Subject: Re: [PATCH 0/6] Ancillary bus implementation and SOF multi-client support
Date: Thu, 1 Oct 2020 13:50:38 +0100	[thread overview]
Message-ID: <20201001125038.GC6715@sirena.org.uk> (raw)
In-Reply-To: <20200930225051.889607-1-david.m.ertman@intel.com>

[-- Attachment #1: Type: text/plain, Size: 2065 bytes --]

On Wed, Sep 30, 2020 at 03:50:45PM -0700, Dave Ertman wrote:

> In some subsystems, the functionality of the core device
> (PCI/ACPI/other) may be too complex for a single device to be managed as
> a monolithic block or a part of the functionality might need to be
> exposed to a different subsystem.  Splitting the functionality into
> smaller orthogonal devices makes it easier to manage data, power
> management and domain-specific communication with the hardware.  Also,
> common ancillary_device functionality across primary devices can be
> handled by a common ancillary_device. A key requirement for such a split
> is that there is no dependency on a physical bus, device, register
> accesses or regmap support. These individual devices split from the core
> cannot live on the platform bus as they are not physical devices that

I have to say that I find the motivation behind this bus to be a bit
confusing.  In code terms it's essentially a stripped back copy of the
platform bus and we're basically assigning devices between the two based
on if they end up having a physical resource passed through to them.
That seems to result in some duplication, has some potential for devices
to need to churn between the two buses and for duplication in parent
devices if they need to create both platform and auxiliary devices.
What exactly is the problem we're trying to solve here beyond the
labelling one?  I can see that it's a bit messy but this whole area is a
bit messy and I'm not clear that we're not just pushing the mess around.

> are controlled by DT/ACPI. The same argument applies for not using MFD
> in this scenario as it relies on individual function devices being
> physical devices that are DT enumerated.

MFD has no reliance on devices being DT enumerated, it works on systems
that don't have DT and in many cases it's not clear that the split you'd
want for the way Linux describes devices is a sensible one for other
operating systems so we don't want to put it into DT.  Forcing things to
be DT enumerated would just create needless ABIs.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  parent reply	other threads:[~2020-10-01 12:52 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 [this message]
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
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=20201001125038.GC6715@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=david.m.ertman@intel.com \
    --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.