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.nel...@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.nel...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
