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

[Eric Nelson]

Hello all,

On 11/11/2013 12:18 PM, Eric Nelson wrote:
>
 > <snip>
>
> 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.
>
> <snip>
 >
> 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.
>

If you've followed along with all of this, there's another alternative
to consider, which is the approach we've used in our Linux 3.0.35
kernels.

If you look at pads-mx6_nitrogen6x.h in our 3.0.35 kernel tree:
	http://bit.ly/1eECBxm

You'll see something different from what I proposed for
"boardname-pads.h".

Instead of simply containing a series of macro calls, this file
contains complete declarations with the names of each variable
wrapped with the macro MX6NAME():

	static iomux_v3_cfg_t MX6NAME(csi0_sensor_pads)[] = {

MX6NAME is defined based on whether the "FOR_DL_SOLO" macro
is defined.

	#ifdef FOR_DL_SOLO
	#define MX6(a) MX6DL_##a
	#define MX6PAD(a) MX6DL_PAD_##a
	#define MX6NAME(a) mx6dl_solo_##a
	#else
	#define MX6(a) MX6Q_##a
	#define MX6PAD(a) MX6Q_PAD_##a
	#define MX6NAME(a) mx6q_##a
	#endif


And the board file includes the pad header twice:
	http://bit.ly/1dYWpbU

This approach requires a bit more effort to understand, but almost
completely isolates the body of the code from the question of
whether the build is for a single processor variant or supports
multiple variants.

It also addresses the question of what to do with the i2c
and ethernet pad declarations above.

Using this approach, they move into "boardname-pads.h".

Regards,


Eric