lkml.org 
[lkml]   [2012]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Pinmux bindings proposal V2
    * Dong Aisheng <dongas86@gmail.com> [120202 11:36]:
    >
    > Actually i think i'd rather do not use config property, then i could
    > be more compact:
    > (anyway it's another issue and is flexible to be controlled by #pinmux-cells)
    > pinctrl_usdhc4: pinconfig-usdhc4 {
    > /* 0: pin 1: group */
    > mux-entity = <0>;
    > func-name = "usdhc4func";
    > grp-name = "usdhc4grp";

    The func-name and grp-name should be optional here.
    This mux entry is already the group, and can be used as
    the group name. And the function name can be generated
    dynamically in most cases. I'm currently using np->full_name
    of the driver claiming these pins as the function name.

    > mux =
    > <MX6Q_SD4_CMD 0 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_CLK 0 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_DAT0 1 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_DAT1 1 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_DAT2 1 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_DAT3 1 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_DAT4 1 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_DAT5 1 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_DAT6 1 MX6Q_USDHC_PAD_CTRL>
    > <MX6Q_SD4_DAT7 1 MX6Q_USDHC_PAD_CTRL>;
    > };

    For listing basic pins this format works fine for me. It seems
    to have low overhead for parsing. And the width of the array
    can be driver specific.

    Looks like it's the binding for altenative states that's still a
    bit open..

    So how about let's first standardize on the mux format above?

    Then we can enhance it later for describing alternative states?

    Regards,

    Tony


    \
     
     \ /
      Last update: 2012-02-03 18:35    [W:0.024 / U:0.120 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site