[PATCH 6/6] ARM: dts: add pinctrl in PXA DT files

Linus Walleij linus.walleij at linaro.org
Fri Aug 10 06:56:51 EDT 2012


On Thu, Aug 9, 2012 at 4:28 PM, Daniel Mack <zonque at gmail.com> wrote:

> I am looking at the generic pinctrl code right now

Sweet!

> and I wonder if the following approach would be ok:
>
> - each driver that calls pinctrl_register() has its own dt_match_table
> entry, so the 'compatible' part of the bindings is specific to a pin
> controller chip.

Yep.

> - introduce a pinctrl_parse_of(struct of_node *) and call that after the
> driver has added all its pins. That function walks all the children of
> the given node and uses the callbacks provided by the driver to do the
> actual work.

Isn't that already how it works? Maybe I misunderstand, do you mean
that you want to pass the DT node to pinctrl_register()?

Are you talking about using pinctrl hogs to set up the default
configuration and muxing? That can already be done today,
and has nothing to do with whether you use generic pin config
or not.

This uses the .dt_node_to_map() and .dt_free_map() callbacks
in the pinctrl_ops vtable to generate a map from the device tree,
in any way you want.

So the infrastructure I think already exists, but whereas all
current driver have their own config and mux (etc) parsing
code, pinconf-generic could provide something that would
be common for all driver using generic pin config.

> - Unfortunately, we can't parse the node from pinctrl_register() as the
> gpio ranges are only added after that by the drivers.

The ranges are a *big* problem and we haven't come up with
a proper DT binding for these. After discussion with Grant,
he has proposed that GPIO chips should register their ranges
using their local numberspace and always passing the
struct gpio_chip, instead of pin controllers registering ranges.
Documented here:
https://blueprints.launchpad.net/linux-linaro/+spec/pinctrl-gpiorange-makeover

> If that sounds good, I can come up with a patch.

I think you already have what you need, look closer at how
e.g. the Tegra or i.MX driver does this. Or maybe I'm only
getting it backwards?

Yours,
Linus Walleij



More information about the linux-arm-kernel mailing list