Re: [RFC PATCH v2 4/4] mmc: sdhci-esdhc-imx: using pinmux subsystem

[Linus Walleij]

On Thu, Dec 15, 2011 at 8:05 AM, Shawn Guo <shawn.guo@xxxxxxxxxxxxx> wrote:
>[Me]
>> 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.

> 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.

Thanks,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/