Thread (32 messages) 32 messages, 5 authors, 2011-11-23

[PATCH 06/10] arm/tegra: prepare pinmux code for multiple tegra variants

From: pdeschrijver@nvidia.com (Peter De Schrijver)
Date: 2011-11-23 03:22:54
Also in: linux-devicetree, linux-tegra, lkml

On Tue, Nov 22, 2011 at 08:01:46PM +0100, Olof Johansson wrote:
On Mon, Nov 21, 2011 at 04:29:19PM +0200, Peter De Schrijver wrote:
quoted
On Fri, Nov 18, 2011 at 10:41:16PM +0100, Olof Johansson wrote:
quoted
On Thu, Nov 17, 2011 at 06:19:20PM +0200, Peter De Schrijver wrote:
quoted
This patch modifies the pinmux code to be useable for multiple tegra variants.
Some tegra20 specific constants will be replaced by variables which will be
initialized to the appropriate value at runtime.

Signed-off-by: Peter De Schrijver <pdeschrijver@nvidia.com>
---
 arch/arm/mach-tegra/board-harmony-pcie.c     |    1 +
 arch/arm/mach-tegra/board-harmony-pinmux.c   |    1 +
 arch/arm/mach-tegra/board-paz00-pinmux.c     |    1 +
 arch/arm/mach-tegra/board-trimslice-pinmux.c |    1 +
 arch/arm/mach-tegra/include/mach/pinmux.h    |   25 +++----
 arch/arm/mach-tegra/pinmux-tegra20-tables.c  |   15 +++-
 arch/arm/mach-tegra/pinmux.c                 |  105 ++++++++++++++-----------
 7 files changed, 86 insertions(+), 63 deletions(-)
diff --git a/arch/arm/mach-tegra/board-harmony-pcie.c b/arch/arm/mach-tegra/board-harmony-pcie.c
index 6db7d69..bd402d0 100644
--- a/arch/arm/mach-tegra/board-harmony-pcie.c
+++ b/arch/arm/mach-tegra/board-harmony-pcie.c
@@ -23,6 +23,7 @@
 #include <asm/mach-types.h>

 #include <mach/pinmux.h>
+#include <mach/pinmux-tegra20.h>
Boards shouldn't have to include this. The idea is that you should only
have to do board code against the pinmux.h interface, which internally
abstracts it for tegra 20 vs tegra 30.
The pinmux naming is still SoC specific. Unless we move this to devicetree
(which should be part of a different patchset), I don't see how we can solve
this, except by renaming all the pingroups. That would cause a lot more
changes though.
If the pinmux naming and numbering is unique per SoC then sharing
namespace for them could be a source of confusion. If we need to keep
them around much longer, then doing that rename would be a good idea. But
we can do that separately from this change. So the include change is ok
for now.

My other comments about the code changes still stands though, so please
address those.
I'm working on those. I'm on a businesstrip now, so things might go a bit
slower.

Cheers,

Peter.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help