lkml.org 
[lkml]   [2012]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 1/3] pinctrl: pinctrl-imx: add imx pinctrl core driver
On Sun, Apr 15, 2012 at 11:49:04AM +0800, Dong Aisheng wrote:
...
> >> +iomuxc@020e0000 {
> >> +     compatible = "fsl,imx6q-iomuxc";
> >> +     reg = <0x020e0000 0x4000>;
> >> +
> >> +     /* shared pinctrl settings */
> >> +     usdhc4 {
> >> +             pinctrl_usdhc4_1: usdhc4grp-1 {
> >> +                     fsl,pins =      "MX6Q_PAD_SD4_CMD",
> >> +                                     "MX6Q_PAD_SD4_CLK",
> >> +                                     "MX6Q_PAD_SD4_DAT0",
> >> +                                     "MX6Q_PAD_SD4_DAT1",
> >> +                                     "MX6Q_PAD_SD4_DAT2",
> >> +                                     "MX6Q_PAD_SD4_DAT3",
> >> +                                     "MX6Q_PAD_SD4_DAT4",
> >> +                                     "MX6Q_PAD_SD4_DAT5",
> >> +                                     "MX6Q_PAD_SD4_DAT6",
> >> +                                     "MX6Q_PAD_SD4_DAT7";
> >
> > Do we really want to have all combinations of all pins in the devicetree
> > as strings? This is going to be huge.
> >
> Correct.
> My plan is:
> 1) not all combinations, just define frequently used ones since
> it's hard to define all combinations groups for per based IMX.
> (maybe we can try to add a fix-up function which can do minor changes
> based on available ones, then user does not need to write a new group
> caused by only a small change.
> what do you think?)
>
> 2) When dt supports macro, will try convert string to integer macro.
> Then it maybe:
> fsl,pins = <MX6Q_PAD_SD4_CMD 0
> MX6Q_PAD_SD4_CLK 0
> MX6Q_PAD_SD4_DAT0 1
> .................>,
> Why i did not start pin id with a raw integer is because it's less
> meaning to user and
> not easy to read in dts file.
>
We may want to use integer from the beginning to reduce the churn on
driver later.

I'm thinking about documenting the definition we used to have in
iomux-mx*.h in the binding document and assign id to each of them
in order.

pinmux id
------ --
MX6Q_PAD_SD2_DAT1__USDHC2_DAT1 0
MX6Q_PAD_SD2_DAT1__ECSPI5_SS0 1
MX6Q_PAD_SD2_DAT1__WEIM_WEIM_CS_2 2
...

The ordering between the list and imx6q_pin_regs[] array need to match.

By looking at the binding document, we can just put pinmux-id into
property "fsl,pins" (maybe rename it to "fsl,pinmux-ids") to get the
desired pinmux settings. With doing so, we can gain the following.

1) The pinmux-id can be used as index to locate the entry in array
imx6q_pin_regs[], so that the slow string lookup can be avoid.

2) Property "fsl,mux" can be dropped, as it's been encoded in
imx6q_pin_regs[] entry.

3) Converting the existing board files to device tree will be much
easier. We only need to find the pinmux-id of those existing
definitions and put them in "fsl, pinmux-ids".

4) When DTC support macro, we can simply move the pinmux-id list from
binding document into dts file. No driver change is needed at all.

Thoughts?

Regards,
Shawn

> 3) maybe we need a separate imx6q-pinctrl.dtsi when it becomes big
> after adding all device support.
>
> >> +                     fsl,mux = <0 0 1 1 1 1 1 1 1 1>;
> >
> > Still we lose the precious information which pin can be put into which
> > mode which means that you have to look at the datasheet each time a pin
> > is missing.
> To avoid this, i also put the pad function macro in driver, user can
> look at the pinctrl SoC driver instead of look at the datasheet.
> See:
> [PATCH 2/3] pinctrl: pinctrl-imx: add imx6q pinctrl drive
> +/* imx6q register maps */
> +static struct imx_pin_reg imx6q_pin_regs[] = {
> + IMX_PIN_REG(MX6Q_PAD_SD2_DAT1, 0x0360, 0x004C, 0, 0x0000, 0),
> /* MX6Q_PAD_SD2_DAT1__USDHC2_DAT1 */
> + IMX_PIN_REG(MX6Q_PAD_SD2_DAT1, 0x0360, 0x004C, 1, 0x0834, 0),
> /* MX6Q_PAD_SD2_DAT1__ECSPI5_SS0 */
> .......
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2012-04-15 16:19    [W:0.123 / U:0.192 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site