On Fri, Aug 12, 2011 at 04:54:45PM -0600, Stephen Warren wrote: > This patch modifies Tegra's device tree support to remove the dependency > on harmony_pinmux_init(), thus making it completely board-independent. > > Some notes: > > * This series is built on top of linux-next with a bunch of patches > applied, in particular the removal of irq_to_gpio and custom gpio_to_irq > that I'm in the process of sending to Russell. I haven't yet thought > through how/where to merge this without causing all kinds of conflicts. > > * I took care to preserve bisectability of Tegra DT support. However, > linux-next doesn't yet have entirely useful Tegra DT support; some stuff > from Grant's devicetree/next hasn't been pushed into linux-next yet. If > we don't care about bisectability, I can remove a couple commits and > possibly squash some others. > > * The approach taken here is to have a custom semantic SoC-specific > binding for each the gpio and pinmux drivers. Other alternatives > suggested included: > > 1) A generic "list of register writes" to be performed at boot. This has > the advantage of reusability across different SoCs. However, this > approach isn't semantic, and requires detailed knowledge of pinmux > registers and potentially fiddly calculations when constructing the > device tree. > > 2) The ability to define disabled child nodes of the pinmux controller > that are not processed by tegra_pinmux_probe_dt(). Other devices may > refer to those using phandles, and later enable/disable them, thus > representing dynamic pinmuxing in the device tree. I wasn't convinced > whether we should represent dynamic pinmuxing using phandles. > > I discussed in more detail why I prefer the current proposal in various > email threads. > Glad to see the second soc specific pinmux binding besides the one below for i.mx. http://permalink.gmane.org/gmane.linux.drivers.devicetree/6962 > * tegra_pinmux_probe_dt() enumerates all legal pingroup names, and searches > for a pinmux controller subnode of that name, then processes each one > that is found. An alternative that some may prefer would be to enumerate > each child node of the pinmux controller, and have each node contain an > explicit pingroup name property instead. Does anyone have any preference > here? I suppose the latter option would obviate the need to add > of_find_child_node_by_name(). > I agree with Jamie that the latter option seems better/simper. > Thanks for reading! > > Stephen Warren (12): > dt: Add of_find_child_node_by_name() > arm/tegra: Prep boards for gpio/pinmux conversion to pdevs > arm/tegra: Avoid duplicate gpio/pinmux devices with dt > arm/tegra: board-dt: Add AUXDATA for tegra-gpio and tegra-pinmux > arm/dt: Tegra: Add nvidia,gpios property to GPIO controller > arm/dt: Tegra: Add pinmux node > gpio/tegra: Convert to a platform device > gpio/tegra: Add device tree support > arm/tegra: Convert pinmux driver to a platform device > arm/tegra: Add device tree support to pinmux driver > arm/tegra: board-dt: Remove dependency on non-dt pinmux functions > arm/tegra: Remove temporary gpio/pinmux registration workaround > > arch/arm/boot/dts/tegra-harmony.dts | 479 ++++++++++++++++++++++++++ > arch/arm/boot/dts/tegra-seaboard.dts | 409 ++++++++++++++++++++++ > arch/arm/boot/dts/tegra20.dtsi | 5 + > arch/arm/mach-tegra/Makefile | 1 - > arch/arm/mach-tegra/board-dt.c | 12 +- > arch/arm/mach-tegra/board-harmony-pinmux.c | 8 + > arch/arm/mach-tegra/board-paz00-pinmux.c | 8 + > arch/arm/mach-tegra/board-seaboard-pinmux.c | 9 +- > arch/arm/mach-tegra/board-trimslice-pinmux.c | 7 + > arch/arm/mach-tegra/devices.c | 10 + > arch/arm/mach-tegra/devices.h | 2 + > arch/arm/mach-tegra/pinmux.c | 136 ++++++++ > drivers/gpio/gpio-tegra.c | 56 +++- > drivers/of/base.c | 18 + > include/linux/of.h | 2 + > 15 files changed, 1138 insertions(+), 24 deletions(-) > Generally, you need to document the bindings you come with in Documentation/devicetree/bindings/ -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-tegra" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
