ARM: OMAP: mux: add config for 16xx SPI pins
Subsystems (3)
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
@@ -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
@@ -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,
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.
Tony Lindgren
reviewerQuoted 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