Hi all,
On 11/11/2013 11:42 AM, Eric Nelson wrote:
On 11/11/2013 08:12 AM, Eric Nelson wrote:
On 11/11/2013 05:03 AM, Tapani wrote:
On Sat, 9 Nov 2013 13:12:42 -0700 Eric Nelson eric.nelson@boundarydevices.com wrote:
...
The following is a diff with some updates, and I've attached a complete updated version.
Can you tell me whether this bit is better, worse, similar?
...
+Or since the arrays are guaranteed to be the same size, the somewhat +simpler form: imx_iomux_v3_setup_multiple_pads(
MX6REF(nitrogen_pads),ARRAY_SIZE(MX6REF(nitrogen_pads))
is_cpu_type(MXC_CPU_MX6Q)? mx6q_nitrogen_pads: mx6dl_nitrogen_pads,ARRAY_SIZE(mx6q_nitrogen_pads) );-N.B. This doesn't work, since ARRAY_SIZE can't be passed this kind of -reference...
As mentioned in my original e-mail, I wanted to get some feedback about the most important questions:
1. Whether to turn declarations in mx6q_pins.h/mx6dl_pins.h into macros 2. Whether to double-include the same in mx6-pins.h 3. Whether to define baseline pads (the 90% case) in a header and double-include it, and 4. Whether to macro-fy the memory layout files like 1066mhz_4x128mx16.cfg so they can be used by imximage and gcc.
I also started veering off into policy questions that need the answers to the bits above first.
I did draft some additional notes about the straggling, un-addressed 10% of the pads though, and listed the details below.
Regards,
Eric
--------------------------------------------------------------------- The remaining 10% of references can't be resolved in such a simple way, and require some additional run-time logic.
In general, these are places where the pad configuration changes at run-time, and there are two prominent instances in the code base: ethernet pads and I2C pads.
In the ethernet case, two sets of pad settings are used to first defines the pads as GPIOs during reset of a PHY, and the second configures the pads for use as RGMII pins.
It is possible to use the multiple #include approach for these as well, but there are only six pads for the second configuration, and duplicating them is not very onerous, so it is recommended that the initial settings be placed into "boardname-pads.h" along with the others, and that the second simply be duplicated:
static iomux_v3_cfg_t const mx6q_enet2_pads[] = { MX6Q_PAD_RGMII_RXC__ENET_RGMII_RXC... MX6Q_PAD_RGMII_RD0__ENET_RGMII_RD0... ... }; static iomux_v3_cfg_t const mx6dl_enet2_pads[] = { MX6DL_PAD_RGMII_RXC__ENET_RGMII_RXC... MX6DL_PAD_RGMII_RD0__ENET_RGMII_RD0... ... };
The eth_init() routine can then make a choice at run-time between the two.
The I2C case is a bit different, in that the I2C driver will switch between the I2C and GPIO modes. GPIO mode is used during recovery from I2C bus, and the mux and pad settings are defined in the i2c_pads_info structure:
struct i2c_pads_info i2c_pad_info0 = { .scl = { .i2c_mode = MX6_PAD_EIM_D21__I2C1_SCL | PC, .gpio_mode = MX6_PAD_EIM_D21__GPIO_3_21 | PC, }, .sda = { ...
I'm torn about this one. There are a total of 12 pad references (3 I2C structures with 4 pads per structure) in some board files, and I'm not sure whether the entire structures should be simply declared twice or if some other macro configuration is appropriate.
This is common enough (exists in every i.MX6 board) that we should all be doing it the same way.