lkml.org 
[lkml]   [2012]   [Jan]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRE: Pinmux bindings proposal
    Date
    > -----Original Message-----
    > From: Stephen Warren [mailto:swarren@nvidia.com]
    ....

    > > Considering the different pinctrl configurations for the same client
    > > device usually share the same pinmux and only pinconf varies. It may
    > > worth introducing another level phandle reference. Something like the
    > > following:
    >
    > I don't think there's a need for another level of indirection. The 1:n model I
    > was talking about already handles this, I believe. See below.
    >
    > > pinmux_sdhci: pinmux-sdhci {
    > > mux =
    > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_MUX_1>
    > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_MUX_1>;
    > > };
    > >
    > > pinconf_sdhci_active: pinconf-sdhci-active {
    > > config =
    > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
    > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
    > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
    > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
    > > };
    > >
    > > pinconf_sdhci_suspend: pinconf-sdhci-suspend {
    > > config =
    > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_TRISTATE 1>
    > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_TRISTATE 1>
    > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
    > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_DRIVE_STRENGTH 5>
    > > <&tegra_pmx TEGRA_PMX_PG_DTA TEGRA_PMX_CONF_SLEW_RATE 4>
    > > <&tegra_pmx TEGRA_PMX_PG_DTD TEGRA_PMX_CONF_SLEW_RATE 8>;
    > > };
    >
    > Those 3 nodes make sense to me.
    >
    > > pinctrl_sdhci_active: pinctrl-sdhci-active {
    > > pinmux = <&pinmux_sdhci>;
    > > pinconf = <&pinconf_sdhci_active>;
    > > };
    > >
    > > pinctrl_sdhci_suspend: pinctrl-sdhci-suspend {
    > > pinmux = <&pinmux_sdhci>;
    > > pinconf = <&pinconf_sdhci_suspend>;
    > > };
    >
    > I think we can avoid those 2 nodes.
    >
    > > sdhci@c8000200 {
    > > ...
    > > pinctrl = <&pinctrl_sdhci_active> <&pinctrl_sdhci_suspend>;
    > > pinctrl-names = "active", "suspend";
    > > };
    >
    > And rewrite that node as:
    >
    > sdhci@c8000200 {
    > ...
    > pinctrl = <&pinmux_sdhci> <&pinconf_sdhci_active>
    > <&pinmux_sdhci> <&pinconf_sdhci_suspend>;
    > pinctrl-names = "active", "active", "suspend", "suspend"; };
    >
    > The only slight disadvantage here is that the person constructing the
    > pinctrl/pinctrl-names properties needs to know to explicitly list both the
    > separate mux/config phandles for each value in pinctrl-names. Still, this seems
    > a reasonable compromise; the user is still picking from a bunch of pre-
    > defined/canned nodes, they simply need to list 2 (or n in
    > general) of them for each state.
    >
    > > This will be pretty useful for imx6 usdhc case, which will have 3
    > > pinctrl configuration for each usdhc device (imx6 has 4 usdhc
    > > devices), pinctrl-50mhz, pinctrl-100mhz and pinctrl-200mhz. All these
    > > 3 states have the exactly same pinmux settings, and only varies on pinconf.
    >
    > Yes, I definitely agree there's a need for this.
    >
    > As an aside, I wonder if the following would be any better:
    >
    > sdhci@c8000200 {
    > ...
    > pinctrl = <&pinmux_sdhci> <&pinconf_sdhci_active>
    > <&pinmux_sdhci> <&pinconf_sdhci_suspend>;
    > /* Number of entries in pinctrl for each in pinctrl-names */
    > pinctrl-entries = <2 2>;
    > pinctrl-names = "active", "suspend"; };
    >
    > That seems more complex though.
    >
    This makes sense to me.

    Regards
    Dong Aisheng




    \
     
     \ /
      Last update: 2012-01-18 10:35    [W:0.029 / U:32.672 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site