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

[Dong Aisheng-B29396]

> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij at linaro.org]
> Sent: Thursday, December 15, 2011 4:29 PM
> To: Dong Aisheng-B29396
> Cc: Sascha Hauer; linus.walleij at stericsson.com; linux-
> kernel at vger.kernel.org; rob.herring at calxeda.com;
> grant.likely at secretlab.ca; linux-arm-kernel at lists.infradead.org;
> kernel at pengutronix.de; Guo Shawn-R65073
> Subject: Re: [RFC PATCH v2 4/4] mmc: sdhci-esdhc-imx: using pinmux
> subsystem
> Importance: High
> 
> On Thu, Dec 15, 2011 at 8:23 AM, Dong Aisheng-B29396
> <B29396 at freescale.com> 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?
> >
> > For those platforms do not select PINCTRL, current code does not block.
> 
> Yeah I know...
> 
> > For platforms do select PINCTRL but does not have pinmux driver ready,
> > for example, single image for both mx5&mx6, IMHO it may be better to
> > fix in driver to avoid introduce too much complexity in pinctrl core.
> 
> If you mean that you fix the i.MX driver for all the combines i.MX
> variants then I agree.
> 
Yes, I mean this one.

> If you mean to do stuff like allow the code to continue even if the
> pinmux isn't found - no. That is not the way we proceed with clocks and
> regulators as Mark has taught me recently, so for consistency we need to
> error out if no pinmux is found.
> 

Regards
Dong Aisheng