From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Tue, 24 Sep 2013 06:49:00 -0700 Subject: [U-Boot] [RFC PATCH 0/3] i.MX6 (DQ/DLS): consolidate mux and pad names In-Reply-To: <20130924173638.3f6c897c@triceratops> References: <1379366805-22166-1-git-send-email-eric.nelson@boundarydevices.com> <523CE6E2.6030204@boundarydevices.com> <20130924173638.3f6c897c@triceratops> Message-ID: <5241984C.2070407@boundarydevices.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Thanks Tapani, On 09/24/2013 02:36 AM, Tapani Utriainen wrote: > On Fri, 20 Sep 2013 17:22:58 -0700 > Eric Nelson wrote: > >> On 09/16/2013 02:26 PM, Eric Nelson wrote: >>> This patch set begins the process of consolidating mux and pad >>> declarations for the i.MX6 Dual/Quad and Dual-Lite/Solo processor >>> variants. >>> >>> Patch 1 replaces the mux/pad names with their equivalents from >>> the Linux kernel (from linux-next). This >>> Patch 2 removes a set of completely useless pad declarations >>> Patch 3 adds a number of registers that are defined in the Linux >>> kernel and in the DLS variant, but not in the DQ. >>> >>> After this patch, there are still more than 400 pad differences >>> between the two variants. These represent mux/pad declarations >>> that are not present in the Linux kernel. A combined list of these >>> is available at: >>> http://linode.boundarydevices.com/u-boot-pads.lst >>> >>> The majority of these are diagnostic settings and a large number >>> of these appear unlikely to ever be used. The primary reason this >>> is being sent as an RFC is to get feedback about what should be >>> done with them: >>> 1. Delete them all >>> 2. Walk through them and delete some and add others >>> 3. Add them all and consolidate the names. >>> >> >> Shawn and Fabio: I'd like to find out what you think about >> how to handle the pads that aren't in the kernel tree. >> >> Please advise, >> > > Just adding two (more) cents: > > At least padconfig definitions like > > DRAM_A0__MMDC_DRAM_A_0, > DRAM_A1__MMDC_DRAM_A_1, > DRAM_A2__MMDC_DRAM_A_2, > DRAM_A3__MMDC_DRAM_A_3, > DRAM_A4__MMDC_DRAM_A_4, > DRAM_A5__MMDC_DRAM_A_5, > DRAM_A6__MMDC_DRAM_A_6, > DRAM_A7__MMDC_DRAM_A_7, > DRAM_A8__MMDC_DRAM_A_8, > DRAM_A9__MMDC_DRAM_A_9 > > etc. might be useful as soon as memory is set up programmatically > rather than using DCD tables. > Some of these pads are already defined in mx6q-ddr.h/mx6dl-ddr.h: http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx6/mx6q-ddr.h;h=0aa94cffe5177bf89fbfa59cd2bc423285a96d64;hb=HEAD Oddly, the ones you refer to aren't. > Hence, my suggestion is not to delete them all. At least leave the > MMDC padconfigs in. > Do you think these registers will be easier to work with via the IOMUX_PAD macro or as straight macros? If they're straight-up #defines, we can use them in assembly and .cfg files. Please advise, Eric