|
@@ -0,0 +1,48 @@
|
|
|
+/*
|
|
|
+ * omap_hwmod implementation for OMAP2/3/4
|
|
|
+ *
|
|
|
+ * Copyright (C) 2009-2011 Nokia Corporation
|
|
|
+ * Copyright (C) 2011-2012 Texas Instruments, Inc.
|
|
|
+ *
|
|
|
+ * Paul Walmsley, Benoît Cousson, Kevin Hilman
|
|
|
+ *
|
|
|
+ * Created in collaboration with (alphabetical order): Thara Gopinath,
|
|
|
+ * Tony Lindgren, Rajendra Nayak, Vikram Pandita, Sakari Poussa, Anand
|
|
|
+ * Sawant, Santosh Shilimkar, Richard Woodruff
|
|
|
+ *
|
|
|
+ * This program is free software; you can redistribute it and/or modify
|
|
|
+ * it under the terms of the GNU General Public License version 2 as
|
|
|
+ * published by the Free Software Foundation.
|
|
|
+ *
|
|
|
+ * Introduction
|
|
|
+ * ------------
|
|
|
+ * One way to view an OMAP SoC is as a collection of largely unrelated
|
|
|
+ * IP blocks connected by interconnects. The IP blocks include
|
|
|
+ * devices such as ARM processors, audio serial interfaces, UARTs,
|
|
|
+ * etc. Some of these devices, like the DSP, are created by TI;
|
|
|
+ * others, like the SGX, largely originate from external vendors. In
|
|
|
+ * TI's documentation, on-chip devices are referred to as "OMAP
|
|
|
+ * modules." Some of these IP blocks are identical across several
|
|
|
+ * OMAP versions. Others are revised frequently.
|
|
|
+ *
|
|
|
+ * These OMAP modules are tied together by various interconnects.
|
|
|
+ * Most of the address and data flow between modules is via OCP-based
|
|
|
+ * interconnects such as the L3 and L4 buses; but there are other
|
|
|
+ * interconnects that distribute the hardware clock tree, handle idle
|
|
|
+ * and reset signaling, supply power, and connect the modules to
|
|
|
+ * various pads or balls on the OMAP package.
|
|
|
+ *
|
|
|
+ * OMAP hwmod provides a consistent way to describe the on-chip
|
|
|
+ * hardware blocks and their integration into the rest of the chip.
|
|
|
+ * This description can be automatically generated from the TI
|
|
|
+ * hardware database. OMAP hwmod provides a standard, consistent API
|
|
|
+ * to reset, enable, idle, and disable these hardware blocks. And
|
|
|
+ * hwmod provides a way for other core code, such as the Linux device
|
|
|
+ * code or the OMAP power management and address space mapping code,
|
|
|
+ * to query the hardware database.
|
|
|
+ *
|
|
|
+ * Using hwmod
|
|
|
+ * -----------
|
|
|
+ * Drivers won't call hwmod functions directly. That is done by the
|
|
|
+ * omap_device code, and in rare occasions, by custom integration code
|
|
|
+ * in arch/arm/ *omap*. The omap_device code includes functions to
|