* Linus Walleij <linus.walleij@xxxxxxxxxx> [111122 03:30]:
> On Tue, Nov 22, 2011 at 12:09 PM, Thomas Abraham
> <thomas.abraham@xxxxxxxxxx> wrote:
> > On 17 November 2011 19:27, Linus Walleij <linus.walleij@xxxxxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
