>>>>>> 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. >> > > The problem is that there are two managers in the specified AMD design, and > the codecs are both on "Link 0" for each manager. You're confusing Controller and Manager. A Manager is the same as a 'Link', the two terms are interchangeable. It makes no sense to refer to a link number for a manager because there is no such concept. Only a Controller can have multiple links or managers. And each Controller needs to be declared as an ACPI device if you want to use the DisCo properties. The Managers/Links are not described as ACPI devices, that's a regrettable design decision made in MIPI circles many moons ago, that's why in the Intel code we have to manually create auxiliary devices based on the 'mipi-sdw-master-count' property. > So the _ADR really is identical for both. That cannot possible work, even for Windows. You need to have a controller scope, and the _ADR can then be identical for different peripherals as long as this ADR is local to a controller scope.
