On Tue, 2017-12-12 at 14:27 -0600, Timur Tabi wrote: > On 12/12/2017 05:07 AM, Andy Shevchenko wrote: > > > Not ACPI standards as of my knowledge. ACPI standard defines a > > common > > scheme how to define properties, it doesn't tell anything about > > property > > names or any mappings between names to values or names to "OS > > subsystem"). > > There was an attempt a while back to standardize this like we do for > device tree, but it fell apart. Device-specific ACPI-only properties > are not standarized. This driver is initialized only on ACPI > systems. > It has no device tree binding. It should follow DT *de facto* standard bindings like "ngpios" (though it's not needed in ACPI case IIRC) and other properties. > > As for GPIO we just follow *de facto* what DT has right now, i.e. > > "xxx- > > gpio" or "xxx-gpios" pattern is used to map ACPI standard resource > > to a > > GPIO name. That's how GPIO ACPI lib is being developed. > > GPIOs in device tree are defined completely differently than in ACPI. > On DT, the kernel controls the pin muxing. On ACPI, pins are muxed > by > firmware and never re-muxed by the operating system. So all this > driver > does is expose a few pins as simple GPIOs. Wait, runtime muxing is a matter of requesting another function (usually GPIO) and putting it back afterwards. Do you really need anything like this at *runtime*? Pin control design is not compatible with hardware (too abstract), but that is the problem of DT as well: I'm referring here to not carefully designed so called "pin states". This is another story and has nothing specific for ACPI. -- Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Intel Finland Oy -- To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
