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

From: Dong Aisheng-B29396
Date: Thu Dec 15 2011 - 03:56:00 EST


> -----Original Message-----
> From: Linus Walleij [mailto:linus.walleij@xxxxxxxxxx]
> Sent: Thursday, December 15, 2011 4:29 PM
> To: Dong Aisheng-B29396
> Cc: Sascha Hauer; linus.walleij@xxxxxxxxxxxxxx; linux-
> kernel@xxxxxxxxxxxxxxx; rob.herring@xxxxxxxxxxx;
> grant.likely@xxxxxxxxxxxx; linux-arm-kernel@xxxxxxxxxxxxxxxxxxx;
> kernel@xxxxxxxxxxxxxx; 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@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?
> >
> > 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


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