On Thu, Oct 6, 2016 at 12:40 PM, Mark Brown <broonie@xxxxxxxxxx> 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. My view on that is a bit different. Even if there's more than one style in use, they all can be supported at the same time. Avoiding confusion is only a matter of prioritizing them, then. It should be clear which style is the default one, which is going to be taken into consideration next and so on. If that is made clear, I don't see a big problem here, at least in principle. > 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. The pinctrl thing is being dealt with (and not in a way of adding pinctrl _DSD properties support to the kernel FWIW). Other things potentially conflicting with ACPI-defined HW control should be dealt with analogously. The point here is that some things just don't conflict with ACPI-defined HW control even potentially and they can be handled with the help of _DSD properties just fine. Thus, there are no technical obstacles to do that, at least not in principle. Thanks, Rafael -- 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
