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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




"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.

Correct for DSP processing/debug stuff. In some cases though, the firmware deals with different IOs (HDMI, I2C) and having multiple 'aux' devices helps expose unrelated physical functions in a more modular way.

The non-SOF audio case I can think of is SoundWire. We want to expose SoundWire links as separate devices even though they are not exposed in the platform firmware or PCI configs (decision driven by Windows). We currently use platform devices for this, but we'd like to transition to this 'aux' bus



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Pulse Audio]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux