[PATCH 0/6] Ancillary bus implementation and SOF multi-client support

Dan Williams dan.j.williams at intel.com
Wed Oct 7 18:41:52 CEST 2020


On Wed, Oct 7, 2020 at 9:23 AM Mark Brown <broonie at kernel.org> wrote:
>
> On Wed, Oct 07, 2020 at 09:19:32AM -0700, Dan Williams wrote:
> > On Wed, Oct 7, 2020 at 2:14 AM gregkh at linuxfoundation.org
>
> > > "virtual" here means "not real" :)
>
> > Which of these aux device use cases is not a real device? One of my
> > planned usages for this facility is for the NPEM (Native PCIE
> > Enclosure Management) mechanism that can appear on any PCIE
> > bridge/endpoint. While it is true that the NPEM register set does not
> > get its own PCI-b:d:f address on the host bus, it is still
> > discoverable by a standard enumeration scheme. It is real auxiliary
> > device functionality that can appear on any PCIE device where the
> > kernel can now have one common NPEM driver for all instances in the
> > topology.
>
> Some if not all of the SOF cases are entirely software defined by the
> firmware downloaded to the audio DSPs.

"Software-defined" in the kernel context to me means software Linux
kernel developers have control over, so device-mapper devices, other
things that show up under /sys/devices/virtual, or
/sys/devices/system/memory/. Firmware changing device functionality is
more like just-in-time hardware than software-defined. In other words
kernel software is not involved in constructing the device
functionality.


More information about the Alsa-devel mailing list