linux-kernel - Re: [RFC PATCH 00/12] arm/tegra: Initialize GPIO & pinmux from DT

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sat, 13 Aug 2011 21:08:59 +0800
From:	Shawn Guo <shawn.guo@...escale.com>
To:	Stephen Warren <swarren@...dia.com>
CC:	Grant Likely <grant.likely@...retlab.ca>,
	Colin Cross <ccross@...roid.com>,
	Erik Gilling <konkers@...roid.com>,
	Olof Johansson <olof@...om.net>,
	Russell King <linux@....linux.org.uk>,
	<devicetree-discuss@...ts.ozlabs.org>,
	<linux-kernel@...r.kernel.org>, <linux-tegra@...r.kernel.org>,
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [RFC PATCH 00/12] arm/tegra: Initialize GPIO & pinmux from DT

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/