Tomasz, On Wed, May 15, 2013 at 2:36 PM, Tomasz Figa <tomasz.figa@xxxxxxxxx> wrote: >> One potential reason for leaving them is the hopes that it might cause >> a little less line glitching, especially in the case of outputs. >> There is some delay between the pinmux being configured at the start >> of device probe and the device actually claiming the GPIO. Things >> might be worse in the case of deferred probe (?). Can you think of >> any reason to remove (other than yet more lines of device tree to deal >> with)? > > Well, actually in case of interrupts the function should not be configured > manually, because it is likely to cause a false interrupt to be caught, > before appropriate interrupt trigger type is configured. The correct way > is to leave setting pin function to EINT to the pin control driver once > the trigger gets configured (the pin control driver configures pin > function from set_irq_type callback). Ah, OK. I'll set to input for these. >> I will probably leave them even for inputs. They shouldn't matter but >> I like the idea of initting things to a known state... > > Well, the binding you proposed for interrupts doesn't initialize it. This > is why I pointed that it can be omitted using current way as well. Agreed. ...though you could say that the actual code in that case would just be setting the drive strength to 0 (for consistency). ;) -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
 |