On Tue, Apr 5, 2016 at 12:52 AM, Mark Rutland <mark.rutland@xxxxxxx> wrote: > On Thu, Mar 31, 2016 at 02:44:41PM +0300, Irina Tirdea wrote: >> This proposal is based on using _DSD properties to specify device >> states and configuration nodes and it follows closely the device >> tree model. Device states are defined using the Device Properties >> format and the configuration nodes are defined using the >> Hierarchical Properties Extension format. The generic properties >> for the configuration nodes are the same as the ones for device >> tree, while pincontroller drivers can also define custom ones. > > From a look of the Documentation addition, and of the current uses of > pinctrl-names in device tree bindings, one reason for requiring multiple > pinctrl states is power management. Given that, I'm somewhat concerned by this, > as it goes against the usual ACPI model of abstracting this sort of thing > behind power control methods. There are other use cases but in essence there are two common use cases: - Initial set-up of muxing and electrical properties - Runtime reconfiguration for power saving (especially biasing and pull options) I did see that the ACPI people's ambition has been for all things power save to be embedded into AML and the like. However AFAICT the development model for deployment of ACPI seems to imply that products are shipped with ACPI tables resident in ROM-like storage, and at product release several devices are disabled from muxing while others at the same time are totally lacking power save enablement. And these products are only update-able with hairy BIOS patches that need to be applied using $SPECIAL_TOOL that "normal users" do not want to concern themselves with, as this is not an "apt-get upgrade" kind of thing. And as this is server silicon the systems have a bunch of these "normal users" that are not embedded development experts and they are very hesitant about doing such things. Under that scenario it is of course tempting to simply set up the pins in a known good state and then remove the responsibility of pin controlling from ACPI firmware altogether and into the kernel, where "apt-get upgrade" will take care of post-product launch upgrading of the functionality. And I think that is what is happening, it's just that so much prestige is involved that no-one wants to officially admit it. I was once poking fun at this development model accusing firmware engineers of having a God complex when they claim to be able to engineer in these complex use cases during product firmware development. Now I just feel sad about this situation and want things to "just work" for them. I think these patches are good. Yours, Linus Walleij -- 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
