On Tue, Mar 5, 2013 at 10:03 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/05/2013 08:28 AM, Tom Warren wrote:
On Mon, Mar 4, 2013 at 5:28 PM, Stephen Warren swarren@wwwdotorg.org wrote:
On 03/04/2013 04:11 PM, Tom Warren wrote:
On Wed, Feb 27, 2013 at 11:08 AM, Stephen Warren swarren@wwwdotorg.org wrote:
On 02/27/2013 09:59 AM, Tom Warren wrote:
On Tue, Feb 26, 2013 at 4:26 PM, Stephen Warren swarren@wwwdotorg.org wrote:
...
For the pinmux registers, I think they should be programmed by the pinmux driver at the same time as the rest of the pinmux is programmed.
Technically, they're not pinmux registers (PINMUX_AUX_ space), but GP regs (APB_MISC_GP_ space). Since the pinmux _code_ (no pinmux driver is used in Tegra U-Boot)
The distinction isn't relevant for this discussion. Anyway, there really is a driver...
I must be dense. Please point it out to me. It is relevant, because you've asked to put the GP register writes in the pinmux driver.
[swarren@swarren-lx1 u-boot]$ find|grep pinmux|grep tegra|grep \.c$ ./arch/arm/cpu/tegra30-common/pinmux.c ./arch/arm/cpu/tegra114-common/pinmux.c ./arch/arm/cpu/tegra20-common/pinmux.c
OK, there's a semantic chasm here. This is not a 'driver' in my mind - it's just the pinmux code to set the bits in the PINMUX_AUX regs, and over half of it's tables & structs. Again, T30 reads in a few tables of pinmux/pingroup settings, and slams 'em out to the regs using the functions in pinmux.c (set_tristate, set_pullupdown, etc.).
So would you be satisfied if I removed the GP sdio pad cfg writes from the common board-level code (common/board.c) and put them in a function that's called during pinmux_init(), early on in board_early_init_f()? That'll preclude being able to parse the mmc_id to see if I need to write SDIO1CFG or SDIO3CFG, so I'll have to slam 'em both, but that should be OK.