Delete about 700 used only once symbols.
I used the following script to clean up the file,
iomux-mx51.h.
cp iomux-mx51.h iomux-mx51.h.cpy
sed -n iomux-mx51.h.cpy \
-e 's/#define[ \x09]\+\(_MX5[0-9a-zA-Z_]*\)[ \x09]\+\(.\+\)/s@\1@\2 at g/p' >t.tmp
sed iomux-mx51.h.cpy \
-e '/define[ \x09]\+_MX5/d' \
-f t.tmp \
-e 's/,[ \x09]*\([^,]\+\)/, \1/g' \
-e 's/, 0)[ \x09]*|[ \x09]*MUX_PAD_CTRL(/, /' \
-e 's/(IOMUX_PAD(\(.*\)))/IOMUX_PAD(\1)/' \
-e 's/0x\([0-9a-fA-F]\{2\}\)[ \x09]*,/0x0\1,/' \
-e 's/0x0\([0-9a-fA-F]\{3\}\)[ \x09]*,/0x\1,/' \
-e '/#include <mach\/iomux-v3.h/ a#define __NA_\x090x000\n' \
-e 's/0x[0]\{1,3\},/__NA_,/' \
-e 's/#define[ \x09]\+\(MX5[0-9a-zA-Z_]*\)[ \x09]\+\(IOMUX_PAD.\+\)/#define \1\x09\2/' \
-e 's/\(#define MX5[^\x09]\{5,12\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\x09\x09\x09\2/' \
-e 's/\(#define MX5[^\x09]\{13,20\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\x09\x09\2/' \
-e 's/\(#define MX5[^\x09]\{21,28\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\x09\2/' \
-e 's/\(#define MX5[^\x09]\{29,36\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\2/' \
-e 's/\(#define MX5[^\x09]\{45,\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\\\n\x09\x09\x09\x09\x09\x09\2/' \
-e 's/, IOMUX_CONFIG_SION,/, 0 | IOMUX_CONFIG_SION,/' \
-e 's/\((0x[0-9a-fA-F]*, 0x[0-9a-fA-F]*, \)0x0\([0-9a-fA-F]\{2\},\)/\10x\2/' >iomux-mx51.h
Signed-off-by: Troy Kisky <redacted>
---
arch/arm/plat-mxc/include/mach/iomux-mx51.h | 2270 +++++++++------------------
1 files changed, 758 insertions(+), 1512 deletions(-)
I didn't include the entire patch because it is too big for the mailing list.
Beside, you'll probably want to run the above script last thing before sending a pull
for a clean up branch to avoid conflicts.
Delete about 1,000 symbols used only once
I used the following script to clean up the file.
cp iomux-mx53.h iomux-mx53.h.cpy
sed -n iomux-mx53.h.cpy \
-e 's/#define[ \x09]\+\(_MX5[0-9a-zA-Z_]*\)[ \x09]\+\(.\+\)/s@\1@\2 at g/p' >t.tmp
sed iomux-mx53.h.cpy \
-e '/define[ \x09]\+_MX5/d' \
-f t.tmp \
-e 's/,[ \x09]*\([^,]\+\)/, \1/g' \
-e 's/, 0)[ \x09]*|[ \x09]*MUX_PAD_CTRL(/, /' \
-e 's/(IOMUX_PAD(\(.*\)))/IOMUX_PAD(\1)/' \
-e 's/0x\([0-9a-fA-F]\{2\}\)[ \x09]*,/0x0\1,/' \
-e 's/NON_PAD_I/__NA_/' \
-e 's/0x0,/__NA_,/' \
-e 's/#define[ \x09]\+\(MX5[0-9a-zA-Z_]*\)[ \x09]\+\(IOMUX_PAD.\+\)/#define \1\x09\2/' \
-e 's/\(#define MX5[^\x09]\{5,12\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\x09\x09\x09\x09\2/' \
-e 's/\(#define MX5[^\x09]\{13,20\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\x09\x09\x09\2/' \
-e 's/\(#define MX5[^\x09]\{21,28\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\x09\x09\2/' \
-e 's/\(#define MX5[^\x09]\{29,36\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\x09\2/' \
-e 's/\(#define MX5[^\x09]\{45,\}\)\x09\(IOMUX_PAD.\+\)/\1\x09\\\n\x09\x09\x09\x09\x09\x09\x09\2/' \
-e 's/, IOMUX_CONFIG_SION,/, 0 | IOMUX_CONFIG_SION,/' >iomux-mx53.h
Signed-off-by: Troy Kisky <redacted>
---
arch/arm/plat-mxc/include/mach/iomux-mx53.h | 3527 +++++++++------------------
1 files changed, 1184 insertions(+), 2343 deletions(-)
I didn't include the entire patch because it is too big for the mailing list.
Beside, you'll probably want to run the above script last thing before sending a pull
for a clean up branch to avoid conflicts.
@@ -23,7 +23,7 @@/* These 2 defines are for pins that may not have a mux register, but could*haveapadsettingregister,andvice-versa.*/-#define NON_PAD_I 0x00+#define __NA_ 0x00#define MX53_UART_PAD_CTRL (PAD_CTL_PKE | PAD_CTL_PUE | \PAD_CTL_DSE_HIGH|PAD_CTL_SRE_FAST|PAD_CTL_HYS)
You have to protect cfg with ().
Otherwise I like the idea.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
Do we really need this __NA_ define? Can?t we continue just writing 0
in the macro?
Regards,
Fabio Estevam
First, welcome back from vacation and thanks for taking the time to review.
I like the __NA_ macro for a couple of reasons.
1. It keeps the macro arguments aligned from line to line. 5 character
name so that a line that uses 0xnnn instead, usually has its arguments
aligned with a line that uses __NA_.
2. It makes it more obvious that this field is "not applicable" to this
setting.
3. NON_PAD_I is replaced with __NA_ as it has the same use, and keeps
alignment.
But if Sascha agrees with you, I will change it as it is not really
important to me. Sascha, if you do agree, please also tell me what you
want done with NON_PAD_I.
Thanks
Troy
Do we really need this __NA_ define? Can?t we continue just writing 0
in the macro?
Regards,
Fabio Estevam
First, welcome back from vacation and thanks for taking the time to review.
I like the __NA_ macro for a couple of reasons.
1. It keeps the macro arguments aligned from line to line. 5 character
name so that a line that uses 0xnnn instead, usually has its arguments
aligned with a line that uses __NA_.
2. It makes it more obvious that this field is "not applicable" to this
setting.
3. NON_PAD_I is replaced with __NA_ as it has the same use, and keeps
alignment.
I'm fine with the __NA_ macro.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |