Stephen,
On Wed, May 15, 2013 at 4:51 PM, Stephen Warren <swarren@xxxxxxxxxxxxx> wrote:
> I don't really see much disadvantage here; the interrupt bindings
> specify things related to interrupts and the pinctrl bindings specify
> thing related to pin configuration.
OK. If this is the best way then I can accept that and maybe we
should just drop this thread. What do people think? It means less
work for me in the short term since I've already got it implemented
that way and then I don't need to submit any patches to try to change
things! ;)
> If you want to condense the DT, I'd suggest using a the pinctrl hogging
> feature, i.e. don't put pinctrl-* properties in the trackpad node, but
> rather define a system-wide "default" pinctrl state in the pin
> controller node itself. That configuration will be applied as soon as
> the pin controller driver is registered. That'd be the same as the
> above, with the following added:
>
> pinctrl@11400000 {
> pinctrl-names = "default";
> pinctrl-0 = <&cyapa_irq>;
> };
>
> except that the pinctrl-0 property would probably end up configuring a
> whole bunch of basic pinctrl state rather than just that one interrupt pin.
>
> I prefer to put all the static pinctrl configuration in the pinctrl hog,
> and only the dynamic stuff in the individual device nodes.
>
> I know LinusW won't like this suggestion much though:-)
Ah right! I forgot about hogs in this case. That's also reasonable
as a solution and is similar to what we've got in the tree for
powerdown configuration of pins (I'll try to post this patch soon too,
WIP at <https://gerrit.chromium.org/gerrit/#/c/51292/> and
<https://gerrit.chromium.org/gerrit/#/c/51372/>.
It sounds like there's a bit of disagreement about the "best way" so
I'll probably keep the way I have. ...but I'll keep hogs in my back
pocket.
> I don't like that myself, since it makes the interrupt binding (and I
> assume you'd want to go back to the similar misuse in the GPIO binding)
> also configure pinctrl-related stuff.
Fair enough. :)
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
