From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Warren Date: Tue, 5 Mar 2013 10:21:21 -0700 Subject: [U-Boot] [PATCH 3/5] Tegra30: MMC: Add SD bus power-rail and SDMMC pad init routines In-Reply-To: <5136254C.6020604@wwwdotorg.org> References: <1361911596-16518-1-git-send-email-twarren@nvidia.com> <1361911596-16518-4-git-send-email-twarren@nvidia.com> <512D4493.6060502@wwwdotorg.org> <512E4B94.8060302@wwwdotorg.org> <51353C13.8010106@wwwdotorg.org> <5136254C.6020604@wwwdotorg.org> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Tue, Mar 5, 2013 at 10:03 AM, Stephen Warren wrote: > On 03/05/2013 08:28 AM, Tom Warren wrote: >> On Mon, Mar 4, 2013 at 5:28 PM, Stephen Warren wrote: >>> On 03/04/2013 04:11 PM, Tom Warren wrote: >>>> On Wed, Feb 27, 2013 at 11:08 AM, Stephen Warren wrote: >>>>> On 02/27/2013 09:59 AM, Tom Warren wrote: >>>>>> On Tue, Feb 26, 2013 at 4:26 PM, Stephen Warren 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 at 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.