Difference between revisions of "OMAP wishlist"

From eLinux.org
Jump to: navigation, search
m (Add category)
Line 85: Line 85:

Latest revision as of 14:45, 27 October 2011

OMAP developers' wishlist for TI

  • Better access to TI documentation
  • Hardware registers in machine readable format (partially happening for omap4 already)
  • More long term maintenance approach

Wishlist for companies developing on OMAPs

  • More participation from companies using omaps
  • Concentrate on doing the core features well to recycle code between omaps
  • Let the original patch authors submit the code on the mailing lists
  • Review patches internally
  • Coordinate development on linux-omap@vger.kernel.org mailing list

Pin-mux framework

Feature list

  • dynamic, run-time alloc/free of pins
  • handle various SoCs: 34xx, 35xx including the various packages of 35xx
  • IP based Revision and errata handling framework
  • capability for I2C to handle board+bus based timing parameters (SCLL and SLH)

Initial plans (from Tony, for next merge window)

1. Do the include directories for mach-omap1 and mach-omap2 as suggested by Russell earlier: http://www.mail-archive.com/linux-omap@vger.kernel.org/msg15087.html

2. Move all mux code to only live under arch/arm/*omap*/ and make sure drivers don't call omap_cfg_reg() any longer

3. Remove the enumeration for the mux and require all the boards to register the pins they'll use

After these it should be trivial to improve the mux code further. The steps 2 & 3 above will be most likely breaking things for some boards, so help will be needed with testing.

Update: New mux code is now merged for omap3. Next steps are to convert 24xx to use the new mux framework and then to add omap4 support.



PXA uses MFP (Multi-Function Pin) framework for pin multiplexing. Brief MFP description can be found at Documentation/arm/pxa/mfp.txt.

Update: We ended up not using the PXA approach, as we need to mux some pins dynamically. We also wanted pin debugging support, and support for overriding bootloader pins from cmdline. This all needs signal name based approach. Signal name based approach also should be more future proof with new omaps.

The concept of MFP is as follows:

  • There's an enumeration of all possible configurable pins.
  • The enumeration values are used as indexes to the mfp_table that defines pin configuration register address and pin configuration for active and low power modes. The table entries are quite similar to OMAP's pin_config, and the mfp_table is much like omapXXXX_pins[]. The main difference is that omapXXXX_pins[] tries to define all possible mux modes and the mfp_table has exactly one entry for a pin.
  • Possible pin configurations are encoded together with pin enumeration index with a set of a macros, e.g
#define GPIO32_UTM_PHYDATA_2       MFP_CFG(GPIO32,  AF3)
#define GPIO32_USB_P2_4            MFP_CFG(GPIO32, AF1)
  • Processor initialization code sets pin configuration register addresses in the mfp_table for all pins present of the CPU variant
  • Board initialization code uses MFP API to set actual pin configuration both in the mfp_table and in the pin configuration registers, e.g :
static mfp_cfg_t cm_x300_mfp_cfg[] __initdata = {
	/* LCD */

	/* BTUART */

	/* STUART */

static void __init machine_init_func(void)