On Fri, 20 Sep 2013 17:22:58 -0700 Eric Nelson eric.nelson@boundarydevices.com 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:
- Delete them all
- Walk through them and delete some and add others
- 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.
Hence, my suggestion is not to delete them all. At least leave the MMDC padconfigs in.
//Tapani