[U-Boot] [PATCH RFC] imx: add multi-architecture README

[Eric Nelson]

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 at 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.