From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: Vinod Koul <vkoul@kernel.org>
Cc: alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org,
tiwai@suse.de, broonie@kernel.org, gregkh@linuxfoundation.org,
liam.r.girdwood@linux.intel.com, jank@cadence.com,
joe@perches.com, srinivas.kandagatla@linaro.org,
Sanyog Kale <sanyog.r.kale@intel.com>
Subject: Re: [PATCH 1/8] soundwire: intel: filter SoundWire controller device search
Date: Tue, 7 May 2019 09:43:15 -0500 [thread overview]
Message-ID: <47fd3ca6-6910-f101-9b63-f653cd1443f9@linux.intel.com> (raw)
In-Reply-To: <20190507122651.GO16052@vkoul-mobl>
On 5/7/19 7:26 AM, Vinod Koul wrote:
> On 03-05-19, 19:29, Pierre-Louis Bossart wrote:
>> The convention is that the SoundWire controller device is a child of
>> the HDAudio controller. However there can be more than one child
>> exposed in the DSDT table, and the current namespace walk returns the
>> last device.
>>
>> Add a filter and terminate early when a valid _ADR is provided,
>> otherwise keep iterating to find the next child.
>
> So what are the other devices in DSDT here..
this is what I see:
Scope (HDAS)
{
Device (IDA)
{
Name (_ADR, 0x00020001) // _ADR: Address
}
}
I thought this was nonsense but your question triggered me to look into
the Intel SST ACPI specs (not public I am afraid but shared with the OS
who shall not be named).
Using the same source of information as below, I *believe* this is
HDaudio related, bits 31..16 mean HDaudio with codec SDI 2, and NodeId 1
for the function group. This would make sense as I believe there are two
codecs on the board that can be pin-strapped to boot either in HDaudio
or SoundWire mode- but this is a conjecture only.
At any rate, we need a hardware rework and mutual exclusion between
HDaudio and SoundWire, so we have to ignore this one when SoundWire is
enabled.
>> +
>> + /*
>> + * On some Intel platforms, multiple children of the HDAS
>> + * device can be found, but only one of them is the SoundWire
>> + * controller. The SNDW device is always exposed with
>> + * Name(_ADR, 0x40000000) so filter accordingly
>> + */
>> + if (adr != 0x40000000)
>
> I do not recall if 4 corresponds to the links you have or soundwire
> device type, is this number documented somewhere is HDA specs?
I thought it was a magic number, but I did check and for once it's
documented and the values match the spec :-)
I see in the ACPI docs bits 31..28 set to 4 indicate a SoundWire Link
Type and bits 3..0 indicate the SoundWire controller instance, the rest
is reserved to zero.
>
> Also it might good to create a define for this
I will respin this one to add the documentation above, and only filter
on the 4 ms-bits. Thanks for forcing me to RTFM :-)
next prev parent reply other threads:[~2019-05-07 14:43 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-04 0:29 [PATCH 0/8] soundwire: corrections to ACPI and DisCo properties Pierre-Louis Bossart
2019-05-04 0:29 ` [PATCH 1/8] soundwire: intel: filter SoundWire controller device search Pierre-Louis Bossart
2019-05-07 12:26 ` Vinod Koul
2019-05-07 14:43 ` Pierre-Louis Bossart [this message]
2019-05-08 5:08 ` Vinod Koul
2019-05-08 16:20 ` Pierre-Louis Bossart
2019-05-08 16:37 ` Vinod Koul
2019-05-04 0:29 ` [PATCH 2/8] soundwire: mipi_disco: fix master/link error Pierre-Louis Bossart
2019-05-07 1:58 ` Pierre-Louis Bossart
2019-05-04 0:29 ` [PATCH 3/8] soundwire: mipi_disco: expose sdw_slave_read_dpn as symbol Pierre-Louis Bossart
2019-05-07 12:30 ` Vinod Koul
2019-05-04 0:29 ` [PATCH 4/8] soundwire: mipi_disco: expose sdw_slave_read_dp0 " Pierre-Louis Bossart
2019-05-04 0:29 ` [PATCH 5/8] soundwire: add port-related definitions Pierre-Louis Bossart
2019-05-04 0:29 ` [PATCH 6/8] soundwire: remove master data port properties Pierre-Louis Bossart
2019-05-04 0:29 ` [PATCH 7/8] soundwire: fix master properties Pierre-Louis Bossart
2019-05-07 14:44 ` Vinod Koul
2019-05-04 0:29 ` [PATCH 8/8] soundwire: rename/clarify MIPI DisCo properties 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=47fd3ca6-6910-f101-9b63-f653cd1443f9@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=joe@perches.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=sanyog.r.kale@intel.com \
--cc=srinivas.kandagatla@linaro.org \
--cc=tiwai@suse.de \
--cc=vkoul@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®