Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Linus Walleij]

On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
<thomas.abraham@linaro.org> wrote:

> For now, the Samsung GPIO, Pinconfig and Pinmux information is
> represented in device tree as listed below.

Does this mean that the understanding of this format is merged into
the mainline kernel drivers or is it keps out-of-tree?

> i2c@1C004000 {
>          compatible = "...";
>          reg = <0x... 0x..>;
>           gpios = <&gpa0 2 2 3 0>,
>                      <&gpa0 3 2 3 0>;
>          ...
> };
>
> The format of the gpio specifier is
> <[Pad Controller phandle] [pin number within the controller] [Pin Mux
> Function] [Pull Up/Down] [Drive Strength]>
>
> From a perspective of writing a 'gpios' property for a device node,
> this is quite simple. Looking up the hardware manual of the SoC can
> provide all the values that should be used in the gpio specifier.

That may not be as simple as it seems if all you have is the
device tree and no manual, but I get the picture.

> The GPIO/PinCtrl driver can provide a translate function that picks up
> the values for the gpio specifier and writes the same value to the
> pad-controller registers. But, this a deviation from the existing
> pinctrl subsystem code which mainly relies on name of the pin-group
> and pin-function.
>
> Does this seem to be a feasible option for specifying
> gpio/pinconfig/pinmux dt bindings?

I would prefer the above to use the nice generic enums from the
pin control subsystem's pinmux and pinconf properties in the
end so the device tree on its own is understandable without
any manual whatsoever, but we'll see about that.

Maybe I'm mistaken about the device tree ambitions, but
I was sort of hoping that it would not contain too much
custom magic numbers that need to be cross-referenced
elsewhere ... or rather - the more understandable the device
tree is, the more we win.

Thanks,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Thomas Abraham]

Hi Linus,

On 17 November 2011 19:27, Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
> On Thu, Nov 17, 2011 at 12:26 PM, Thomas Abraham
> <thomas.abraham-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:
>
>> For now, the Samsung GPIO, Pinconfig and Pinmux information is
>> represented in device tree as listed below.
>
> Does this mean that the understanding of this format is merged into
> the mainline kernel drivers or is it keps out-of-tree?


All existing dt support in samsung drivers use this format and it
works fine. But I could not complete work on time and pull request for
samsung-dt support for 3.2 was delayed and hence rejected. So for now,
it is out of tree but available in linux-next.

>
>> i2c@1C004000 {
>>          compatible = "...";
>>          reg = <0x... 0x..>;
>>           gpios = <&gpa0 2 2 3 0>,
>>                      <&gpa0 3 2 3 0>;
>>          ...
>> };
>>
>> The format of the gpio specifier is
>> <[Pad Controller phandle] [pin number within the controller] [Pin Mux
>> Function] [Pull Up/Down] [Drive Strength]>
>>
>> From a perspective of writing a 'gpios' property for a device node,
>> this is quite simple. Looking up the hardware manual of the SoC can
>> provide all the values that should be used in the gpio specifier.
>
> That may not be as simple as it seems if all you have is the
> device tree and no manual, but I get the picture.
>
>> The GPIO/PinCtrl driver can provide a translate function that picks up
>> the values for the gpio specifier and writes the same value to the
>> pad-controller registers. But, this a deviation from the existing
>> pinctrl subsystem code which mainly relies on name of the pin-group
>> and pin-function.
>>
>> Does this seem to be a feasible option for specifying
>> gpio/pinconfig/pinmux dt bindings?
>
> I would prefer the above to use the nice generic enums from the
> pin control subsystem's pinmux and pinconf properties in the
> end so the device tree on its own is understandable without
> any manual whatsoever, but we'll see about that.


This may lead to linux specific information getting into the device
tree. And that might not be acceptable.

>
> Maybe I'm mistaken about the device tree ambitions, but
> I was sort of hoping that it would not contain too much
> custom magic numbers that need to be cross-referenced
> elsewhere ... or rather - the more understandable the device
> tree is, the more we win.

Device tree is expected to describe the hardware. So to
cross-reference the hardware manual to understand device tree should
be fine I guess. For instance, GPIO numbers in dts would be written as
a numeric number and not a enum or other format. And by looking up the
manual, we understand the actual details of the GPIO pin.

If dt-compiler had a option to support #define like in C, the numbers
could have been made more easier to understand. Like, 3 to mean
GPIO_PULL_UP in Exynos dts file.

Thanks,
Thomas.

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Linus Walleij]

On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
<thomas.abraham@linaro.org> wrote:
> On 17 November 2011 19:27, Linus Walleij <linus.walleij@linaro.org> wrote:
>>
>> Maybe I'm mistaken about the device tree ambitions, but
>> I was sort of hoping that it would not contain too much
>> custom magic numbers that need to be cross-referenced
>> elsewhere ... or rather - the more understandable the device
>> tree is, the more we win.
>
> Device tree is expected to describe the hardware. So to
> cross-reference the hardware manual to understand device tree should
> be fine I guess. For instance, GPIO numbers in dts would be written as
> a numeric number and not a enum or other format. And by looking up the
> manual, we understand the actual details of the GPIO pin.
>
> If dt-compiler had a option to support #define like in C, the numbers
> could have been made more easier to understand. Like, 3 to mean
> GPIO_PULL_UP in Exynos dts file.

OK I think I get it now, so DT bindings shall really NOT be read
by any of the pinctrl core, it is *supposed* to be all driver-specific.
Then it makes perfect sense to have it as it is.

So for example in the pinctrl-coh901xxx.c example driver I have
locally defined registers presets like:

#define U300_FLOATING_INPUT { \
        .bias_mode = PIN_CONFIG_BIAS_HIGH_IMPEDANCE, \
        .output = false, \
}

#define U300_PULL_UP_INPUT { \
        .bias_mode = PIN_CONFIG_BIAS_PULL_UP, \
        .output = false, \
}

Then this type of stuff shall keep its custom format in the device
tree, and the driver for coh901xxx reads that out.

Thanks for helping me understand this crucial assumption of how
it works...

Yours,
Linus Walleij

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Tony Lindgren]

* Linus Walleij <linus.walleij@linaro.org> [111122 03:30]:
> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> <thomas.abraham@linaro.org> wrote:
> > On 17 November 2011 19:27, Linus Walleij <linus.walleij@linaro.org> wrote:
> >>
> >> Maybe I'm mistaken about the device tree ambitions, but
> >> I was sort of hoping that it would not contain too much
> >> custom magic numbers that need to be cross-referenced
> >> elsewhere ... or rather - the more understandable the device
> >> tree is, the more we win.
> >
> > Device tree is expected to describe the hardware. So to
> > cross-reference the hardware manual to understand device tree should
> > be fine I guess. For instance, GPIO numbers in dts would be written as
> > a numeric number and not a enum or other format. And by looking up the
> > manual, we understand the actual details of the GPIO pin.
> >
> > If dt-compiler had a option to support #define like in C, the numbers
> > could have been made more easier to understand. Like, 3 to mean
> > GPIO_PULL_UP in Exynos dts file.
> 
> OK I think I get it now, so DT bindings shall really NOT be read
> by any of the pinctrl core, it is *supposed* to be all driver-specific.
> Then it makes perfect sense to have it as it is.

Yes the driver nodes should describe in DT which pins to use:

        serial@12340000 {
                compatible = "8250";
                reg = <0x12340000 0x40>;
                reg-shift = <2>;
                interrupts = < 10 >;
		pins = "uart1_rx", "uart1_tx";
        };

Note that we should use the actual signal names, not package specific
pad names. This way they have a high likelyhood to work for new packages
too by just mapping the signals to the new package.

> So for example in the pinctrl-coh901xxx.c example driver I have
> locally defined registers presets like:
> 
> #define U300_FLOATING_INPUT { \
>         .bias_mode = PIN_CONFIG_BIAS_HIGH_IMPEDANCE, \
>         .output = false, \
> }
> 
> #define U300_PULL_UP_INPUT { \
>         .bias_mode = PIN_CONFIG_BIAS_PULL_UP, \
>         .output = false, \
> }

I think things like above should also be set in the node for the
driver because it is board specific. For example, if you have an
external pull on the board for some line, then the internal pull
needs to be disabled.

I don't know how we should describe the driver set values though,
maybe something like:

        serial@12340000 {
                compatible = "8250";
                reg = <0x12340000 0x40>;
                reg-shift = <2>;
                interrupts = < 10 >;
		pins = "uart1_rx", "uart1_tx";
		pin-values = < 0x7 0x7 >;
	};

Note that with device tree things get simpler for muxing as we can
get rid of the hardcoded grouping of pins in mux drivers. Instead of
hardcoded pingroups, the groups can be created dynamically based on
what the driver DT entries have.

The reason why we want to avoid hardcoded pin groups is because trying
to map all the pad combinations in the pinmux driver is not a scalable
way to go. And it's not even possible at least on omaps because of the
huge number of combinations with alternative pins and multiple packages.

> Then this type of stuff shall keep its custom format in the device
> tree, and the driver for coh901xxx reads that out.
> 
> Thanks for helping me understand this crucial assumption of how
> it works...

FYI I'm playing with a DT based pinmux-simple.c driver that should
be pretty generic and work for all kinds of hardware hopefully.

It will be few days before I can post anything though, there are
some pinctrl fwk issues to deal with first. Like the hardcoded
pinmux_maps that assumes that dev entries are static. This means
that multiple instances of pinmux drivers won't work..

Cheers,

Tony

RE: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Stephen Warren]

Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
> * Linus Walleij <linus.walleij@linaro.org> [111122 03:30]:
> > On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> > <thomas.abraham@linaro.org> wrote:
> > > On 17 November 2011 19:27, Linus Walleij <linus.walleij@linaro.org> wrote:
> > >>
> > >> Maybe I'm mistaken about the device tree ambitions, but
> > >> I was sort of hoping that it would not contain too much
> > >> custom magic numbers that need to be cross-referenced
> > >> elsewhere ... or rather - the more understandable the device
> > >> tree is, the more we win.
> > >
> > > Device tree is expected to describe the hardware. So to
> > > cross-reference the hardware manual to understand device tree should
> > > be fine I guess. For instance, GPIO numbers in dts would be written as
> > > a numeric number and not a enum or other format. And by looking up the
> > > manual, we understand the actual details of the GPIO pin.
> > >
> > > If dt-compiler had a option to support #define like in C, the numbers
> > > could have been made more easier to understand. Like, 3 to mean
> > > GPIO_PULL_UP in Exynos dts file.
> >
> > OK I think I get it now, so DT bindings shall really NOT be read
> > by any of the pinctrl core, it is *supposed* to be all driver-specific.
> > Then it makes perfect sense to have it as it is.
> 
> Yes the driver nodes should describe in DT which pins to use:
> 
>         serial@12340000 {
>                 compatible = "8250";
>                 reg = <0x12340000 0x40>;
>                 reg-shift = <2>;
>                 interrupts = < 10 >;
> 		pins = "uart1_rx", "uart1_tx";
>         };

Sorry to jump in late here, but I wasn't aware of this thread.

I don't necessarily agree with that. Describing the HW doesn't necessarily
mean that each device needs to describe what pinmux pins it uses; one
could quite easily have the pinmux describe what settings the various
pins should have and which drivers will use those pins. That would map
very well to the pinctrl subsystem's mapping table, and at least Tegra's
existing pinmux tables, which are both just a big array of settings which
end up getting provided to drivers.

I'll try and track down the rest of this thread and catch up though...

-- 
nvpublic

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Jean-Christophe PLAGNIOL-VILLARD]

On 16:28 Tue 22 Nov     , Stephen Warren wrote:
> Tony Lindgren wrote at Tuesday, November 22, 2011 10:54 AM:
> > * Linus Walleij <linus.walleij@linaro.org> [111122 03:30]:
> > > On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> > > <thomas.abraham@linaro.org> wrote:
> > > > On 17 November 2011 19:27, Linus Walleij <linus.walleij@linaro.org> wrote:
> > > >>
> > > >> Maybe I'm mistaken about the device tree ambitions, but
> > > >> I was sort of hoping that it would not contain too much
> > > >> custom magic numbers that need to be cross-referenced
> > > >> elsewhere ... or rather - the more understandable the device
> > > >> tree is, the more we win.
> > > >
> > > > Device tree is expected to describe the hardware. So to
> > > > cross-reference the hardware manual to understand device tree should
> > > > be fine I guess. For instance, GPIO numbers in dts would be written as
> > > > a numeric number and not a enum or other format. And by looking up the
> > > > manual, we understand the actual details of the GPIO pin.
> > > >
> > > > If dt-compiler had a option to support #define like in C, the numbers
> > > > could have been made more easier to understand. Like, 3 to mean
> > > > GPIO_PULL_UP in Exynos dts file.
> > >
> > > OK I think I get it now, so DT bindings shall really NOT be read
> > > by any of the pinctrl core, it is *supposed* to be all driver-specific.
> > > Then it makes perfect sense to have it as it is.
> > 
> > Yes the driver nodes should describe in DT which pins to use:
> > 
> >         serial@12340000 {
> >                 compatible = "8250";
> >                 reg = <0x12340000 0x40>;
> >                 reg-shift = <2>;
> >                 interrupts = < 10 >;
> > 		pins = "uart1_rx", "uart1_tx";
> >         };
> 
> Sorry to jump in late here, but I wasn't aware of this thread.
> 
> I don't necessarily agree with that. Describing the HW doesn't necessarily
> mean that each device needs to describe what pinmux pins it uses; one
> could quite easily have the pinmux describe what settings the various
> pins should have and which drivers will use those pins. That would map
> very well to the pinctrl subsystem's mapping table, and at least Tegra's
> existing pinmux tables, which are both just a big array of settings which
> end up getting provided to drivers.
> 
> I'll try and track down the rest of this thread and catch up though...
I agreee here


as example on at91 I try to found a good way to let the macb driver to ask the
pin configuration

so in my mind i do not need put all pins in each board but in the dtsi and
then in the drivers just said
	pins = "mii";
	or
	pins = "rmii";
	or if I want to use the alternative config

	pins = "mii_alt";
	or
	pins = "rmii_alt";

and then in the dtsi I describe the  pin used for those configs
which is soc specifific not board

Best Regards,
J.

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Linus Walleij]

On Wed, Nov 23, 2011 at 1:28 AM, Stephen Warren <swarren-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org> wrote:

> Describing the HW doesn't necessarily
> mean that each device needs to describe what pinmux pins it uses; one
> could quite easily have the pinmux describe what settings the various
> pins should have and which drivers will use those pins. That would map
> very well to the pinctrl subsystem's mapping table, and at least Tegra's
> existing pinmux tables, which are both just a big array of settings which
> end up getting provided to drivers.

That sounds true. It's also something that is cleanly cut out as a very
well defined and abstract piece of hardware information to live in the
device tree and which would be useful for any OS using DT.

I'd have to see the device trees and corresponding map bindings
before I understand it fully though.

Just my €0.01
Linus Walleij

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Koen Kooi]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]


Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:

> * Linus Walleij <linus.walleij@linaro.org> [111122 03:30]:
>> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
>> <thomas.abraham@linaro.org> wrote:
>>> On 17 November 2011 19:27, Linus Walleij <linus.walleij@linaro.org> wrote:
>>>> 
>>>> Maybe I'm mistaken about the device tree ambitions, but
>>>> I was sort of hoping that it would not contain too much
>>>> custom magic numbers that need to be cross-referenced
>>>> elsewhere ... or rather - the more understandable the device
>>>> tree is, the more we win.
>>> 
>>> Device tree is expected to describe the hardware. So to
>>> cross-reference the hardware manual to understand device tree should
>>> be fine I guess. For instance, GPIO numbers in dts would be written as
>>> a numeric number and not a enum or other format. And by looking up the
>>> manual, we understand the actual details of the GPIO pin.
>>> 
>>> If dt-compiler had a option to support #define like in C, the numbers
>>> could have been made more easier to understand. Like, 3 to mean
>>> GPIO_PULL_UP in Exynos dts file.
>> 
>> OK I think I get it now, so DT bindings shall really NOT be read
>> by any of the pinctrl core, it is *supposed* to be all driver-specific.
>> Then it makes perfect sense to have it as it is.
> 
> Yes the driver nodes should describe in DT which pins to use:
> 
>        serial@12340000 {
>                compatible = "8250";
>                reg = <0x12340000 0x40>;
>                reg-shift = <2>;
>                interrupts = < 10 >;
> 		pins = "uart1_rx", "uart1_tx";
>        };
> 
> Note that we should use the actual signal names, not package specific
> pad names. This way they have a high likelyhood to work for new packages
> too by just mapping the signals to the new package.

How would this handle the situation where you can mux a signal to multiple pins? IIRC omap3 and am335x can do funny stuff with the display pins like being able to map the blue bits to different pinblocks.

regards,

Koen

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

RE: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Hiremath, Vaibhav]

> -----Original Message-----
> From: linux-omap-owner@vger.kernel.org [mailto:linux-omap-
> owner@vger.kernel.org] On Behalf Of Koen Kooi
> Sent: Wednesday, November 23, 2011 8:51 PM
> To: Tony Lindgren
> Cc: Linus Walleij; Thomas Abraham; Nayak, Rajendra; linux-
> omap@vger.kernel.org; linaro-dev@lists.linaro.org;
> linus.walleij@stericsson.com; linux-samsung-soc; devicetree-
> discuss@lists.ozlabs.org
> Subject: Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux
> 
> 
> Op 22 nov. 2011, om 18:54 heeft Tony Lindgren het volgende geschreven:
> 
> > * Linus Walleij <linus.walleij@linaro.org> [111122 03:30]:
> >> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> >> <thomas.abraham@linaro.org> wrote:
> >>> On 17 November 2011 19:27, Linus Walleij <linus.walleij@linaro.org>
> wrote:
> >>>>
> >>>> Maybe I'm mistaken about the device tree ambitions, but
> >>>> I was sort of hoping that it would not contain too much
> >>>> custom magic numbers that need to be cross-referenced
> >>>> elsewhere ... or rather - the more understandable the device
> >>>> tree is, the more we win.
> >>>
> >>> Device tree is expected to describe the hardware. So to
> >>> cross-reference the hardware manual to understand device tree should
> >>> be fine I guess. For instance, GPIO numbers in dts would be written as
> >>> a numeric number and not a enum or other format. And by looking up the
> >>> manual, we understand the actual details of the GPIO pin.
> >>>
> >>> If dt-compiler had a option to support #define like in C, the numbers
> >>> could have been made more easier to understand. Like, 3 to mean
> >>> GPIO_PULL_UP in Exynos dts file.
> >>
> >> OK I think I get it now, so DT bindings shall really NOT be read
> >> by any of the pinctrl core, it is *supposed* to be all driver-specific.
> >> Then it makes perfect sense to have it as it is.
> >
> > Yes the driver nodes should describe in DT which pins to use:
> >
> >        serial@12340000 {
> >                compatible = "8250";
> >                reg = <0x12340000 0x40>;
> >                reg-shift = <2>;
> >                interrupts = < 10 >;
> > 		pins = "uart1_rx", "uart1_tx";
> >        };
> >
> > Note that we should use the actual signal names, not package specific
> > pad names. This way they have a high likelyhood to work for new packages
> > too by just mapping the signals to the new package.
> 
> How would this handle the situation where you can mux a signal to multiple
> pins? IIRC omap3 and am335x can do funny stuff with the display pins like
> being able to map the blue bits to different pinblocks.
> 
That's quite not true, in case of omap3 pins are labeled as R0-R7, B0-B7 and
G0-G7; what changes is pixel format.

AM335x LCDC is completely different IP altogether and spec doesn't map
Colors to pins. It barely maps bit0 from memory to pinX.
Now you call it as a standard or legacy or may be due to SGX software,
the pixel format we use is BGR (as in memory). 
It is completely depends on how you interface the pins to LCD (considering)
Software support/requirement.

Thanks,
Vaibhav


> regards,
> 
> Koen

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Linus Walleij]

On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren <tony@atomide.com> wrote:

> Note that with device tree things get simpler for muxing as we can
> get rid of the hardcoded grouping of pins in mux drivers. Instead of
> hardcoded pingroups, the groups can be created dynamically based on
> what the driver DT entries have.

Yes, I know too little about DT to figure out how these should
come in.

> The reason why we want to avoid hardcoded pin groups is because trying
> to map all the pad combinations in the pinmux driver is not a scalable
> way to go. And it's not even possible at least on omaps because of the
> huge number of combinations with alternative pins and multiple packages.

Yes, that's a solid case!

> FYI I'm playing with a DT based pinmux-simple.c driver that should
> be pretty generic and work for all kinds of hardware hopefully.

I love it.

> It will be few days before I can post anything though, there are
> some pinctrl fwk issues to deal with first. Like the hardcoded
> pinmux_maps that assumes that dev entries are static. This means
> that multiple instances of pinmux drivers won't work..

I'm not following, but I guess I will understand when I see the
patches. The idea behind the current map concept is that you
get either a string or struct device * to identify the pin controller
and mapped device, that's as far as I thought it out, sorry for
any inherent limitations, they're not intentional...

Thanks,
Linus Walleij

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Tony Lindgren]

Hi,

* Linus Walleij <linus.walleij@linaro.org> [111124 01:29]:
> On Tue, Nov 22, 2011 at 6:54 PM, Tony Lindgren <tony@atomide.com> wrote:
> 
> > Note that with device tree things get simpler for muxing as we can
> > get rid of the hardcoded grouping of pins in mux drivers. Instead of
> > hardcoded pingroups, the groups can be created dynamically based on
> > what the driver DT entries have.
> 
> Yes, I know too little about DT to figure out how these should
> come in.
> 
> > The reason why we want to avoid hardcoded pin groups is because trying
> > to map all the pad combinations in the pinmux driver is not a scalable
> > way to go. And it's not even possible at least on omaps because of the
> > huge number of combinations with alternative pins and multiple packages.
> 
> Yes, that's a solid case!

So far it seems that device tree simplifies things here quite a bit in at
least two ways:

- We by default have automatically generated 1:1 mapping of devices to
  groups (of course others can be added too)

- We should be able to support new SoC packages with different pin on
  existing kernels, like distro kernels, just by modifying the the device
  tree data ;)
 
> > FYI I'm playing with a DT based pinmux-simple.c driver that should
> > be pretty generic and work for all kinds of hardware hopefully.
> 
> I love it.

Still need few more days with these patches..
 
> > It will be few days before I can post anything though, there are
> > some pinctrl fwk issues to deal with first. Like the hardcoded
> > pinmux_maps that assumes that dev entries are static. This means
> > that multiple instances of pinmux drivers won't work..
> 
> I'm not following, but I guess I will understand when I see the
> patches. The idea behind the current map concept is that you
> get either a string or struct device * to identify the pin controller
> and mapped device, that's as far as I thought it out, sorry for
> any inherent limitations, they're not intentional...

Yeah we can sort those out afterwards. We should probably pass over
the static board specific mapping as platform_data to the pinmux device
and make it be part of struct pinctrl_dev. Then new driver instances
can have their own pctldev->mapping and we can support both platform_data
and device tree based drivers on the same system. Anyways, I'll try to
get the initial patches working with just one instance to start with
so we have something to play
with.

Regards,

Tony

Re: [RFC 1/3] pinctrl: add a driver for the OMAP pinmux

[Linus Walleij]

On Thu, Nov 24, 2011 at 8:54 PM, Tony Lindgren <tony@atomide.com> wrote:

> We should probably pass over
> the static board specific mapping as platform_data to the pinmux device
> and make it be part of struct pinctrl_dev. Then new driver instances
> can have their own pctldev->mapping and we can support both platform_data
> and device tree based drivers on the same system.

That sounds like a real good idea and I think it'll work fine.

You can use the map in mach-u300/core.c as guinea pig for refactoring if you
like. I think that's the only map that's in-tree ftm.

Thanks,
Linus Walleij