[RFC PATCH 00/12] arm/tegra: Initialize GPIO & pinmux from DT
Shawn Guo
shawn.guo at freescale.com
Sat Aug 13 09:08:59 EDT 2011
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
More information about the linux-arm-kernel
mailing list