On Thu, 2016-09-29 at 16:15 +0930, Joel Stanley wrote: > On Wed, Sep 28, 2016 at 12:20 AM, Andrew Jeffery <andrew@xxxxxxxx> wrote: > > > > The System Control Unit IP in the Aspeed SoCs is typically where the > > pinmux configuration is found. > > > > But not always. > > > > On the AST2400 and AST2500 a number of pins depend on state in one of > > the SIO, LPC or GFX IP blocks, so add support to at least capture what > > that state is. The pinctrl engine for the Aspeed SoCs doesn't try to > > inspect or modify the state of the off-SCU IP blocks. Instead, it logs > > the state requirement with the expectation that the platform > > designer/maintainer arranges for the appropriate configuration to be > > applied through the associated drivers. > This is unfortunate. > > This patch kicks the can down the road, but doesn't solve the problem > for a user who wants to configure some functionality that depends on > the non-SCU bits. Because of this I'm not sure if we want to put it in > the tree. I agree that there's not much functionality from a user's perspective, but the "kicking the can down the road" assessment might be a little harsh. Given the lack of user functionality it becomes more difficult to argue for the patch's inclusion given the additional complexity, but it does mean that the g4/g5 drivers can completely specify their dependencies and not have the aspeed pinctrl core do the wrong thing when it encounters the non-SCU IP offsets. It gets us half-way to having the pinctrl driver actually configure the state (knowing what it needs to configure), which I feel is more than a kick-the-can-down-the- road boondoggle. > > However, I'm not sure what a proper solution would look like. So if we accept that a proper solution includes specifying the off-SCU dependencies, the remaining question is how do we tastefully apply the desired state on register-spaces the pinctrl driver doesn't own. > Perhaps > Linus can point out another SoC that has a similar problem? Or failing that, an approach that is acceptable... Cheers, Andrew
Attachment:
signature.asc
Description: This is a digitally signed message part
