diff options
Diffstat (limited to 'Documentation/arm')
| -rw-r--r-- | Documentation/arm/OMAP/omap_pm | 129 | ||||
| -rw-r--r-- | Documentation/arm/SA1100/ADSBitsy | 2 | ||||
| -rw-r--r-- | Documentation/arm/SA1100/Assabet | 2 | ||||
| -rw-r--r-- | Documentation/arm/SA1100/Brutus | 2 | ||||
| -rw-r--r-- | Documentation/arm/SA1100/GraphicsClient | 4 | ||||
| -rw-r--r-- | Documentation/arm/SA1100/GraphicsMaster | 4 | ||||
| -rw-r--r-- | Documentation/arm/SA1100/Victor | 2 | ||||
| -rw-r--r-- | Documentation/arm/Samsung-S3C24XX/CPUfreq.txt | 75 |
8 files changed, 212 insertions, 8 deletions
diff --git a/Documentation/arm/OMAP/omap_pm b/Documentation/arm/OMAP/omap_pm new file mode 100644 index 0000000..5389440 --- /dev/null +++ b/Documentation/arm/OMAP/omap_pm @@ -0,0 +1,129 @@ + +The OMAP PM interface +===================== + +This document describes the temporary OMAP PM interface. Driver +authors use these functions to communicate minimum latency or +throughput constraints to the kernel power management code. +Over time, the intention is to merge features from the OMAP PM +interface into the Linux PM QoS code. + +Drivers need to express PM parameters which: + +- support the range of power management parameters present in the TI SRF; + +- separate the drivers from the underlying PM parameter + implementation, whether it is the TI SRF or Linux PM QoS or Linux + latency framework or something else; + +- specify PM parameters in terms of fundamental units, such as + latency and throughput, rather than units which are specific to OMAP + or to particular OMAP variants; + +- allow drivers which are shared with other architectures (e.g., + DaVinci) to add these constraints in a way which won't affect non-OMAP + systems, + +- can be implemented immediately with minimal disruption of other + architectures. + + +This document proposes the OMAP PM interface, including the following +five power management functions for driver code: + +1. Set the maximum MPU wakeup latency: + (*pdata->set_max_mpu_wakeup_lat)(struct device *dev, unsigned long t) + +2. Set the maximum device wakeup latency: + (*pdata->set_max_dev_wakeup_lat)(struct device *dev, unsigned long t) + +3. Set the maximum system DMA transfer start latency (CORE pwrdm): + (*pdata->set_max_sdma_lat)(struct device *dev, long t) + +4. Set the minimum bus throughput needed by a device: + (*pdata->set_min_bus_tput)(struct device *dev, u8 agent_id, unsigned long r) + +5. Return the number of times the device has lost context + (*pdata->get_dev_context_loss_count)(struct device *dev) + + +Further documentation for all OMAP PM interface functions can be +found in arch/arm/plat-omap/include/mach/omap-pm.h. + + +The OMAP PM layer is intended to be temporary +--------------------------------------------- + +The intention is that eventually the Linux PM QoS layer should support +the range of power management features present in OMAP3. As this +happens, existing drivers using the OMAP PM interface can be modified +to use the Linux PM QoS code; and the OMAP PM interface can disappear. + + +Driver usage of the OMAP PM functions +------------------------------------- + +As the 'pdata' in the above examples indicates, these functions are +exposed to drivers through function pointers in driver .platform_data +structures. The function pointers are initialized by the board-*.c +files to point to the corresponding OMAP PM functions: +.set_max_dev_wakeup_lat will point to +omap_pm_set_max_dev_wakeup_lat(), etc. Other architectures which do +not support these functions should leave these function pointers set +to NULL. Drivers should use the following idiom: + + if (pdata->set_max_dev_wakeup_lat) + (*pdata->set_max_dev_wakeup_lat)(dev, t); + +The most common usage of these functions will probably be to specify +the maximum time from when an interrupt occurs, to when the device +becomes accessible. To accomplish this, driver writers should use the +set_max_mpu_wakeup_lat() function to to constrain the MPU wakeup +latency, and the set_max_dev_wakeup_lat() function to constrain the +device wakeup latency (from clk_enable() to accessibility). For +example, + + /* Limit MPU wakeup latency */ + if (pdata->set_max_mpu_wakeup_lat) + (*pdata->set_max_mpu_wakeup_lat)(dev, tc); + + /* Limit device powerdomain wakeup latency */ + if (pdata->set_max_dev_wakeup_lat) + (*pdata->set_max_dev_wakeup_lat)(dev, td); + + /* total wakeup latency in this example: (tc + td) */ + +The PM parameters can be overwritten by calling the function again +with the new value. The settings can be removed by calling the +function with a t argument of -1 (except in the case of +set_max_bus_tput(), which should be called with an r argument of 0). + +The fifth function above, omap_pm_get_dev_context_loss_count(), +is intended as an optimization to allow drivers to determine whether the +device has lost its internal context. If context has been lost, the +driver must restore its internal context before proceeding. + + +Other specialized interface functions +------------------------------------- + +The five functions listed above are intended to be usable by any +device driver. DSPBridge and CPUFreq have a few special requirements. +DSPBridge expresses target DSP performance levels in terms of OPP IDs. +CPUFreq expresses target MPU performance levels in terms of MPU +frequency. The OMAP PM interface contains functions for these +specialized cases to convert that input information (OPPs/MPU +frequency) into the form that the underlying power management +implementation needs: + +6. (*pdata->dsp_get_opp_table)(void) + +7. (*pdata->dsp_set_min_opp)(u8 opp_id) + +8. (*pdata->dsp_get_opp)(void) + +9. (*pdata->cpu_get_freq_table)(void) + +10. (*pdata->cpu_set_freq)(unsigned long f) + +11. (*pdata->cpu_get_freq)(void) diff --git a/Documentation/arm/SA1100/ADSBitsy b/Documentation/arm/SA1100/ADSBitsy index ab47c38..7197a9e 100644 --- a/Documentation/arm/SA1100/ADSBitsy +++ b/Documentation/arm/SA1100/ADSBitsy @@ -40,4 +40,4 @@ Notes: mode, the timing is off so the image is corrupted. This will be fixed soon. -Any contribution can be sent to nico@cam.org and will be greatly welcome! +Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/SA1100/Assabet b/Documentation/arm/SA1100/Assabet index 78bc1c1..91f7ce7 100644 --- a/Documentation/arm/SA1100/Assabet +++ b/Documentation/arm/SA1100/Assabet @@ -240,7 +240,7 @@ Then, rebooting the Assabet is just a matter of waiting for the login prompt. Nicolas Pitre -nico@cam.org +nico@fluxnic.net June 12, 2001 diff --git a/Documentation/arm/SA1100/Brutus b/Documentation/arm/SA1100/Brutus index 2254c8f..b1cfd40 100644 --- a/Documentation/arm/SA1100/Brutus +++ b/Documentation/arm/SA1100/Brutus @@ -60,7 +60,7 @@ little modifications. Any contribution is welcome. -Please send patches to nico@cam.org +Please send patches to nico@fluxnic.net Have Fun ! diff --git a/Documentation/arm/SA1100/GraphicsClient b/Documentation/arm/SA1100/GraphicsClient index 8fa7e80..6c9c4f5 100644 --- a/Documentation/arm/SA1100/GraphicsClient +++ b/Documentation/arm/SA1100/GraphicsClient @@ -4,7 +4,7 @@ For more details, contact Applied Data Systems or see http://www.applieddata.net/products.html The original Linux support for this product has been provided by -Nicolas Pitre <nico@cam.org>. Continued development work by +Nicolas Pitre <nico@fluxnic.net>. Continued development work by Woojung Huh <whuh@applieddata.net> It's currently possible to mount a root filesystem via NFS providing a @@ -94,5 +94,5 @@ Notes: mode, the timing is off so the image is corrupted. This will be fixed soon. -Any contribution can be sent to nico@cam.org and will be greatly welcome! +Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/SA1100/GraphicsMaster b/Documentation/arm/SA1100/GraphicsMaster index dd28745..ee7c659 100644 --- a/Documentation/arm/SA1100/GraphicsMaster +++ b/Documentation/arm/SA1100/GraphicsMaster @@ -4,7 +4,7 @@ For more details, contact Applied Data Systems or see http://www.applieddata.net/products.html The original Linux support for this product has been provided by -Nicolas Pitre <nico@cam.org>. Continued development work by +Nicolas Pitre <nico@fluxnic.net>. Continued development work by Woojung Huh <whuh@applieddata.net> Use 'make graphicsmaster_config' before any 'make config'. @@ -50,4 +50,4 @@ Notes: mode, the timing is off so the image is corrupted. This will be fixed soon. -Any contribution can be sent to nico@cam.org and will be greatly welcome! +Any contribution can be sent to nico@fluxnic.net and will be greatly welcome! diff --git a/Documentation/arm/SA1100/Victor b/Documentation/arm/SA1100/Victor index 01e81fc..f938a29 100644 --- a/Documentation/arm/SA1100/Victor +++ b/Documentation/arm/SA1100/Victor @@ -9,7 +9,7 @@ Of course Victor is using Linux as its main operating system. The Victor implementation for Linux is maintained by Nicolas Pitre: nico@visuaide.com - nico@cam.org + nico@fluxnic.net For any comments, please feel free to contact me through the above addresses. diff --git a/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt b/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt new file mode 100644 index 0000000..76b3a11 --- /dev/null +++ b/Documentation/arm/Samsung-S3C24XX/CPUfreq.txt @@ -0,0 +1,75 @@ + S3C24XX CPUfreq support + ======================= + +Introduction +------------ + + The S3C24XX series support a number of power saving systems, such as + the ability to change the core, memory and peripheral operating + frequencies. The core control is exported via the CPUFreq driver + which has a number of different manual or automatic controls over the + rate the core is running at. + + There are two forms of the driver depending on the specific CPU and + how the clocks are arranged. The first implementation used as single + PLL to feed the ARM, memory and peripherals via a series of dividers + and muxes and this is the implementation that is documented here. A + newer version where there is a seperate PLL and clock divider for the + ARM core is available as a seperate driver. + + +Layout +------ + + The code core manages the CPU specific drivers, any data that they + need to register and the interface to the generic drivers/cpufreq + system. Each CPU registers a driver to control the PLL, clock dividers + and anything else associated with it. Any board that wants to use this + framework needs to supply at least basic details of what is required. + + The core registers with drivers/cpufreq at init time if all the data + necessary has been supplied. + + +CPU support +----------- + + The support for each CPU depends on the facilities provided by the + SoC and the driver as each device has different PLL and clock chains + associated with it. + + +Slow Mode +--------- + + The SLOW mode where the PLL is turned off altogether and the + system is fed by the external crystal input is currently not + supported. + + +sysfs +----- + + The core code exports extra information via sysfs in the directory + devices/system/cpu/cpu0/arch-freq. + + +Board Support +------------- + + Each board that wants to use the cpufreq code must register some basic + information with the core driver to provide information about what the + board requires and any restrictions being placed on it. + + The board needs to supply information about whether it needs the IO bank + timings changing, any maximum frequency limits and information about the + SDRAM refresh rate. + + + + +Document Author +--------------- + +Ben Dooks, Copyright 2009 Simtec Electronics +Licensed under GPLv2 |
