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

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

[Eric Nelson]

Thanks Shawn,

I noticed that Otavio's e-mail had a bad reference for the list,
and we've veered off the original topic.

On 09/20/2013 01:44 AM, Shawn Guo wrote:
> On Thu, Sep 19, 2013 at 07:08:35AM -0700, Eric Nelson wrote:
>> There are currently 8 pads defined in U-Boot that aren't defined
>> in the Linux kernel sources:
>>
>> 	SD2_CLK__USDHC2_CLK
>> 	SD2_CMD__USDHC2_CMD
>> 	SD2_DAT0__USDHC2_DAT0
>> 	SD2_DAT1__USDHC2_DAT1
>> 	SD2_DAT2__USDHC2_DAT2
>> 	SD2_DAT3__USDHC2_DAT3
>
> They are the following ones in kernel.
>
> 	MX6QDL_PAD_SD2_CLK__SD2_CLK
> 	MX6QDL_PAD_SD2_CMD__SD2_CMD
> 	MX6QDL_PAD_SD2_DAT0__SD2_DATA0
> 	MX6QDL_PAD_SD2_DAT1__SD2_DATA1
> 	MX6QDL_PAD_SD2_DAT2__SD2_DATA2
> 	MX6QDL_PAD_SD2_DAT3__SD2_DATA3
>
This comment was about SL, not DQ or DLS.

And my comments were wrong.

I used a tool to do a quick comparison and didn't check my work.

The reality is that U-Boot's pad declarations for SL are
almost non-existent:
	http://git.denx.de/u-boot.git/?p=u-boot.git;a=blob;f=arch/arm/include/asm/arch-mx6/mx6sl_pins.h;h=b39a354f39568b11ea010ae08485ded610b00f1a;hb=HEAD

The 8 declarations that are present all have name mis-matches
with the Linux kernel (USDHC2 vs. SD2, UART1_RXD vs. UART1_RX_DATA).

> They are named per IOMUXC registers description in reference manual.
>
>> 	UART1_RXD__UART1_RXD
>> 	UART1_TXD__UART1_TXD
>
> Yes, kernel does not define them.  That's because the reference manual
> does not define them.  The macros in kernel are generated from reference
> manual data source.
>
Cool. Thanks for your work on the kernel side. Things there
are in much better shape than in the U-Boot source tree.

Regards,


Eric

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

[Eric Nelson]

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

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

[Fabio Estevam]

[Re-sending to the list as the original address was incorrect]

On Thu, Oct 10, 2013 at 12:34 PM, Fabio Estevam <festevam@gmail.com> wrote:
> On Thu, Oct 10, 2013 at 12:29 PM, Eric Nelson
> <eric.nelson@boundarydevices.com> wrote:
>
>>> Personally, I think it is better to remove everything that is not used,
>>> and add it later when it is really needed.
>>>
>> It seems like we mostly have consensus here.
>>
>> Fabio/Shawn/Tapani, can we get a head nod?
>
> Sounds good for me as well.
>
> Regards,
>
> Fabio Estevam

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

[Shawn Guo]

On Thu, Oct 10, 2013 at 12:35:13PM -0300, Fabio Estevam wrote:
> [Re-sending to the list as the original address was incorrect]
> 
> On Thu, Oct 10, 2013 at 12:34 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > On Thu, Oct 10, 2013 at 12:29 PM, Eric Nelson
> > <eric.nelson@boundarydevices.com> wrote:
> >
> >>> Personally, I think it is better to remove everything that is not used,
> >>> and add it later when it is really needed.
> >>>
> >> It seems like we mostly have consensus here.
> >>
> >> Fabio/Shawn/Tapani, can we get a head nod?

Agree.

Shawn

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

[Eric Nelson]

On 10/10/2013 07:10 PM, Shawn Guo wrote:
> On Thu, Oct 10, 2013 at 12:35:13PM -0300, Fabio Estevam wrote:
>> [Re-sending to the list as the original address was incorrect]
>>
>> On Thu, Oct 10, 2013 at 12:34 PM, Fabio Estevam <festevam@gmail.com> wrote:
>>> On Thu, Oct 10, 2013 at 12:29 PM, Eric Nelson
>>> <eric.nelson@boundarydevices.com> wrote:
>>>
>>>>> Personally, I think it is better to remove everything that is not used,
>>>>> and add it later when it is really needed.
>>>>>
>>>> It seems like we mostly have consensus here.
>>>>
>>>> Fabio/Shawn/Tapani, can we get a head nod?
>

Thanks Shawn (and Fabio).

I'll work up a cleaner patch-set without the RFC.