[RFC PATCH v2 4/4] mmc: sdhci-esdhc-imx: using pinmux subsystem
shawn.guo at freescale.com
Thu Dec 15 04:03:58 EST 2011
On Thu, Dec 15, 2011 at 09:26:40AM +0100, Linus Walleij wrote:
> On Thu, Dec 15, 2011 at 8:05 AM, Shawn Guo <shawn.guo at freescale.com> wrote:
> >> So if you want to do this for i.MX you need something like
> >> selectable dummy pinmuxes, i.e. pinmux_get() to return something
> >> that just say "OK" to everything like the dummy regulators.
> >> Shall I try to create something like that?
> > Isn't the empty functions defined in include/linux/pinctrl/pinmux.h
> > for this purpose?
> No, these are for compiling it *out*, dummy pinmuxes would
> be if you compile it *in*, but don't find an apropriate pinmux,
> you still get something that does nothing and still works.
> Dummy regulators work exactly this way.
> > It does not solve the problem with single image.
> I think it does.
> > You might probably mean that we create a dummy_pinctrl_desc and register
> > it to pinctrl core with pinctrl_register() if we detect that the kernel
> > is running on a soc that has no pinctrl support?
> No. You have a #ifdef CONFIG_PINMUX_DUMMY in pinmux_get()
> that makes sure you return a working no-op pinmux handle even
> though there is no real pinmux behind it.
Ah, ok. So the problem will be sorted out at pinctrl core level, and
pinctrl driver will not be bothered at all. Yes, please, we need this.
> > This is not a problem to pinctrl migration only. We have the same
> > problem with common clk migration. Unless we migrate imx3, imx5 and
> > imx6 to common clk at the same time, single image build just does not
> > cope with clk_* api.
> And you could have the same problem with regulator migration...
> Luckily dummy regulators saves you in that case.
Not sure what will save me in common clk case though.
More information about the linux-arm-kernel