From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
tiwai@suse.de, broonie@kernel.org, vkoul@kernel.org,
jank@cadence.com, srinivas.kandagatla@linaro.org,
slawomir.blauciak@intel.com,
Bard liao <yung-chuan.liao@linux.intel.com>,
Rander Wang <rander.wang@linux.intel.com>,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
Sanyog Kale <sanyog.r.kale@intel.com>
Subject: Re: [alsa-devel] [PATCH v4 06/15] soundwire: add support for sdw_slave_type
Date: Fri, 13 Dec 2019 16:14:10 -0600 [thread overview]
Message-ID: <c7d25b39-b8bf-46f1-96c2-8e52aa858dff@linux.intel.com> (raw)
In-Reply-To: <20191213161218.GC2653074@kroah.com>
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
WARNING: multiple messages have this Message-ID (diff)
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: alsa-devel@alsa-project.org, tiwai@suse.de,
linux-kernel@vger.kernel.org,
Ranjani Sridharan <ranjani.sridharan@linux.intel.com>,
vkoul@kernel.org, broonie@kernel.org,
srinivas.kandagatla@linaro.org, jank@cadence.com,
slawomir.blauciak@intel.com,
Sanyog Kale <sanyog.r.kale@intel.com>,
Bard liao <yung-chuan.liao@linux.intel.com>,
Rander Wang <rander.wang@linux.intel.com>
Subject: Re: [alsa-devel] [PATCH v4 06/15] soundwire: add support for sdw_slave_type
Date: Fri, 13 Dec 2019 16:14:10 -0600 [thread overview]
Message-ID: <c7d25b39-b8bf-46f1-96c2-8e52aa858dff@linux.intel.com> (raw)
In-Reply-To: <20191213161218.GC2653074@kroah.com>
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@alsa-project.org
https://mailman.alsa-project.org/mailman/listinfo/alsa-devel
next prev parent reply other threads:[~2019-12-13 22:16 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-13 5:03 [PATCH v4 00/15] soundwire: intel: implement new ASoC interfaces Pierre-Louis Bossart
2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:03 ` [PATCH v4 01/15] soundwire: renames to prepare support for master drivers/devices Pierre-Louis Bossart
2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:03 ` [PATCH v4 02/15] soundwire: rename dev_to_sdw_dev macro Pierre-Louis Bossart
2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:03 ` [PATCH v4 03/15] soundwire: rename drv_to_sdw_slave_driver macro Pierre-Louis Bossart
2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:03 ` [PATCH v4 04/15] soundwire: bus_type: rename sdw_drv_ to sdw_slave_drv Pierre-Louis Bossart
2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:03 ` [PATCH v4 05/15] soundwire: intel: rename res field as link_res Pierre-Louis Bossart
2019-12-13 5:03 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 06/15] soundwire: add support for sdw_slave_type Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 7:21 ` Greg KH
2019-12-13 7:21 ` [alsa-devel] " Greg KH
2019-12-13 15:05 ` Pierre-Louis Bossart
2019-12-13 15:05 ` Pierre-Louis Bossart
2019-12-13 16:12 ` Greg KH
2019-12-13 16:12 ` Greg KH
2019-12-13 22:14 ` Pierre-Louis Bossart [this message]
2019-12-13 22:14 ` Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 07/15] soundwire: slave: move uevent handling to slave Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 7:22 ` Greg KH
2019-12-13 7:22 ` [alsa-devel] " Greg KH
2019-12-13 15:11 ` Pierre-Louis Bossart
2019-12-13 15:11 ` Pierre-Louis Bossart
2019-12-13 16:11 ` Greg KH
2019-12-13 16:11 ` Greg KH
2019-12-13 22:15 ` Pierre-Louis Bossart
2019-12-13 22:15 ` Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 08/15] soundwire: add initial definitions for sdw_master_device Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 7:28 ` Greg KH
2019-12-13 7:28 ` [alsa-devel] " Greg KH
2019-12-13 15:49 ` Pierre-Louis Bossart
2019-12-13 15:49 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 16:10 ` Greg KH
2019-12-13 16:10 ` [alsa-devel] " Greg KH
2019-12-13 22:15 ` Pierre-Louis Bossart
2019-12-13 22:15 ` Pierre-Louis Bossart
2019-12-16 22:34 ` Pierre-Louis Bossart
2019-12-16 22:34 ` Pierre-Louis Bossart
2019-12-13 23:25 ` Pierre-Louis Bossart
2019-12-13 23:25 ` Pierre-Louis Bossart
2019-12-14 8:27 ` Greg KH
2019-12-14 8:27 ` Greg KH
2019-12-16 15:02 ` Pierre-Louis Bossart
2019-12-16 15:02 ` Pierre-Louis Bossart
2019-12-16 16:25 ` Greg KH
2019-12-16 16:25 ` Greg KH
2019-12-16 17:07 ` Pierre-Louis Bossart
2019-12-16 17:07 ` Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 09/15] soundwire: intel: remove platform devices and provide new interface Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 10/15] soundwire: register master device driver Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 11/15] soundwire: intel: add prepare support in sdw dai driver Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 12/15] soundwire: intel: add trigger " Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 13/15] soundwire: intel: add sdw_stream_setup helper for .startup callback Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 14/15] soundwire: intel: free all resources on hw_free() Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
2019-12-13 5:04 ` [PATCH v4 15/15] soundwire: intel_init: add implementation of sdw_intel_enable_irq() Pierre-Louis Bossart
2019-12-13 5:04 ` [alsa-devel] " Pierre-Louis Bossart
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=c7d25b39-b8bf-46f1-96c2-8e52aa858dff@linux.intel.com \
--to=pierre-louis.bossart@linux.intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=jank@cadence.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rander.wang@linux.intel.com \
--cc=ranjani.sridharan@linux.intel.com \
--cc=sanyog.r.kale@intel.com \
--cc=slawomir.blauciak@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.de \
--cc=vkoul@kernel.org \
--cc=yung-chuan.liao@linux.intel.com \
/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.