On 05/15/2013 12:29 PM, Linus Walleij wrote:
> On Wed, May 15, 2013 at 6:44 PM, Doug Anderson <dianders@xxxxxxxxxx> wrote:
...
>> Here's how I need to do things when I'm using "just an interrupt":
>>
>> pinctrl@11400000 {
>> cyapa_irq: cyapa-irq {
>> samsung,pins = "gpx1-2";
>> samsung,pin-function = <0xf>;
>> samsung,pin-pud = <0>;
>> samsung,pin-drv = <0>;
>> };
>> };
>>
>> trackpad {
>> reg = <0x67>;
>> compatible = "cypress,cyapa";
>> interrupts = <2 0>;
>> interrupt-parent = <&gpx1>;
>> pinctrl-names = "default";
>> pinctrl-0 = <&cyapa_irq>;
>> wakeup-source;
>> };
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.
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:-)
>> I really wish I could add a 3rd number to the interrupt specifier for
>> pud and skip the pinctrl bit:
>>
>> trackpad {
>> reg = <0x67>;
>> compatible = "cypress,cyapa";
>> interrupts = <2 0 0>;
>> interrupt-parent = <&gpx1>;
>> wakeup-source;
>> };
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.
--
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
