On 12/13/19 10:12 AM, Greg KH wrote:
On Fri, Dec 13, 2019 at 09:05:37AM -0600, Pierre-Louis Bossart wrote:
On 12/13/19 1:21 AM, Greg KH wrote:
On Thu, Dec 12, 2019 at 11:04:00PM -0600, Pierre-Louis Bossart wrote:
Currently the bus does not have any explicit support for master
devices.
First add explicit support for sdw_slave_type and error checks if this type
is not set.
In follow-up patches we can add support for the sdw_md_type (md==Master
Device), following the Grey Bus example.
How are you using greybus as an example of "master devices"? All you
are doing here is setting the type of the existing devices, right?
I took your advice to look at GreyBus and used the 'gb host device' as the
model to implement the 'sdw master' add/startup/remove interfaces we needed.
so yes in this patch we just add a type for the slave, the interesting part
is in the next patches.
Is that what a "master" device really is? A host controller, like a USB
host controller? Or something else?
I thought things were a bit more complex for this type of topology.
The "Master Device" is similar to a USB host controller, but with a much
lower complexity. It can also be viewed as similar to an
HDaudio/AC97/SLIMbus controller which handles a serial link with
interleaved command/data, but with lower latency to e.g. support 1-bit
oversampled PDM data typically used by digital microphones (or amplifiers).
The Master device provides the clock for the bus, handles clock
stop/restart sequences in and out of idle state, and it issues commands
which contain a sync pattern. The Master device will also typically have
audio 'ports'.
The 'Slave Devices' are similar to USB/SLIMbus devices, they look for a
sync pattern and when synchronized will respond to status/write/read
commands. They cannot send commands on their own but can signal in-band
interrupts. The bus is multi-drop and typically single-level (no
hubs/bridges so far).
Unfortunately there is no host controller interface so we need a
vendor-specific driver for each Master device implementation. The Master
IP is typically part of the audio controller, so in the Intel
implementation it's represented as an ACPI-enumerated child device of
the PCI audio controller.
The patches in this series provide a means for the SOF/HDaudio driver to
check the ACPI DSDT tables and detect if SoundWire links are enabled,
allocate all necessary resources and start the hardware operation once
all the power rail dependencies are handled.
Here are a couple of publicly-available pointers:
https://mipi.org/sites/default/files/Audio_Spec_Brief_20141007.pdf
https://mipi.org/sites/default/files/MIPI-SoundWire-webinar-20150121-final.pdf
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
