On 1/31/23 07:09, Mukunda,Vijendar wrote:
> On 16/01/23 13:32, Mukunda,Vijendar wrote:
>> On 13/01/23 22:41, Pierre-Louis Bossart wrote:
>>>>>> + if (is_dmic_dev && is_sdw_dev) {
>>>>>> + switch (acp_data->sdw_master_count) {
>>>>>> + case 1:
>>>>>> + acp_data->pdev_mask = ACP63_SDW_PDM_DEV_MASK;
>>>>>> + acp_data->pdev_count = ACP63_SDW0_PDM_MODE_DEVS;
>>>>>> + break;
>>>>>> + case 2:
>>>>>> + acp_data->pdev_mask = ACP63_SDW_PDM_DEV_MASK;
>>>>>> + acp_data->pdev_count = ACP63_SDW0_SDW1_PDM_MODE_DEVS;
>>>>>> + break;
>>>>> so the cover letter is indeed wrong and confuses two controllers for two
>>>>> managers.
>>>> ACP IP has two independent manager instances driven by separate controller
>>>> each which are connected in different power domains.
>>>>
>>>> we should create two separate ACPI companion devices for separate
>>>> manager instance. Currently we have limitations with BIOS.
>>>> we are going with single ACPI companion device.
>>>> We will update the changes later.
>>> Humm, this is tricky. The BIOS interface isn't something that can be
>>> changed at will on the kernel side, you'd have to maintain two solutions
>>> with a means to detect which one to use.
>>>
>>> Or is this is a temporary issue on development devices, then that part
>>> should probably not be upstreamed.
>> It's a temporary issue on development devices.
>> We had discussion with Windows dev team and BIOS team.
>> They have agreed to modify ACPI companion device logic.
>> We will update the two companion devices logic for two manager
>> instances in V2 version.
> After experimenting, two ACPI companion devices approach,
> we got an update from Windows team, there is a limitation
> on windows stack. For current platform, we can't proceed
> with two ACPI companion devices.
so how would the two controllers be declared then in the DSDT used by
Windows? There's a contradiction between having a single companion
device and the ability to set the 'manager-number' to one.
You probably want to give an example of what you have, otherwise we
probably will talk past each other.
>
> Even on Linux side, if we create two ACPI companion devices
> followed by creating a single soundwire manager instance per
> Soundwire controller, we have observed an issue in a scenario,
> where similar codec parts(UID are also same) are connected on
> both soundwire manager instances.
We've been handling this case of two identical amplifiers on two
different links for the last 3 years. I don't see how this could be a
problem, the codecs are declared in the scope of the companion device
and the _ADR defines in bits [51..48] which link the codec is connected to.
see example below from a TigerLake device with two identical amsp on
link 1 and 2.
Scope (_SB.PC00.HDAS.SNDW)
{
Device (SWD1)
{
Name (_ADR, 0x000131025D131601) // _ADR: Address
Device (SWD2)
{
Name (_ADR, 0x000230025D131601) // _ADR: Address
> As per MIPI Disco spec, for single link controllers Link ID should
> be set to zero.
> If we use Link ID as zero, for the soundwire manager which is on
> the second soundwire controller ACPI device scope, then soundwire
> framework is not allowing to create peripheral device node as its
> duplicate one.
I still don't see how it's possible. There is an IDA used in the bus
allocation
static int sdw_get_id(struct sdw_bus *bus)
{
int rc = ida_alloc(&sdw_bus_ida, GFP_KERNEL);
if (rc < 0)
return rc;
bus->id = rc;
return 0;
}
and that's used for debugfs
/* create the debugfs master-N */
snprintf(name, sizeof(name), "master-%d-%d", bus->id, bus->link_id);
as well as in sdw_master_device_add():
dev_set_name(&md->dev, "sdw-master-%d", bus->id);
can you clarify what part of the 'SoundWire framework' is problematic? I
guess the problem is that you have identical devices with the same _ADR
under the same manager, which is problematic indeed, but that's not a
SoundWire framework issue, just not a supported configuration.
> If we want to support two ACPI companion device approach
> on our future platforms, how to proceed?
Well how about dealing with a single companion device first, cause
that's what you have now and that's already problematic.
