Re: [U-Boot] [PATCH RFC] imx: add multi-architecture README
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.
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:
- Whether to turn declarations in mx6q_pins.h/mx6dl_pins.h into macros
- Whether to double-include the same in mx6-pins.h
- 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
participants (1)
-
Eric Nelson