AlanZhang

Understanding the configuration and usage of i.MX53 MUXIO pins for a customizing board -blog archive

Discussion created by AlanZhang Employee on Oct 25, 2011
Latest reply on Apr 24, 2012 by jose jose

When Linux kernel entry to startup, the first data block it will execute is MACHINE_START/END where the map_io, init_irq, init_machine, and timer will be initialized to guarantee that these basic parts of Linux kernel work well or prepare low level runtime to support kernel-level APIs such as irq_request() etc. This entry block is usually defined in mx53_xxx.c (xxx stands for board name, such as smd), looking into this file, we can find out there exist a lot of GPIO definitions and IOMUX pins' configuration, platform devices' declarations that will be registered into Kernel, and used by driver later when insmod'ing.

To take a first look on mach-mx5/mx53_smd.c, the macros and mx53_smd_pads[] looks complilcated to a newbies, this article will explain the background behind these coding step by step, so these definitioins could be easy to be handled for a new specific customer's board based on i.MX53.

Step 1: Every customers' design must follow certain specification that can be derived to the top level design in which we can see what interfaces of i.MX53 will be utilized for the interactions between i.MX53 and external peripherals;

        At this phase, we use IOMUX_plan_calculatorMX53_100517_ext.xls developed by Roman Mostinski (maybe there exist new update of this tool) to plan the  pins-out bundled w/ interfaces (i.e. connecting to i.MX53 internal functional modules), its "Instruction" sheet tells you how to use this tool to customize the utilized interfaces in the target design. I briefly describe here. First, switch to "Configuration_Select" sheet, under "Module" column, the i.MX53 total modules have been listed, so you can choice one module that your design utilizes (ex. Camera Interface module) from the list, then set "TRUE" or "FALSE" of each module signal at column Z labeled "Needed for Usecase", then choice another module, do the same module signal setting, and so on till all utilized modules have been set up. For verification on the IOMUX pins planning, I cite the developer's description:

 


 "MX53_pins" tab
  This table shows current current status of port allocation
  >For each pad (row) check column "Conflict" (column "J"):
   - "TRUE" indicates there are conflicting ports (ALTxx cells colored in orange) or port(s) that could not be allocated at all (ALTxx cells colored in red). You should re-consider
IOMUX plan if some ports can not be allocated.
   - "FALSE" indicates there is no conflict. Please check ALTxx. If there is cell colored in orange it indicates port that have only single available location in the current IOMUX plan, and
therefore that port should be allocated.
  For pad allocation please select appropriate ALT mode (column "H") and lock pad (change "FREE" to "LOCK") in column "G"
   - column "I" shows function (port) corresponding to the selected ALT mode
   - Allocated ports will be marked in green. If the ALT mode in configured IOMUX is not the same as it is in the default configuration the cell in column H changes its color to bright yellow.
  Re-check conflicts and repeat pad allocation

        At this point, we have defined the dedicated IOMUX pins to connect the target board's peripherals, and these dedicated pins are routed to i.MX53 internal modules (ex. SPI, CSI, eMMC, SPDIF, DISP0/1 etc.), and we also know that some peripherals like HDMI transmitter may require extra switch signals to perform controlling purpose, so GPIO pins allocated from GPIO modules are involved. This requirement will definitely occur when no dedicated interfaces are  supported by default. Considering that GPIO is one modules in "Configuration_Select" sheet, so we can specify these needed GPIO switch signals randomly, if these setting cause "Conflict" in "MX53_pins" sheet, for more fine tune, we have to reference to chapter 4 in "i.MX53 Reference Manual" to figure out a proper choice.

 

Step 2: Add these interfaces' usage in mach-mx5/mx53_smd.c as following

static iomux_v3_cfg_t mx53_smd_pads[] = {

        ............

    /* DI_VGA_HSYNC */
    MX53_PAD_EIM_OE__IPU_DI1_PIN7,
    /* HDMI reset */
    MX53_PAD_EIM_WAIT__GPIO5_0,
    /* DI_VGA_VSYNC */
    MX53_PAD_EIM_RW__IPU_DI1_PIN8,
    /* CSPI1 */
    MX53_PAD_EIM_EB2__ECSPI1_SS0,
    MX53_PAD_EIM_D16__ECSPI1_SCLK,
    MX53_PAD_EIM_D17__ECSPI1_MISO,
    MX53_PAD_EIM_D18__ECSPI1_MOSI,
    MX53_PAD_EIM_D19__ECSPI1_SS1,
    /* BT: UART3*/
    MX53_PAD_EIM_D24__UART3_TXD_MUX,
    MX53_PAD_EIM_D25__UART3_RXD_MUX,
    MX53_PAD_EIM_EB3__UART3_RTS,
    MX53_PAD_EIM_D23__UART3_CTS,
        ............

}

This array settings are used for IOMUXC set by mxc_iomux_v3_setup_pad(),  its naming pattern reflects the mapping relation in <MX53_PAD_xxx, Block_BlockPort>. ex. MX53_PAD_EIM_D24__UART3_TXD_MUX in which EIM_D24 stands for the pad name, and UART3_TXD_MUX stands for block instance is UART3, TXD_MUX is the block I/O (extracted from Table 4-3, i.MX53 Reference Manual).


 

The mx53_smd_pads[] enumerates all used interfaces that are connected to external peripherals, so certainly it also contains the controlling purpose switch signals bundled w/ certain peripheral that will be set as GPIO block I/O.

 

Step 3: Define bundled GPIO signals

For that extra control purpose switch signals (GPIO typed), we define these switch signals totally as being macros. For example:

#define MX53_SMD_HDMI_RESET_B        (4*32 + 0)    /* GPIO_5_0 */
#define MX53_SMD_MODEM_RESET_B        (4*32 + 2)    /* GPIO_5_2 */
#define MX53_SMD_KEY_INT            (4*32 + 4)    /* GPIO_5_4 */

where MX53_SMD stands for target board name, HDMI_RESET_B is the net name in schematic design,  (4 * 32 + 0) stands for the #0 block I/O of #5 GPIO Block Instance, these macro setting will be used by gpio_request(), gpio_get_value(), gpio_set_value(), gpio_direction_output(), and gpio_direction_input() APIs. These switch control signals will be referenced by devices' kernel driver to perform specific control purpose. Note the same pin declared in mx53_smd_pads[] is    

/* HDMI reset */
    MX53_PAD_EIM_WAIT__GPIO5_0,
it is for IOMUXC only.

 

Summary

When facing a new customer's board, we can deduce these pins' configuration and usage step by step without missing following the above guidelines.

 

 

s of port allocation
  >For each pad (row) check column "Cnflict" (colum "J"):
   - "TRUE" indicates there are conflicting ports (ALTxx cells colored in orange) or port(s) that could not be allocated at all (ALTxx cells colored in red). You should re-consider
IOMUX plan if some ports can not be allocated.
   - "FALSE" indicates there is no conflict. Please check ALTxx. If there is cell colored in orange it indicates port that have only single available location in the current IOMUX plan, and
therefore that port should be allocated.
  For pad allocation please select appropriate ALT mode (column "H") and lock pad (change "FREE" to "LOCK") in column "G"
   - column "I" shows function (port) corresponding to the selected ALT mode
   - Allocated ports will be marked in green. If the ALT mode in configured IOMUX is not the same as it is in the default configuration the cell in column H changes its color to bright yellow.
  Re-check conflicts and repeat pad allocation
r
each pad (row) check column "Conflict" (column "J"):

Outcomes