On Wednesday 15 of May 2013 14:31:20 Doug Anderson wrote: > Linus, > > Thank you for your comments. See below... > > Stephen: sorry for missing you earlier! :( > > On Wed, May 15, 2013 at 11:29 AM, Linus Walleij > > <linus.walleij@xxxxxxxxxx> wrote: > > But please use the preprocessor to provide symbolic names for > > the configurations. See for example these two patches from > > J-C: > > http://www.mail-archive.com/devicetree-discuss@xxxxxxxxxxxxxxxx/msg321 > > 64.html > Ah, that does look nice! This probably needs to be addressed in a > separate patch to cleanup all of the samsung pinctrl devicetrees. > > > I don't think the idea with device tree is to write as compact trees > > as possible, but as expressive and exact yet abstract trees as > > possible for OS independence. > > The compactness was one benefit, but also it was about trying to avoid > excessive duplication of information. I found it awkward that I > needed to list that my interrupt was "gpx1-2" in two different ways. > > I would find it just as good if I could express things like this (for > interrupts): > > pinctrl@11400000 { > cyapa_irq: cyapa-irq { > samsung,pins = "gpx1-2"; > samsung,pin-function = <0xf>; > samsung,pin-pud = <0>; > samsung,pin-drv = <0>; > > interrupt-controller; > #interrupt-cells = <1>; > }; > }; > > trackpad { > reg = <0x67>; > compatible = "cypress,cyapa"; > interrupt-parent = <&cyapa_irq>; > interrupts = <0>; > wakeup-source; > }; > > In this case I'm not saying that my interrupt parent is "gpx1-2" in > two separate places that could diverge. This will be hard, since the phandle in interrupt-parent is represented by an IRQ domain in kernel code. One-interrupt IRQ domains seem a bit awkward to me. Since we are already going to modify the binding, let's think a bit more about this problem and try to figure out a solution that doesn't add any disadvantages (at least any significant) to avoid such situation in future again. Best regards, Tomasz -- 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
 |