On Thu, Oct 06, 2016 at 12:40:58PM +0200, Mark Brown wrote: > On Thu, Oct 06, 2016 at 12:11:33PM +0300, Mika Westerberg wrote: > > > One reason is that we have boards like Joule where developers are > > allowed to connect different peripherals using buses such as I2C and SPI > > where there is no native enumeration mechanism. This includes camera > > sensors and related so there needs to be a way for a developer to > > describe this in ACPI. Just as can be done when using ARM and DT. > > One of my biggest concerns with this approach is that I'm really not > clear to me that that this has broad buy in from the x86/ACPI community > and therefore that we might end up needing to support several different > styles of ACPI bindings. Reuse would be great but it can be confusing > if there's multiple different styles of bindings in use at the same > time. Yes, that's possible unfortunately. And we can't force people to use whatever _DSD properties we came up. Instead they use whatever is convenient for them, even if it is already available in the _DSD properties database. > The audio systems that have this issue (which include production laptops > and tablets with both Windows and ChromeOS) don't seem to be showing > much interest in reusing any of the DT work beyond the device level > properties and I didn't think the OS level support for using _DSD in > Windows was great. There were also the pinctrl bindings which had some > issues too. Right and it does not always follow DT work even on device level. Here is an example what Windows is supporting. They use _DSD device properties but it is completely different to what Linux and DT use: https://msdn.microsoft.com/en-us/windows/uwp/devices-sensors/enable-usermode-access We have had all that stuff in DT already but they chose not to use it. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
