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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
