[U-Boot] [RFC PATCH 4/3] i.MX6DQ/DLS: remove unused pad declarations

[Eric Nelson <eric.nelson@boundarydevices.com>]

Hi all,

I'm just following up on this patch.

On 09/18/2013 12:18 PM, Eric Nelson wrote:
 > Hi Otavio,
 >
 > On 09/18/2013 11:27 AM, Otavio Salvador wrote:
 >> On Wed, Sep 18, 2013 at 3:14 PM, Eric Nelson
 >> <eric.nelson@boundarydevices.com> wrote:
 >>> That's not a typo. I really did intend this to be an add-on to the
 >>> series described here:
 >>>
 >>>          http://lists.denx.de/pipermail/u-boot/2013-September/#162774
 >>>
 >>> This patch assumes that the answer about what to do with pads that
 >>> aren't in the Linux tree is to delete them from U-Boot.
 >>>
 >>> No boards are currently referring to them, and the names are still
 >>> a jumble of mis-matched abbreviations.
 >>>
 >>> After applying this patch, there are still over 200 differences in
 >>> pad declarations between the i.MX6D/Q and the i.MX6DL/S header files,
 >>> but the differences may all be meaningful.
 >>>
 >>> Specifically:
 >>>
 >>> 142  have names referring to IPU2 on i.MX6D/Q and LCDIF on i.MX6DL/S
 >>>       It's not clear to me whether these can be used in the same
 >>>       manner
 >>>       on both variants.
 >>>   50  refer to the EPDC signals only available on i.MX6DL/S
 >>>    8  refer to ACLK_FREERUN, and it's not clear from the
 >>>       documentation
 >>>       whether this exists on i.MX6 D/Q
 >>>   15  refer to the ECSPI5 component, only available on i.MX6 D/Q
 >>>    8  refer to the I2C4 component, only available on i.MX6 DL/S
 >>>
 >>> These pad declarations seem to have made it into the Linux kernel
 >>> for i.MX6DL and should be added to i.MX6DQ:
 >>>
 >>>   38  refer to IPU1_CSI1, which is available on both variants and
 >>>       should be added to the i.MX6D/Q declarations in Linux and >>> 
       U-Boot
 >>>    4  refer to USBOH3 functions that should be added to i.MX6 D/Q
 >>>       in Linux and U-Boot
 >>>
 >>> Signed-off-by: Eric Nelson <eric.nelson@boundarydevices.com>
 >>
 >> Personally I think this is the way to go.
 >>
 >
 > I guess I didn't really weigh in, but I'm in favor of 'ding now,
 > add later if needed'.
 >

I don't think Stefano, Shawn, or Fabio ever weighed in on whether to
     - remove them all, or
     - review and remove or consolidate names, or
     - leave them alone

Tapani requested that the MMDC_DRAM pads be kept, but I don't see
a response to the comment that these are likely to be configured in
DCD data at least for some boards, so the structs won't be useful
and #defines would do the trick.

Please let me know your thoughts.

Regards,


Eric