On 09/01/2013 11:21 AM, Eric Nelson wrote:
Hi Stefano,
On 09/01/2013 10:08 AM, Stefano Babic wrote:
Hi Otavio,
On 31/08/2013 23:55, Otavio Salvador wrote:
On Sat, Aug 31, 2013 at 6:38 PM, Eric Nelson
<[email protected]> wrote:
The primary reason this patch set is sent as an RFC is the overall
feeling that there must be a better way and the fact that none of
these pads is actually used by any current code in U-Boot and the
vast majority of these changes will never do so (OBSERVABILITY
pads, for instance).
I think it is better to have all the pads there so we don't need to
always recheck if the pad is known or not and make changes on this all
the time.
I am not sure I have understood your sentence: what do you mean with
"there" ? Are you suggesting another place for the pads ?
Note that not all of the defined pad options are currently present
in these headers, including some that are being used by some down-stream
boards:
https://github.com/boundarydevices/u-boot-imx6/commit/b9a39fd1756ab95554f4c49b9cf1cde73a9dbda9
I'm taking a look at the XML files distributed as a part of the
IOMux tool to see if they can be used to produce a more complete set.
I finally took some time to walk through the XML files that are a
part of the IOMux tool (scraped through "strings").
They seem to be more complete than any of the other canonical
sources, but only slightly so.
AFAIK, there are six main repositories of this pin-mux declarations.
-- Freescale's 2009.08 U-Boot has files mx6_pins.h for Dual/Quad,
and mx6dl_pins.h for Solo/Dual-Lite:
http://git.freescale.com/git/cgit.cgi/imx/uboot-imx.git/tree/include/asm-arm/arch-mx6?h=imx_v2009.08_3.0.35_4.1.0
-- Main-line U-Boot has files mx6q_pins.h for Quad/Dual and mx6dl_pins.h
for Dual-Lite/Solo:
http://git.denx.de/u-boot.git/?p=u-boot.git;a=tree;f=arch/arm/include/asm/arch-mx6;h=bec3aaf4de0813965b19bb6cf8a43b1c78f5e7f1;hb=HEAD
-- The main-line Linux kernel has files imx6q-pinfunc.h for Quad/Dual
and imx6dl-pinfunc.h for Dual-Lite/Solo:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts?id=refs/tags/v3.11
-- Freescale's 3.5.7 tree appears to share the headers with main-line.
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/boot/dts?h=imx_3.5.7_1.0.0_alpha
-- Freescale's 3.0.35 tree has files iomux-mx6q.h for Quad/Dual and
iomux-mx6dl.h for Dual-Lite/Solo:
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/tree/arch/arm/plat-mxc/include/mach
Freescale's IOMux tool has two embedded XML files that describe all
of the pads, mux and pad registers :
https://www.freescale.com/webapp/sps/download/license.jsp?colCode=IMX6_IOMUX_TOOL&appType=file1
The two U-Boot trees and the 3.0.35 Linux kernel appear to have
the same origins, and each seem to have extra declarations for
things that are unlikely to be used or are completely useless
like this declaration:
MX6_PAD_DRAM_D40__MMDC_DRAM_D_40
= IOMUX_PAD(NO_PAD_I, NO_MUX_I, 0, 0x0000, 0, 0),
If a pad has no mux or pad register, I don't think we need a
declaration.
The main-line Linux kernel appears to have been generated from
the IOMux tool (or a similar ancestor), though there are a number
of subtle differences, especially in the use of the "_B" suffix
on some declarations.
Comparing the two (IOMux and main-line) showed that some
pin muxing options aren't represented in main-line yet
and there are some declarations in main-line that I'm not
sure how to produce from the XML (those involving input-select
registers).
Shawn appears to have implemented things in a clean way
for the main-line kernel:
https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/arch/arm/boot/dts/imx6q-pinfunc.h?id=c56009b2f6134e5943a03cf26e4d7fce9745d56b
I recommend that we simply adopt the main-line kernel naming,
and work up a couple of initial patches:
1. simply replace all of the names with their main-line
equivalent, and
2. remove all of the unused (NO_PAD_I,NO_MUX_I) pad
declarations
Each of these should be easy to inspect for correctness
and then we can focus on how to handle the differences
and produce binaries that support both variants.
Let me know your thoughts.
Regards,
Eric
_______________________________________________
U-Boot mailing list
[email protected]
http://lists.denx.de/mailman/listinfo/u-boot
