Skip to contentSkip to conversation

ARM: OMAP: mux: add config for 16xx SPI pins

PATCH In review Mark Howell 2 participants 3 messages Jul 26, 2006 – Aug 30, 2006

Subsystems (3)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 ARM: OMAP: mux: add config for 16xx SPI pins

This patch adds pin mux info for the SPI master/slave interface on OMAP16xx. Data from OMAP 1611/1612 TRM and errata. Works for me on my 1611/H2 with current git kernel.

-----

arch/arm/mach-omap1/mux.c +0 -0
diff -ruNp -X linux-omap/Documentation/dontdiff linux-omap/arch/arm/mach-omap1/mux.c dev-linux-omap/arch/arm/mach-omap1/mux.c
@@ -200,6 +200,17 @@ MUX_CFG("N14_1610_UWIRE_CS0",	 8,    9, MUX_CFG("P15_1610_UWIRE_CS3",	 8,   12,    1,	  1,  22,   0,	  1,	 1,  1)

MUX_CFG("N15_1610_UWIRE_CS1", 7, 18, 2, 1, 14, 0, NA, 0, 1)

+/* OMAP-1610 SPI */

+MUX_CFG("U19_1610_SPIF_SCK",	 7,    21,   6,	  1,  15,   0,	  1,	 1,  1)
+MUX_CFG("U18_1610_SPIF_DIN",	 8,    0,    6,	  1,  18,   1,	  1,	 0,  1)
+MUX_CFG("P20_1610_SPIF_DIN",	 6,    27,   4,   1,   7,   1,    1,     0,  1)
+MUX_CFG("W21_1610_SPIF_DOUT",	 8,    3,    6,	  1,  19,   0,	  1,	 0,  1)
+MUX_CFG("R18_1610_SPIF_DOUT",	 7,    9,    3,	  1,  11,   0,	  1,	 0,  1)
+MUX_CFG("N14_1610_SPIF_CS0",	 8,    9,    6,	  1,  21,   0,	  1,	 1,  1)
+MUX_CFG("N15_1610_SPIF_CS1",	 7,    18,   6,	  1,  14,   0,	  1,	 1,  1)
+MUX_CFG("T19_1610_SPIF_CS2",	 7,    15,   4,	  1,  13,   0,	  1,	 1,  1)
+MUX_CFG("P15_1610_SPIF_CS3",	 8,    12,   3,	  1,  22,   0,	  1,	 1,  1)
+
/* OMAP-1610 Flash */
MUX_CFG("L3_1610_FLASH_CS2B_OE",10,    6,    1,	 NA,   0,   0,	 NA,	 0,  1)
MUX_CFG("M8_1610_FLASH_CS2B_WE",10,    3,    1,	 NA,   0,   0,	 NA,	 0,  1)
include/asm-arm/arch-omap/mux.h +0 -0
diff -ruNp -X linux-omap/Documentation/dontdiff linux-omap/include/asm-arm/arch-omap/mux.h dev-linux-omap/include/asm-arm/arch-omap/mux.h
@@ -320,6 +320,17 @@ enum omap1xxx_index {
	P15_1610_UWIRE_CS3,
	N15_1610_UWIRE_CS1,

+ /* OMAP-1610 SPI */
+ U19_1610_SPIF_SCK,
+ U18_1610_SPIF_DIN,
+ P20_1610_SPIF_DIN,
+ W21_1610_SPIF_DOUT,
+ R18_1610_SPIF_DOUT,
+ N14_1610_SPIF_CS0,
+ N15_1610_SPIF_CS1,
+ T19_1610_SPIF_CS2,
+ P15_1610_SPIF_CS3,
+

	/* OMAP-1610 Flash */
	L3_1610_FLASH_CS2B_OE,
	M8_1610_FLASH_CS2B_WE,
#1 lore raw
Quoted 3 lines · Mark Howell

This patch adds pin mux info for the SPI master/slave interface on OMAP16xx. Data from OMAP 1611/1612 TRM and errata. Works for me on my
1611/H2 with current git kernel.

I have since spent some lab time with a scope and figured out that I
misunderstood the pull-up config bits in the mux definition structure
(they are inverted vs. what is actually written to the pull-up control registers). The patch I posted before works, but it can be better.

I'll post a patch to set better default values for 16xx SPI pin mux after I get a little more lab time. I don't think this is a burning issue for anyone 'cept me, since eons had passed without anyone spec'ing these pins for 16xx SPI anyway :-)

But this brings up a question... there are some other pins where I'm
suspicious of the default pull-up config in mux.c, such as for the
u-wire interface. Won't there be a bit of a power penalty for turning on
pull-up or pull-down when it isn't necessary? Is there some established opinion or practice in this group regarding pin mux pull-up config to which I can refer?

Cheers,

Mark.

reviewer
#2 lore raw
Quoted 10 lines · Mark Howell
Quoted 4 lines · Mark Howell

This patch adds pin mux info for the SPI master/slave interface on OMAP16xx. Data from OMAP 1611/1612 TRM and errata. Works for me on my 1611/H2 with current git kernel.

I have since spent some lab time with a scope and figured out that I misunderstood the pull-up config bits in the mux definition structure (they are inverted vs. what is actually written to the pull-up control registers). The patch I posted before works, but it can be better.

OK

Quoted 11 lines

I'll post a patch to set better default values for 16xx SPI pin mux after I get a little more lab time. I don't think this is a burning issue for anyone 'cept me, since eons had passed without anyone spec'ing these pins for 16xx SPI anyway :-)

But this brings up a question... there are some other pins where I'm suspicious of the default pull-up config in mux.c, such as for the u-wire interface. Won't there be a bit of a power penalty for turning on pull-up or pull-down when it isn't necessary? Is there some established opinion or practice in this group regarding pin mux pull-up config to which I can refer?

But the pull_ena bit is 0 so they are disabled..

Somebody from TI please correct if I'm wrong, but if a device works without pull-up or pull-down they should not be used. And if device pins are not used, the pins should not be floating to save power.

In general, the pin muxing should be done in the bootloader for production boards as it's board specific and static. During driver development and debugging, pin muxing can be done in the kernel to make development easier.

Regards,

Tony