On Tue, Oct 30, 2012 at 12:49 PM, Felipe Balbi <balbi@xxxxxx> wrote: > On Tue, Oct 30, 2012 at 11:24:10AM +0000, Mark Brown wrote: >> We need some place to put the SoC integration; power domains seem like >> the obvious place to me but YMMV. Nothing about having this out of the > > except that pin muxing has nothing to do with power domain. To me that > sounds like an abuse of the API. It could be renamed to "power resources" or something as long as it's related to resource handling related to the PM calls. But I worry that it violates the Unix principle to do one thing and one thing only. A device power resource framework goes in the opposite direction, trying to do a lot of unrelated things in a central place as opposed to distributing the task. >> drivers requires that this be done by individual subsystems in isolation >> from each other. Half the point here is that for the reusable IPs this >> stuff often isn't driver specific at all, it's often more about the SoC >> integration than it is about the driver and so you'll get a consistent >> pattern for most IPs on the SoC. > > and all of that SoC-specific detail is already hidden behind power > domains, runtime PM, pinctrl, clk API, regulator framework, etc. I agree. pinctrl has already done a fair job at trying to be abstract in the states requested from the core, in <linux/pinctrl/pinctrl-state.h>. And I accept the idea to try to centralize more as well, maybe as a helpful struct and some inlines for the pinctrl core. I think this is enough, and pushing all handles into central code creates a problem elsewhere. (But I'm not so certain ... so I might just change opinion one of those days depending on what arguments will be made.) Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
