From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Nelson Date: Wed, 13 Nov 2013 14:04:50 -0700 Subject: [U-Boot] [PATCH V2 0/5] i.MX6 (DQ/DLS): consolidate mux and pad names In-Reply-To: References: <1383609655-24185-1-git-send-email-eric.nelson@boundarydevices.com> <5283481E.4020209@denx.de> <5283B589.2000805@boundarydevices.com> <5283BD63.1010000@boundarydevices.com> Message-ID: <5283E972.3070806@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 Hi Fabio, On 11/13/2013 01:07 PM, Fabio Estevam wrote: > Hi Eric, > > On Wed, Nov 13, 2013 at 3:56 PM, Eric Nelson > wrote: > >> In the RFC e-mail change regarding README.imx6-something, >> I proposed that we replace the pad declaration form >> currently in use: >> >> enum { >> MX6_PAD_SD3_DAT2__USDHC3_DAT2 = IOMUX_PAD(...) >> }; >> >> with macros of this form so that they can be pre-pended >> with MX6Q_ and MX6DL_ when we need both in an image >> (SPL?) that can run on either variant of processor. >> >> MX6_PAD_DECL(SD3_DAT2__USDHC3_DAT2, ...) > > I thinks this macro approach should work fine. Do we > see any objections? > Not so far. I think everybody would rather not have so much macro-fu, but the only real alternatives are either lots of duplication or an immediate "big bang" switch to have all boards support all CPU variants. Since we have some boards that are expected to be Solo-Only or Quad-Only forever, we'd like to retain the single-variant build without explicitly listing the pads as MX6Q_ or MX6DL_. >> >> If we do this, then lining up the columns based on the >> first form doesn't make much sense. > > Understood it now. Thanks for clarifying. > Cool. I'll re-base the macro patch I have floating here and submit it officially. It's mostly mechanical and easy to validate. I'll also submit an updated patch for README.imx6, but will keep it separate because I expect more suggestions regarding the wording. Regards, Eric