OMAP wishlist - Revision history

Cschalle: Add category

2011-10-27T21:45:16Z

Add category

Tmlind at 00:33, 16 December 2009

2009-12-16T00:33:24Z

Tmlind: /* PXA */

2009-12-16T00:20:54Z

‎PXA

Tmlind: /* Initial plans (from Tony, for next merge window) */

2009-12-16T00:17:52Z

‎Initial plans (from Tony, for next merge window)

Khilman at 14:16, 14 October 2009

2009-10-14T14:16:39Z

Gadiyar: /* Feature list */

2009-09-15T06:43:27Z

‎Feature list

Rppt at 06:16, 15 September 2009

2009-09-15T06:16:18Z

Nmenon at 16:08, 14 September 2009

2009-09-14T16:08:21Z

Khilman: Created page with '= Pin-mux framework = == Feature list == * dynamic, run-time alloc/free of pins * handle various SoCs: 34xx, 35xx including the various packages of 35xx'

2009-09-10T16:06:53Z

Created page with '= Pin-mux framework = == Feature list == * dynamic, run-time alloc/free of pins * handle various SoCs: 34xx, 35xx including the various packages of 35xx'

New page

= Pin-mux framework =

== Feature list ==

* dynamic, run-time alloc/free of pins
* handle various SoCs: 34xx, 35xx including the various packages of 35xx

← Older revision		Revision as of 21:45, 27 October 2011
Line 85:		Line 85:
	}		}
	</pre>		</pre>
		+
		+	[[Category:OMAP]]

← Older revision		Revision as of 00:33, 16 December 2009
Line 1:		Line 1:
		+	= 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 =		= Pin-mux framework =

@@ Line 27: / Line 27: @@
 === PXA ===
 PXA uses MFP (Multi-Function Pin) framework for pin multiplexing. Brief MFP description can be found at [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/arm/pxa/mfp.txt;h=a179e5bc02c94c655b3d1795c899664a2e1f2778;hb=HEAD Documentation/arm/pxa/mfp.txt].
 The concept of MFP is as follows:

@@ Line 20: / Line 20: @@
 steps 2 & 3 above will be most likely breaking things for some boards,
 so help will be needed with testing.
 == References ==

@@ Line 7: / Line 7: @@
 * IP based Revision and errata handling framework
 * capability for I2C to handle board+bus based timing parameters (SCLL and SLH)
 == References ==

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

← Older revision		Revision as of 06:16, 15 September 2009
Line 7:		Line 7:
	* IP based Revision and errata handling handling framework		* IP based Revision and errata handling handling framework
	* capability for I2C to handle board+bus based timing parameters (SCLL and SLH)		* capability for I2C to handle board+bus based timing parameters (SCLL and SLH)
		+
		+	== References ==
		+	=== PXA ===
		+	PXA uses MFP (Multi-Function Pin) framework for pin multiplexing. Brief MFP description can be found at [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/arm/pxa/mfp.txt;h=a179e5bc02c94c655b3d1795c899664a2e1f2778;hb=HEAD Documentation/arm/pxa/mfp.txt].
		+
		+	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 <tt>mfp_table</tt> that defines pin configuration register address and pin configuration for active and low power modes. The table entries are quite similar to OMAP's <tt>pin_config</tt>, and the <tt>mfp_table</tt> is much like <tt>omapXXXX_pins[]</tt>. The main difference is that <tt>omapXXXX_pins[]</tt> tries to define all possible mux modes and the <tt>mfp_table</tt> 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
		+	<pre>
		+	#define GPIO32_UART1_CTS MFP_CFG_LPM(GPIO32, AF2, FLOAT)
		+	#define GPIO32_UART1_RTS MFP_CFG_LPM(GPIO32, AF4, FLOAT)
		+	#define GPIO32_UTM_PHYDATA_2 MFP_CFG(GPIO32, AF3)
		+	#define GPIO32_USB_P2_4 MFP_CFG(GPIO32, AF1)
		+	</pre>
		+	* Processor initialization code sets pin configuration register addresses in the <tt>mfp_table</tt> for all pins present of the CPU variant
		+	* Board initialization code uses MFP API to set actual pin configuration both in the <tt>mfp_table</tt> and in the pin configuration registers, e.g :
		+	<pre>
		+	static mfp_cfg_t cm_x300_mfp_cfg[] __initdata = {
		+	/* LCD */
		+	GPIO54_LCD_LDD_0,
		+	GPIO55_LCD_LDD_1,
		+	GPIO56_LCD_LDD_2,
		+	GPIO57_LCD_LDD_3,
		+
		+	/* BTUART */
		+	GPIO111_UART2_RTS,
		+	GPIO112_UART2_RXD \| MFP_LPM_EDGE_FALL,
		+	GPIO113_UART2_TXD,
		+	GPIO114_UART2_CTS \| MFP_LPM_EDGE_BOTH,
		+
		+	/* STUART */
		+	GPIO109_UART3_TXD,
		+	GPIO110_UART3_RXD \| MFP_LPM_EDGE_FALL,
		+	}
		+
		+	static void __init machine_init_func(void)
		+	{
		+	pxa3xx_mfp_config(ARRAY_AND_SIZE(cm_x300_mfp_cfg));
		+	...
		+	}
		+	</pre>

← Older revision		Revision as of 16:08, 14 September 2009
Line 5:		Line 5:
	* dynamic, run-time alloc/free of pins		* dynamic, run-time alloc/free of pins
	* handle various SoCs: 34xx, 35xx including the various packages of 35xx		* handle various SoCs: 34xx, 35xx including the various packages of 35xx
		+	* IP based Revision and errata handling handling framework
		+	* capability for I2C to handle board+bus based timing parameters (SCLL and SLH)