Re: [PATCH 2/2 v7] pinmux: add a driver for the U300 pinmux

[Linus Walleij]

On Wed, Sep 21, 2011 at 12:15 AM, Stephen Warren <swarren@xxxxxxxxxx> wrote:
> Linus Walleij wrote at Friday, September 16, 2011 6:14 AM:
>> +     for (i = 0; i < ARRAY_SIZE(u300_mux_hogs); i++) {
>> +             struct pinmux *pmx;
>> +             int ret;
>> +
>> +             pmx = pinmux_get(u300_mux_hogs[i].dev, NULL);
>> +             if (IS_ERR(pmx)) {
>> +                     pr_err("u300: could not get pinmux hog %s\n",
>> +                            u300_mux_hogs[i].name);
>> +                     continue;
>> +             }
>> +             ret = pinmux_enable(pmx);
>> +             if (ret) {
>> +                     pr_err("u300: could enable pinmux hog %s\n",
>> +                            u300_mux_hogs[i].name);
>> +                     continue;
>> +             }
>> +             u300_mux_hogs[i].pmx = pmx;
>> +     }
>> +     return 0;
>> +}
>> +subsys_initcall(u300_pinmux_fetch);
>
> Why not just have the pinmux core support hogging on non-"system" mapping
> entries; then everything I quoted above except u300_pinmux_map[] could
> be deleted, and the "hog" flag set on the last 3 u300_pinmux_map[] entries.

Very good question, luckily I have a good answer.

There is no way for the pinmux core to traverse the system and look
up the apropriate struct device * pointers.

When/if we have device tree support, I think this will be possible, then I
will be able to have the pinmux hog look up devices from device tree
and hog their pinmux.

At that point we'll likely have the mapping in the device tree too and
the core does not need to be involved at all.

What I could do right now is add some open-ended function like
pinmux_hog_device_pinmuxes(struct device **devices);
that can take an array of devices and hog their respective
pinmuxes in the hog list. Do you think it's a good idea?

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/