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