Initial Contribution
msm-2.6.38: tag AU_LINUX_ANDROID_GINGERBREAD.02.03.04.00.142
Signed-off-by: Bryan Huntsman <bryanh@codeaurora.org>
diff --git a/Documentation/DocBook/debugobjects.tmpl b/Documentation/DocBook/debugobjects.tmpl
index 08ff908..24979f6 100644
--- a/Documentation/DocBook/debugobjects.tmpl
+++ b/Documentation/DocBook/debugobjects.tmpl
@@ -96,6 +96,7 @@
<listitem><para>debug_object_deactivate</para></listitem>
<listitem><para>debug_object_destroy</para></listitem>
<listitem><para>debug_object_free</para></listitem>
+ <listitem><para>debug_object_assert_init</para></listitem>
</itemizedlist>
Each of these functions takes the address of the real object and
a pointer to the object type specific debug description
@@ -273,6 +274,26 @@
debug checks.
</para>
</sect1>
+
+ <sect1 id="debug_object_assert_init">
+ <title>debug_object_assert_init</title>
+ <para>
+ This function is called to assert that an object has been
+ initialized.
+ </para>
+ <para>
+ When the real object is not tracked by debugobjects, it calls
+ fixup_assert_init of the object type description structure
+ provided by the caller, with the hardcoded object state
+ ODEBUG_NOT_AVAILABLE. The fixup function can correct the problem
+ by calling debug_object_init and other specific initializing
+ functions.
+ </para>
+ <para>
+ When the real object is already tracked by debugobjects it is
+ ignored.
+ </para>
+ </sect1>
</chapter>
<chapter id="fixupfunctions">
<title>Fixup functions</title>
@@ -381,6 +402,35 @@
statistics.
</para>
</sect1>
+ <sect1 id="fixup_assert_init">
+ <title>fixup_assert_init</title>
+ <para>
+ This function is called from the debug code whenever a problem
+ in debug_object_assert_init is detected.
+ </para>
+ <para>
+ Called from debug_object_assert_init() with a hardcoded state
+ ODEBUG_STATE_NOTAVAILABLE when the object is not found in the
+ debug bucket.
+ </para>
+ <para>
+ The function returns 1 when the fixup was successful,
+ otherwise 0. The return value is used to update the
+ statistics.
+ </para>
+ <para>
+ Note, this function should make sure debug_object_init() is
+ called before returning.
+ </para>
+ <para>
+ The handling of statically initialized objects is a special
+ case. The fixup function should check if this is a legitimate
+ case of a statically initialized object or not. In this case only
+ debug_object_init() should be called to make the object known to
+ the tracker. Then the function should return 0 because this is not
+ a real fixup.
+ </para>
+ </sect1>
</chapter>
<chapter id="bugs">
<title>Known Bugs And Assumptions</title>
diff --git a/Documentation/arm/msm/boot.txt b/Documentation/arm/msm/boot.txt
new file mode 100644
index 0000000..1a41cd5
--- /dev/null
+++ b/Documentation/arm/msm/boot.txt
@@ -0,0 +1,23 @@
+Introduction
+=============
+The power management integrated circuit (PMIC) records the reason the
+Application processor was powered on in Shared Memory.
+The hardware and software used is the shared memory interface. This document
+is not for the purpose of describing this interface, but to identify the
+possible values for this data item.
+
+Description
+===========
+Shared memory item (SMEM_POWER_ON_STATUS_INFO) is read to get access to
+this data. The table below identifies the possible values stored.
+
+power_on_status values set by the PMIC for power on event:
+----------------------------------------------------------
+0x01 -- keyboard power on
+0x02 -- RTC alarm
+0x04 -- cable power on
+0x08 -- SMPL
+0x10 -- Watch Dog timeout
+0x20 -- USB charger
+0x40 -- Wall charger
+0xFF -- error reading power_on_status value
diff --git a/Documentation/arm/msm/emulate_domain_manager.txt b/Documentation/arm/msm/emulate_domain_manager.txt
new file mode 100644
index 0000000..b0d007e
--- /dev/null
+++ b/Documentation/arm/msm/emulate_domain_manager.txt
@@ -0,0 +1,254 @@
+Introduction
+============
+
+8x50 chipset requires the ability to disable HW domain manager function.
+
+The ARM MMU architecture has a feature known as domain manager mode.
+Briefly each page table, section, or supersection is assigned a domain.
+Each domain can be globally configured to NoAccess, Client, or Manager
+mode. These global configurations allow the access permissions of the
+entire domain to be changed simultaneously.
+
+The domain manger emulation is required to fix a HW problem on the 8x50
+chipset. The problem is simple to repair except when domain manager mode
+is enabled. The emulation allows the problem to be completely resolved.
+
+
+Hardware description
+====================
+
+When domain manager mode is enabled on a specific domain, the MMU
+hardware ignores the access permission bits and the execute never bit. All
+accesses, to memory in the domain, are granted full read, write,
+execute permissions.
+
+The mode of each domain is controlled by a field in the cp15 dacr register.
+Each domain can be globally configured to NoAccess, Client, or Manager mode.
+
+See: ARMv7 Architecture Reference Manual
+
+
+Software description
+====================
+
+In order to disable domain manager mode the equivalent HW functionality must
+be emulated in SW. Any attempts to enable domain manager mode, must be
+intercepted.
+
+Because domain manager mode is not enabled, permissions for the
+associated domain will remain restricted. Permission faults will be generated.
+The permission faults will be intercepted. The faulted pages/sections will
+be modified to grant full access and execute permissions.
+
+The modified page tables must be restored when exiting domain manager mode.
+
+
+Design
+======
+
+Design Goals:
+
+Disable Domain Manager Mode
+Exact SW emulation of Domain Manager Mode
+Minimal Kernel changes
+Minimal Security Risk
+
+Design Decisions:
+
+Detect kernel page table modifications on restore
+Direct ARMv7 HW MMU table manipulation
+Restore emulation modified MMU entries on context switch
+No need to restore MMU entries for MMU entry copy operations
+Invalidate TLB entries on modification
+Store Domain Manager bits in memory
+8 entry MMU entry cache
+Use spin_lock_irqsave to protect domain manipulation
+Assume no split MMU table
+
+Design Discussion:
+
+Detect kernel page table modifications on restore -
+When restoring original page/section permission faults, the submitted design
+verifies the MMU entry has not been modified. The kernel modifies MMU
+entries for the following purposes : create a memory mapping, release a
+memory mapping, add permissions during a permission fault, and map a page
+during a translation fault. The submitted design works with the listed
+scenarios. The translation fault and permission faults simply do not happen on
+relevant entries (valid entries with full access permissions). The alternative
+would be to hook every MMU table modification. The alternative greatly
+increases complexity and code maintenance issues.
+
+Direct ARMv7 HW MMU table manipulation -
+The natural choice would be to use the kernel provided mechanism to manipulate
+MMU page table entries. The ARM MMU interface is described in pgtable.h.
+This interface is complicated by the Linux implementation. The level 1 pgd
+entries are treated and manipulated as entry pairs. The level 2 entries are
+shadowed and cloned. The compromise was chosen to actually use the ARMv7 HW
+registers to walk and modify the MMU table entries. The choice limits the
+usage of this implementation to ARMv7 and similar ARM MMU architectures. Since
+this implementation is targeted at fixing an issue in 8x50 ARMv7, the choice is
+logical. The HW manipulation is in distinct low level functions. These could
+easily be replaced or generalized to support other architectures as necessary.
+
+Restore emulation modified MMU entries on context switch -
+This additional hook was added to minimize performance impact. By guaranteeing
+the ASID will not change during the emulation, the emulation may invalidate each
+entry by MVA & ASID. Only the affected page table entries will be removed from
+the TLB cache. The performance cost of the invalidate on context switch is near
+zero. Typically on context switch the domain mode would also change, forcing a
+complete restore of all modified MMU entries. The alternative would be to
+invalidate the entire TLB every time a table entry is restored.
+
+No need to restore MMU entries for copy operations -
+Operations which copy MMU entries are relatively rare in the kernel. Because
+we modify the level 2 pte entries directly in hardware, the Linux shadow copies
+are left untouched. The kernel treats the shadow copies as the primary pte
+entry. Any pte copy operations would be unaffected by the HW modification.
+On translation section fault, pgd entries are copied from the kernel master
+page table to the current thread page table. Since we restore MMU entries on
+context switch, we guarantee the master table will not contain modifications,
+while faulting on a process local entry. Other read, modify write operations
+occur during permission fault handling. Since we open permission on modified
+entries, these do not need to be restored, because we guarantee these
+permission fault operations will not happen.
+
+Invalidate TLB entries on modification -
+No real choice here. This is more of a design requirement. On permission
+fault, the MMU entry with restricted permissions will be in the TLB. To open
+access permissions, the TLB entry must be invalidated. Otherwise the access
+will permission fault again. Upon restoring original MMU entries, the TLB
+must be invalidated to restrict memory access.
+
+Store Domain Manager bits in memory -
+There was only one alternative here. 2.6.29 kernel only uses 3 of 16
+possible domains. Additional bits in dacr could be used to store the
+manager bits. This would allow faster access to the manager bits.
+Overall this would reduce any performance impact. The performance
+needs did not seem to justify the added weirdness.
+
+8 entry MMU entry cache-
+The size of the modified MMU entry cache is somewhat arbitrary. The thought
+process is that typically, a thread is using two pointers to perform a copy
+operation. In this case only 2 entries would be required. One could imagine
+a more complicated operation, a masked copy for instance, which would require
+more pointers. 8 pointer seemed to be large enough to minimize risk of
+permission fault thrashing. The disadvantage of a larger cache would simply
+be a longer list of entries to restore.
+
+Use spin_lock_irqsave to protect domain manipulation -
+The obvious choice.
+
+Assume no split MMU table -
+This same assumption is documented in cpu_v7_switch_mm.
+
+
+Power Management
+================
+
+Not affected.
+
+
+SMP/multi-core
+==============
+
+SMP/multicore not supported. This is intended as a 8x50 workaround.
+
+
+Security
+========
+
+MMU page/section permissions must be manipulated correctly to emulate domain
+manager mode. If page permission are left in full access mode, any process
+can read associated memory.
+
+
+Performance
+===========
+
+Performance should be impacted only minimally. When emulating domain manager
+mode, there is overhead added to MMU table/context switches, set_domain()
+calls, data aborts, and prefetch aborts.
+
+Normally the kernel operates with domain != DOMAIN_MANAGER. In this case the
+overhead is minimal. An additional check is required to see if domain manager
+mode is on. This minimal code is added to each of emulation entry points :
+set, data abort, prefetch abort, and MMU table/context switch.
+
+Initial accesses to a MMU protected page/section will generate a permission
+fault. The page will be manipulated to grant full access permissions and
+the access will be retried. This will typically require 2-3 page table
+walks.
+
+On a context switch, all modified MMU entries will be restored. On thread
+resume, additional accesses will be treated as initial accesses.
+
+
+Interface
+=========
+
+The emulation does not have clients. It is hooked to the kernel through a
+small list of functions.
+
+void emulate_domain_manager_set(u32 domain);
+int emulate_domain_manager_data_abort(u32 dfsr, u32 dfar);
+int emulate_domain_manager_prefetch_abort(u32 ifsr, u32 ifar);
+void emulate_domain_manager_switch_mm(
+ unsigned long pgd_phys,
+ struct mm_struct *mm,
+ void (*switch_mm)(unsigned long pgd_phys, struct mm_struct *));
+
+emulate_domain_manager_set() is the set_domain handler. This replaces the
+direct manipulation of CP15 dacr with a function call. This allows emulation
+to prevent setting dacr manager bits. It also allows emulation to restore
+page/section permissions when domain manger is disabled.
+
+emulate_domain_manager_data_abort() handles data aborts caused by domain
+not being set in HW, and handles section/page manipulation.
+
+emulate_domain_manager_prefetch_abort() is the similar prefetch abort handler.
+
+emulate_domain_manager_switch_mm() handles MMU table and context switches.
+This notifies the emulation that the MMU context is changing. Allowing the
+emulation to restore page table entry permission before switching contexts.
+
+
+Config options
+==============
+
+This option is enable/disable by the EMULATE_DOMAIN_MANAGER_V7 option.
+
+
+Dependencies
+============
+
+Implementation is for ARMv7, MMU, and !SMP. Targets solving issue for 8x50
+chipset.
+
+
+User space utilities
+====================
+
+None
+
+
+Other
+=====
+
+Code is implemented in kernel/arch/arm/mm.
+
+
+arch/arm/mm/emulate_domain_manager.c contains comments. No additional public
+documentation available or planned.
+
+
+Known issues
+============
+
+No intent to support SMP or non ARMv7 architectures
+
+
+To do
+=====
+
+None
+
diff --git a/Documentation/arm/msm/gpiomux.txt b/Documentation/arm/msm/gpiomux.txt
index 67a8162..aaf0793 100644
--- a/Documentation/arm/msm/gpiomux.txt
+++ b/Documentation/arm/msm/gpiomux.txt
@@ -2,112 +2,79 @@
is used to provide gpio pin multiplexing and configuration on mach-msm
targets.
-History
-=======
-
-The first-generation API for gpio configuration & multiplexing on msm
-is the function gpio_tlmm_config(). This function has a few notable
-shortcomings, which led to its deprecation and replacement by gpiomux:
-
-The 'disable' parameter: Setting the second parameter to
-gpio_tlmm_config to GPIO_CFG_DISABLE tells the peripheral
-processor in charge of the subsystem to perform a look-up into a
-low-power table and apply the low-power/sleep setting for the pin.
-As the msm family evolved this became problematic. Not all pins
-have sleep settings, not all peripheral processors will accept requests
-to apply said sleep settings, and not all msm targets have their gpio
-subsystems managed by a peripheral processor. In order to get consistent
-behavior on all targets, drivers are forced to ignore this parameter,
-rendering it useless.
-
-The 'direction' flag: for all mux-settings other than raw-gpio (0),
-the output-enable bit of a gpio is hard-wired to a known
-input (usually VDD or ground). For those settings, the direction flag
-is meaningless at best, and deceptive at worst. In addition, using the
-direction flag to change output-enable (OE) directly can cause trouble in
-gpiolib, which has no visibility into gpio direction changes made
-in this way. Direction control in gpio mode should be made through gpiolib.
-
-Key Features of gpiomux
-=======================
-
-- A consistent interface across all generations of msm. Drivers can expect
-the same results on every target.
-- gpiomux plays nicely with gpiolib. Functions that should belong to gpiolib
-are left to gpiolib and not duplicated here. gpiomux is written with the
-intent that gpio_chips will call gpiomux reference-counting methods
-from their request() and free() hooks, providing full integration.
-- Tabular configuration. Instead of having to call gpio_tlmm_config
-hundreds of times, gpio configuration is placed in a single table.
-- Per-gpio sleep. Each gpio is individually reference counted, allowing only
-those lines which are in use to be put in high-power states.
-- 0 means 'do nothing': all flags are designed so that the default memset-zero
-equates to a sensible default of 'no configuration', preventing users
-from having to provide hundreds of 'no-op' configs for unused or
-unwanted lines.
-
Usage
=====
-To use gpiomux, provide configuration information for relevant gpio lines
-in the msm_gpiomux_configs table. Since a 0 equates to "unconfigured",
-only those lines to be managed by gpiomux need to be specified. Here
-is a completely fictional example:
+To use gpiomux, do the following before the msmgpio gpiochips probe:
-struct msm_gpiomux_config msm_gpiomux_configs[GPIOMUX_NGPIOS] = {
- [12] = {
- .active = GPIOMUX_VALID | GPIOMUX_DRV_8MA | GPIOMUX_FUNC_1,
- .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
- },
- [34] = {
- .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
+- Call msm_gpiomux_init to allocate needed resources.
+- Install one or more sets of gpiomux configuration data via
+ msm_gpiomux_install and/or msm_gpiomux_write.
+
+Failing to finish these steps before the probe of msmgpio can result in calls
+from msmgpio to gpiomux to try and activate lines which have not yet
+been configured.
+
+A basic gpiomux setting is described by a gpiomux_setting structure.
+A gpiomux configuration is a group of those settings (one for each power
+state of the board) paired with a specific gpio, like so:
+
+struct msm_gpiomux_config gpio123_config __initdata = {
+ .gpio = 123,
+ .settings = {
+ [GPIOMUX_ACTIVE] = {
+ .func = GPIOMUX_FUNC_GPIO,
+ .drv = GPIOMUX_DRV_2MA,
+ .pull = GPIOMUX_PULL_NONE,
+ .dir = GPIOMUX_OUT_HIGH,
+ },
+ [GPIOMUX_SUSPENDED] = {
+ .func = GPIOMUX_FUNC_3,
+ .drv = GPIOMUX_DRV_8MA,
+ .pull = GPIOMUX_PULL_DOWN,
+ },
},
};
-To indicate that a gpio is in use, call msm_gpiomux_get() to increase
-its reference count. To decrease the reference count, call msm_gpiomux_put().
-
The effect of this configuration is as follows:
-When the system boots, gpios 12 and 34 will be initialized with their
-'suspended' configurations. All other gpios, which were left unconfigured,
-will not be touched.
+- When the system boots, gpio 123 will be put into the SUSPENDED setting.
+- When the reference count for gpio 123 rises above 0, the ACTIVE setting
+ will be applied.
+- When the reference count falls back to 0, the SUSPENDED setting will be
+ reapplied.
-When msm_gpiomux_get() is called on gpio 12 to raise its reference count
-above 0, its active configuration will be applied. Since no other gpio
-line has a valid active configuration, msm_gpiomux_get() will have no
-effect on any other line.
+The reference count rises when msm_gpiomux_get() is called and falls
+when msm_gpiomux_put() is called. msmgpio has hooks to these functions
+in its gpiolib implementation. This means that when you call gpio_request()
+on an msmgpio, msm_gpiomux_get() is automatically called on your behalf.
+Similarly, when you call gpio_free(), msm_gpiomux_put() is called for you.
+This allows generic drivers to obtain low-level management of msmgpio lines
+without having to be aware of the gpiomux layer.
-When msm_gpiomux_put() is called on gpio 12 or 34 to drop their reference
-count to 0, their suspended configurations will be applied.
-Since no other gpio line has a valid suspended configuration, no other
-gpio line will be effected by msm_gpiomux_put(). Since gpio 34 has no valid
-active configuration, this is effectively a no-op for gpio 34 as well,
-with one small caveat, see the section "About Output-Enable Settings".
+Note that the .dir field is ignored if .func != GPIOMUX_FUNC_GPIO, since
+software control of gpios is allowed only in GPIO mode. By selecting any
+other .func, you assign the gpio to another piece of hardware and lose
+control of it from gpiolib. You can still reserve such gpios with gpio_request
+to prevent other modules from using them while they're in such a state,
+but other gpiolib functions will not behave as you expect if .func != GPIO.
-All of the GPIOMUX_VALID flags may seem like unnecessary overhead, but
-they address some important issues. As unused entries (all those
-except 12 and 34) are zero-filled, gpiomux needs a way to distinguish
-the used fields from the unused. In addition, the all-zero pattern
-is a valid configuration! Therefore, gpiomux defines an additional bit
-which is used to indicate when a field is used. This has the pleasant
-side-effect of allowing calls to msm_gpiomux_write to use '0' to indicate
-that a value should not be changed:
-
- msm_gpiomux_write(0, GPIOMUX_VALID, 0);
-
-replaces the active configuration of gpio 0 with an all-zero configuration,
-but leaves the suspended configuration as it was.
+If a configuration is omitted, nothing will happen at the relevant transitions.
+This allows for the creation of 'static configurations' which do not
+change as the line is requested and freed.
Static Configurations
=====================
To install a static configuration, which is applied at boot and does
not change after that, install a configuration with a suspended component
-but no active component, as in the previous example:
+but no active component:
- [34] = {
- .suspended = GPIOMUX_VALID | GPIOMUX_PULL_DOWN,
+ .gpio = ...,
+ .settings = {
+ [GPIOMUX_SUSPENDED] = {
+ ...
+ },
},
The suspended setting is applied during boot, and the lack of any valid
@@ -153,24 +120,3 @@
This mechanism allows for "auto-request" of gpiomux lines via gpiolib
when it is suitable. Drivers wishing more exact control are, of course,
free to also use msm_gpiomux_set and msm_gpiomux_get.
-
-About Output-Enable Settings
-============================
-
-Some msm targets do not have the ability to query the current gpio
-configuration setting. This means that changes made to the output-enable
-(OE) bit by gpiolib cannot be consistently detected and preserved by gpiomux.
-Therefore, when gpiomux applies a configuration setting, any direction
-settings which may have been applied by gpiolib are lost and the default
-input settings are re-applied.
-
-For this reason, drivers should not assume that gpio direction settings
-continue to hold if they free and then re-request a gpio. This seems like
-common sense - after all, anybody could have obtained the line in the
-meantime - but it needs saying.
-
-This also means that calls to msm_gpiomux_write will reset the OE bit,
-which means that if the gpio line is held by a client of gpiolib and
-msm_gpiomux_write is called, the direction setting has been lost and
-gpiolib's internal state has been broken.
-Release gpio lines before reconfiguring them.
diff --git a/Documentation/arm/msm/kgsl-sysfs.txt b/Documentation/arm/msm/kgsl-sysfs.txt
new file mode 100644
index 0000000..c572312
--- /dev/null
+++ b/Documentation/arm/msm/kgsl-sysfs.txt
@@ -0,0 +1,98 @@
+This document lists details for the device specific sysfs attributes
+created by the KGSL GPU driver.
+
+- /sys/devices/platform/kgsl/vmalloc
+ The total amount of vmalloc()ed memory currently allocated by the driver
+ (in bytes)
+
+- /sys/devices/platform/kgsl/vmalloc_max
+ The maximum amount of vmalloc()ed memory allocated at any one
+ time by the driver since the system was booted (in bytes)
+
+- /sys/devices/platform/kgsl/coherent
+ The total amount of coherent DMA memory currently allocated by the driver
+ (in bytes)
+
+- /sys/devices/platform/kgsl/coherent_max
+ The maximum amount of coherent DMA memory allocated at any one
+ time by the driver since the system was booted (in bytes)
+
+
+- /sys/devices/platform/kgsl/histogram
+ A histogram of the sizes of vmalloc allocations by the driver
+ since the system was booted. The allocations are grouped by the order
+ of the allocation size in pages. For example, order 0 are 1 page
+ allocations, order 1 are 2 page allocations, order 2 are 4 page allocations,
+ and so forth, up to order 16 (32768) pages.
+
+- /sys/devices/platform/kgsl/proc
+ This directory contains individual entries for each active rendering
+ process. Rendering instances are created for each unique process that
+ opens the GPU devices, and are named for the id of the creating process.
+ In the driver, memory allocations are owned by the process that allocates
+ them, and outstanding memory is garbage collected when the process closes
+ the device.
+
+ - /sys/devices/platform/kgsl/proc/NN/vmalloc
+ The total amount of vmalloc memory currently allocated by the process
+ (in bytes)
+
+ - /sys/devices/platform/kgsl/proc/NN/vmalloc_max
+ The maximum amount of vmalloc memory allocated at any one
+ time by the process since it was created (in bytes)
+
+ - /sys/devices/platform/kgsl/proc/NN/exmem
+ The total amount of external memory devices currently mapped by the process
+ (in bytes). This includes PMEM, ASHMEM and external memory pointers from
+ userspace.
+
+ - /sys/devices/platform/kgsl/proc/NN/exmem_max
+ The maximum amount of external memory devices allocated at any one
+ time by the process since it was created (in bytes). This includes PMEM,
+ ASHMEM and external memory pointers from userspace.
+
+ - /sys/devices/platform/kgsl/proc/NN/flushes
+ The total number of cache flushes performed by this process since it
+ was created.
+
+- /sys/devices/platform/kgsl/pagetables
+ This directory contains individual entries for each active pagetable.
+ There will always be a global pagetable with ID 0. If per-process
+ pagetables are not enabled, pagetable ID 0 will also be the default
+ pagetable for all processes. If per-process pagetables are enabled,
+ there will be an entry for each pagetable, named after the ID of the
+ process that created it.
+
+ - /sys/devices/platform/kgsl/pagetables/NN/entries
+ The number of concurrent entries mapped in the GPU MMU.
+
+ - /sys/devices/platform/kgsl/pagetables/NN/mapped
+ The number of bytes currently mapped in the GPU MMU.
+
+ - /sys/devices/platform/kgsl/pagetables/NN/va_range
+ The virtual address size of the MMU pagetable (in bytes).
+
+ - /sys/devices/platform/kgsl/pagetables/NN/max_mapped
+ The maximum number of bytes concurrently mapped in the GPU MMU since
+ the pagetable was created.
+
+ - /sys/devices/platform/kgsl/pagetables/NN/max_entries
+ The maximum number of entries concurrently mapped in the GPU MMU since
+ the pagetable was created.
+
+- /sys/devices/platform/kgsl/msm_kgsl/
+ Each individual GPU device (2D or 3D) will have its own device node in
+ this directory. All platforms will have kgsl-3d0 (3D device), some
+ devices may have 1 2D device (kgsl-2d0) and others might add a second 2D
+ device (kgsl-2d1).
+
+ - /sys/devices/platform/kgsl/msm_kgsl/kgsl-XXX/pwrnap
+ Controls the system ability to nap (lightly sleep between frames). 1
+ indicates napping is enabled, 0 indicates it is disabled. Write a 1 or
+ a 0 to the file to control napping.
+
+ - /sys/devices/platform/kgsl/msm_kgsl/kgsl-XXX/gpuclk
+ Shows the last active requested speed of the GPU clock in HZ, does not
+ actually measure the current clock rate. Write a clock speed to the file
+ corresponding to a supported platform power level to change to that power
+ level. The bandwidth vote will also be adjusted.
diff --git a/Documentation/arm/msm/msm_rng-driver.txt b/Documentation/arm/msm/msm_rng-driver.txt
new file mode 100644
index 0000000..3e7d1e9
--- /dev/null
+++ b/Documentation/arm/msm/msm_rng-driver.txt
@@ -0,0 +1,75 @@
+Introduction:
+=============
+
+The msm_rng device driver handles random number generation
+using hardware present in MSM chipsets.
+
+Hardware description:
+=====================
+
+The supported hardware is a macro block within a system-on-a-chip (SoC).
+The hardware is pseudo random number generator (PRNG) with four oscillators
+setup with a linear feedback shift register (LFSR).
+The hardware must be initially configured once for normal operation and
+a 32bit FIFO is read to obtain hardware generated pseudo random numbers.
+Currently the driver configures the hardware registers during initialization
+and the future plan is to have the boot loader configure these registers and
+write lock them so only host OS can read them and the driver writes will be
+ignored.
+
+Software description
+====================
+
+The driver is based on the platform_driver model. It registers an entry,
+exit and probe functions. Once the probe function is called, the driver
+registers a callback function with the hwrng (Hardware Random Number Generator)
+subsystem that is called when the hardware device (i.e. /dev/hw_random) is
+requesting random data from this device.
+Once the callback is issued from the hwrng subsystem, the driver checks to
+make sure the hardware has random data available and determines the maximum
+data it can return and returns that much data back.
+
+Power Management
+================
+
+Initially, no services are provided in the area of power management.
+
+SMP/multi-core
+==============
+
+The locking mechanism for the hwrng operations is taken care of by the hwrng
+framework. There are no SMP situations within the driver that need addressing.
+
+Driver parameters
+=================
+
+This driver is built and statically linked into the kernel; therefore,
+there are no module parameters supported by this driver.
+
+There are no kernel command line parameters supported by this driver.
+
+Config options
+==============
+
+This driver is enabled by the kernel config option CONFIG_HW_RANDOM_MSM.
+The option CONFIG_HW_RANDOM_MSM depends on HW_RANDOM && ARCH_MSM.
+
+Dependencies:
+=============
+
+This driver depends on the HW_RANDOM subsystem to register with and get
+callbacks to request random data.
+
+User space utilities:
+=====================
+
+The driver alone does not feed random numbers into kernel but just provides a
+method to get random numbers to a known device (i.e. /dev/hw_random). A user-
+space utility is required to monitor the /dev/random device entropy pool and
+feed it from the /dev/hw_random device. This application also must perform some
+sort of sanity checking on the returned data to make sure the data is not all
+the same.
+
+There is currently a GPL v2 tool called rng-tools that has a daemon called,
+"rngd" that performs this functionality. There is also a test tool in this
+package that tests the whole random subsystem.
diff --git a/Documentation/arm/msm/pil.txt b/Documentation/arm/msm/pil.txt
new file mode 100644
index 0000000..5b0b527
--- /dev/null
+++ b/Documentation/arm/msm/pil.txt
@@ -0,0 +1,267 @@
+Introduction
+============
+
+The PIL (Peripheral Image Loader) driver loads peripheral images into memory
+and interfaces with the Peripheral Authentication Service (PAS) to
+authenticate and reset peripherals embedded in the SoC.
+
+The PAS could either be running under secure mode in the application
+processor (secure boot support) or be running as a non-secure kernel driver
+(non-secure boot support).
+
+The PIL driver also does housekeeping to handle cases where more than one
+client driver is using the same peripheral.
+
+Some examples of peripherals are modem, DSP and sensors.
+
+Hardware description
+====================
+
+The memory used by the peripherals for code and data storage will be
+accessible as normal memory to the application processor.
+
+The non-secure code (Linux kernel) will have read/write permissions to the
+peripheral memory by default.
+
+The PAS will have access to a MPU (memory protection unit) that can lock away
+the pages of memory from the Linux kernel. It will also have access to
+registers that can reset each peripheral.
+
+Software description
+====================
+
+The PAS provides the following three APIs:
+
+* Init image - Takes as input the peripheral id and firmware metadata and
+ returns a status indicating the authenticity of the firmware metadata. The
+ firmware metadata consists of a standard ELF32 header followed by a program
+ header table and an optional blob of data used to authenticate the metadata
+ and the rest of the firmware.
+
+* Verify segment - Takes as input the firmware segment id and the length of
+ the segment. Authenticates whatever amount (specified by the "length"
+ parameter) of the firmware segment that has been loaded and removes
+ non-secure mode read/write permissions for the pages belonging to the
+ firmware segment. Allows multiple calls for the same firmware segment to
+ allow partial loading and authentication.
+
+* Auth and Reset - Verifies all the necessary firmware segments have been
+ loaded and authenticated and then resets the peripheral.
+
+The user space is expected to provide the firmware metadata and firmware
+segments as separate files on persistent storage. See "Interface" section for
+further details.
+
+The PIL driver will use the request_firmware API provided by the Linux kernel
+to read the firmware and firmware metadata from persistent storage.
+
+When a client driver requests for a peripheral to be enabled, the PIL driver
+increments the reference count for that peripheral, loads the firmware
+metadata and calls the PAS Init Image API that initializes the authentication
+state machine using the firmware metadata.
+
+If the initialization succeeds, the PIL driver loads the appropriate firmware
+segments into their respective memory locations and call the PAS Verify
+segment API on each of the loaded segments to authenticate and lock it.
+
+After all the firmware segments have been successfully loaded and
+authenticated, the PAS Auth and Reset API is called to reset the peripheral
+and initiate its boot sequence.
+
+A peripheral enable request to the PIL driver will block until it succeeds
+(or fails) to initiate the peripheral boot sequence but will NOT block until
+the peripheral is ready. It is not possible to block until a peripheral is
+ready since the semantics of "ready" is subjective to the caller.
+
+The PIL driver will maintain a reference count for each of the peripherals.
+So, if a peripheral is already under use and another client driver requests
+for the peripheral to be enabled, the PIL driver will immediately return a
+value to indicate success.
+
+When all the client drivers of a particular peripheral no longer need the
+peripheral and the reference count reaches zero, the PIL driver can cleanly
+shut down the peripheral. Since a lot of drivers in their current state can't
+handle a peripheral restart, the PIL driver will never let the reference
+count go back to zero.
+
+All information about a peripheral, like firmware filenames, peripheral ID
+passed to PAS, etc, will be hard coded in the PIL driver.
+
+All the PIL APIs will execute in the context of the caller. This includes
+calls from the PIL driver to the PAS driver. The PAS driver might decide to
+switch into secure mode from a separate workqueue or in the same context as
+the caller, but that shouldn't have any implications for the PIL API callers
+since all the PIL APIs are blocking calls.
+
+Dependencies:
+-------------
+* Firmware class (CONFIG_FW_LOADER) for using the request_firmware API to
+ load firmware from persistent storage.
+* PAS to authenticate firmware and bring a peripheral out of reset.
+
+Error cases:
+------------
+The PIL driver could fail to enable a peripheral for several reasons like not
+having enough memory to load firmware and metadata, being unable to
+communicate with the PAS, the PAS returning with an error, etc. For all
+possible error cases, the PIL driver does not perform any retries and returns
+an appropriate error code. The client drivers should always check for success
+before trying to access the peripheral.
+
+Design
+======
+
+Design goals:
+-------------
+* The PIL driver must be agnostic to the actual format and method used to
+ authenticate the firmware.
+* Allow for future expansion to support demand loading of parts of firmware
+ for each peripheral.
+* Move most of the work into the preprocessing/building stage of the firmware.
+* Provide an API to the client drivers that absolves them from having to know
+ the structure or names of the firmware in persistent storage.
+* Handle multiple client drivers wanting to enable the same peripheral.
+
+
+Design reasons:
+---------------
+The user space is expected to provide the firmware metadata and segments as
+separate files for the following reasons:
+* Don't need to load the whole ELF file if the authentication info is
+ invalid.
+* Works better during low memory conditions since the amount of memory used
+ at any given instant when loading one segment at a time is smaller than
+ loading the whole ELF file.
+* Since an ELF segment in memory can be much bigger than on file, having a
+ flat binary would waste a lot of space due to zero-fills.
+* Allows for future enhancements to the loading procedure.
+
+Design tradeoffs:
+-----------------
+* With appropriate changes to the request_firmware API, the firmware blobs
+ could be directly loaded into the right memory location. But due to the
+ additional work and community approval that would be needed for modifying
+ the request_firmware API, we load the firmware blobs into kernel memory and
+ then copy them into the appropriate locations.
+
+Alternate designs:
+------------------
+One of the alternate designs that were considered required the firmware to be
+a flat binary. Although this design would simplify the PIL driver, it would
+result in the waste of a lot of persistent storage space (due to large
+zero-fills), prevent demand loading of segments in the future and use a lot
+more memory while loading the firmware.
+
+Software layering:
+------------------
+The peripheral authentication, reset and shutdown implementation is factored
+away into a Peripheral Authentication Service driver to allow the PIL driver
+to be agnostic of secure vs. non-secure boot and the mechanisms needed for
+communicating with any code that might be running in secure mode.
+
+Power Management
+================
+
+Some of the peripherals might support being turned off when not in use.
+Support for this might be disabled in the initial implementation of the PIL
+driver since many of the existing drivers can not handle peripheral restart.
+
+SMP/multi-core
+==============
+
+Will use mutexes to protected data that might be shared (reference count,
+etc).
+
+Security
+========
+
+The PIL driver must validate the physical memory addresses specified in the
+ELF and program header table before loading firmware segments to make sure
+it's not overwriting any memory used by the kernel and possibly PMEM regions
+(if it can be done without being an ugly hack). The PIL driver might need to
+maintain a white list or black list of physical memory address ranges to
+perform the address validation.
+
+Performance
+===========
+
+As mentioned in the design section, the loading of firmware segments is not
+optimal and has room for improvement.
+
+Interface
+=========
+
+In kernel APIs:
+void * pil_get(char *peripheral_name)
+ - Enables (if not already enabled) a peripheral and returns a handle
+ that can be used to disable the peripheral at a later time. If
+ peripheral can't be enabled successfully, then returns an error
+ (use IS_ERR) indicating the reason.
+
+void pil_put(void *peripheral_handle)
+ - Inform PIL that this client no longer needs the peripheral to be
+ active. Does not necessarily mean that the peripheral would be
+ disabled or powered off.
+
+
+User space APIs:
+All firmware must be located in the path that is expected by the hotplug (or
+compatible) daemon. A hotplug (or compatible) daemon should be running and be
+able to handle events from the kernel requesting for a firmware file.
+
+The basename of the firmware files will depend on the peripheral. For a given
+peripheral, the metadata filename should end with a ".mdt" and the firmware
+segment files should end with ".bXX" where XX denotes the index of the
+firmware segment starting from 0.
+
+Android hotplug compatible daemon expects the firmware files to be under
+/etc/firmware.
+
+Driver parameters
+=================
+
+No module or kernel command line parameters supported.
+
+Config options
+==============
+
+This driver is enabled using the MSM_PIL kernel config option and will
+depend on the CONFIG_FW_LOADER being available.
+
+Dependencies
+============
+
+Depends on firmware class module for the request_firmware API.
+
+Interacts with the PAS to authenticate the firmware and to initiate the boot
+sequence of a peripheral.
+
+Doesn't communicate with other processors since the secure code, if any, will
+be running on the application processor cores.
+
+User space utilities
+====================
+
+None.
+
+Other
+=====
+
+The firmware_class driver might be changed in the future to directly load the
+firmware into memory locations provided by the caller of request_firmware().
+
+Known issues
+============
+
+Since support for cleanly shutting down peripherals is yet to be added, the
+reference count of peripherals will never be allowed to go to zero once it
+becomes non-zero.
+
+To do
+=====
+
+* Add support for turning off peripherals when they are not in use.
+* Modify request_firmware() to directly copy firmware blobs into the
+ appropriate memory locations.
+* Add support for demand loading of firmware segments.
+* Add support for forced peripheral restarts.
diff --git a/Documentation/arm/msm/rpm.txt b/Documentation/arm/msm/rpm.txt
new file mode 100644
index 0000000..9c9511f
--- /dev/null
+++ b/Documentation/arm/msm/rpm.txt
@@ -0,0 +1,157 @@
+Introduction
+============
+
+Resource Power Manager (RPM)
+
+RPM is a dedicated hardware engine for managing shared SoC resources,
+which includes buses, clocks, power rails, etc. The goal of RPM is
+to achieve the maximum power savings while satisfying the SoC's
+operational and performance requirements. RPM accepts resource
+requests from multiple RPM masters. It arbitrates and aggregates the
+requests, and configures the shared resources. The RPM masters are
+the application processor, the modem processor, as well as some
+hardware accelerators.
+
+The RPM driver provides an API for interacting with RPM. Kernel code
+calls the RPM driver to request RPM-managed, shared resources.
+Kernel code can also register with the driver for RPM notifications,
+which are sent when the status of shared resources change.
+
+Hardware description
+====================
+
+RPM exposes a separate region of registers to each of the RPM masters.
+In general, each register represents some shared resource(s). At a
+very basic level, a master requests resources by writing to the
+registers, then generating an interrupt to RPM. RPM processes the
+request, writes acknowledgement to the registers, then generates an
+interrupt to the master.
+
+In addition to the master-specific regions, RPM also exposes a shared
+region that contains the current status of the shared resources. Only
+RPM can write to the status region, but every master can read from it.
+
+RPM contains internal logics that aggregate and arbitrate among
+requests from the various RPM masters. It interfaces with the PMIC,
+the bus arbitration block, and the clock controller block in order to
+configure the shared resources.
+
+Software description
+====================
+
+The RPM driver encapsulates the low level RPM interactions, which
+rely on reading/writing registers and generating/processing
+interrupts, and provides a higher level synchronuous set/clear/get
+interface. Most functions take an array of id-value pairs.
+The ids identify the RPM registers which would correspond to some
+RPM resources, the values specify the new resource values.
+
+The RPM driver synchronizes accesses to RPM. It protects against
+simultaneous accesses from multiple tasks, on SMP cores, in task
+contexts, and in atomic contexts.
+
+Design
+======
+
+Design goals:
+- Encapsulate low level RPM interactions.
+- Provide a synchronuous set/clear/get interface.
+- Synchronize simultaneous software accesses to RPM.
+
+Power Management
+================
+
+RPM is part of the power management architecture for MSM 8660. RPM
+manages shared system resources to lower system power.
+
+SMP/multi-core
+==============
+
+The RPM driver uses mutex to synchronize client accesses among tasks.
+It uses spinlocks to synchronize accesses from atomic contexts and
+SMP cores.
+
+Security
+========
+
+None.
+
+Performance
+===========
+
+None.
+
+Interface
+=========
+
+msm_rpm_get_status():
+The function reads the shared status region and returns the current
+resource values, which are the arbitrated/aggregated results across
+all RPM masters.
+
+msm_rpm_set():
+The function makes a resource request to RPM.
+
+msm_rpm_set_noirq():
+The function is similar to msm_rpm_set() except that it must be
+called with interrupts masked. If possible, use msm_rpm_set()
+instead, to maximize CPU throughput.
+
+msm_rpm_clear():
+The function makes a resource request to RPM to clear resource values.
+Once the values are cleared, the resources revert back to their default
+values for this RPM master. RPM internally uses the default values as
+the requests from this RPM master when arbitrating and aggregating with
+requests from other RPM masters.
+
+msm_rpm_clear_noirq():
+The function is similar to msm_rpm_clear() except that it must be
+called with interrupts masked. If possible, use msm_rpm_clear()
+instead, to maximize CPU throughput.
+
+msm_rpm_register_notification():
+The function registers for RPM notification. When the specified
+resources change their status on RPM, RPM sends out notifications
+and the driver will "up" the semaphore in struct
+msm_rpm_notification.
+
+msm_rpm_unregister_notification():
+The function unregisters a notification.
+
+msm_rpm_init():
+The function initializes the RPM driver with platform specific data.
+
+Driver parameters
+=================
+
+None.
+
+Config options
+==============
+
+MSM_RPM
+
+Dependencies
+============
+
+None.
+
+User space utilities
+====================
+
+None.
+
+Other
+=====
+
+None.
+
+Known issues
+============
+
+None.
+
+To do
+=====
+
+None.
diff --git a/Documentation/arm/msm/tsif.txt b/Documentation/arm/msm/tsif.txt
new file mode 100644
index 0000000..9f6827c
--- /dev/null
+++ b/Documentation/arm/msm/tsif.txt
@@ -0,0 +1,231 @@
+TSIF driver serves piece of hardware found in Qualcomm MSM's.
+It deals with Digital Mobile Broadcast.
+
+If you are dealing with Qualcomm MSM that have relevant piece of hardware,
+read on.
+
+There are various Digital Mobile Broadcast (DMB) systems developed to receive
+audio and/or television broadcast programs by Mobile Station Modem (MSM).
+(in simplified words - cellular phone)
+
+All of these systems have similar architecture. They use radio link which
+is different from primary handset link and hence use the additional antenna.
+RF signal from the broadcast tuner goes to de-modulator.
+Regardless of actual tuner and de-modulator, all systems present
+ITU-T H.222.0 (also known as MPEG2) Transport Stream (HTS)
+to the Mobile Station Modem (MSM).
+
+TSIF stands for Transport Stream Interface;
+this is hardware block in MSM that receives HTS signal from the de-modulator.
+
+TSIF use serial interface with de-modulator;
+it buffers data received in internal registers.
+TSIF support data copying from its internal registers to the RAM
+with the Data Mover (DM).
+
+TSIF driver prevent MSM from sleeping while TSIF hardware is active.
+To achieve this, driver holds wake lock.
+
+For access to TSIF data, TSIF driver provides kernel API
+that may be used by another kernel module. As example for API usage,
+simple TSIF chardev adapter provided. It provides character device
+/dev/tsif0. This device may be opened by single process at a time.
+When read, it provides TS stream.
+
+Quick start:
+
+### copy modules to the target
+adb push msm_tsif.ko /data/local/tmp/
+adb push tsif_chrdev.ko /data/local/tmp/
+### Load modules on the target:
+adb shell mount -t debugfs debugfs /sys/kernel/debug
+adb shell insmod /data/local/tmp/msm_tsif.ko
+adb shell insmod /data/local/tmp/tsif_chrdev.ko
+### Run capture:
+adb shell cat /dev/tsif0 > /data/local/tmp/tsif.dump
+
+
+# tests:
+adb shell mount -t debugfs debugfs /sys/kernel/debug
+adb shell rmmod tsif_chrdev
+adb shell rmmod msm_tsif
+adb shell insmod /data/local/tmp/msm_tsif.ko
+adb shell insmod /data/local/tmp/tsif_chrdev.ko
+adb shell 'echo 60 > /sys/devices/platform/msm_tsif.0/time_limit'
+adb shell 'echo "16 * 8" > /sys/devices/platform/msm_tsif.0/buf_config'
+
+# separate xterm:
+watch adb shell cat /sys/devices/platform/msm_tsif.0/stats
+# separate xterm:
+watch adb shell cat /sys/kernel/debug/msm_tsif.0/dma
+# separate xterm:
+adb shell dd if=/dev/tsif0 of=/dev/null
+
+Mode of operation
+
+TSIF hardware have 2 modes of operation: mode1 and mode 2.
+They differ in serial interface signals. Mode used should match demodulator
+chip interface.
+
+In addition to these 2 modes of operation, TSIF driver have pseudo-mode 3
+that means "debug mode" where all operation controlled through debug interfaces.
+Client configure TSIF mode of operation using tsif_set_mode().
+Alternatively, mode of operation may be configured using device attribute file:
+echo 1 > /sys/devices/platform/msm_tsif.0/mode
+
+Time limit
+
+TSIF driver maintains time limit value. Its value corresponds
+to the TSIF_TIME_LIMIT register in TSIF hardware.
+Value in ticks of tsif_ref_clk. If time between the end of previous
+packet and end of current one exceeds this value, timeout status reported
+for the current TSIF packet.
+Client configure TSIF time limit using tsif_set_time_limit().
+Alternatively, time limit may be configured using device attribute file:
+echo 100 > /sys/devices/platform/msm_tsif.0/time_limit
+
+TSIF packet format
+
+TSIF driver uses 192 byte packets; where first 188 packets is HTS packet;
+last 4 bytes consists of :
+3 bytes TTS in bytes 188..190; and status byte ib byte 191.
+
+Status byte contains the following fields:
+Bit Name Comment
+0 Valid Always set to 1 to indicate valid HTS packet and status.
+ If set to 0, this packet is not valid and should be ignored
+1 First packet When set, indicates 1-st packet of a new stream or
+ 1-st valid packet after one or more packets were lost.
+2 Overflow When set, indicates overflow condition in TSIF hardware;
+ one or more packets were lost. Current packet is valid.
+3 Error Indicates the tsif_error signal status
+4 Null Indicates the tsif_null signal status
+5 Reserved Don't care
+6 Timeout Indicates the 1-st packet after timeout.
+ First packet flag will also be set.
+
+Debug facilities
+
+TSIF driver provides extensive debugging facilities to assist debug both
+TSIF input and TSIF client interfaces. 2 mechanisms used:
+
+Device attribute, accessible through usual /sys hierarchy under
+/sys/devices/platform/msm_tsif.0, provides status and statistics information.
+
+Debugfs exposes more hardware and software details. In order to use debugfs,
+one need to mount it:
+
+adb shell mount -t debugfs debugfs /sys/kernel/debug
+
+When debugfs mounted, TSIF entries may be found under
+/sys/kernel/debug/msm_tsif.0
+
+Register access
+
+All TSIF hardware registers accessible through debugfs.
+$ adb shell ls -l /sys/kernel/debug/msm_tsif.0
+-r--r--r-- root root 0 1980-01-07 16:15 dma
+--w------- root root 0 1980-01-07 16:15 action
+-r--r--r-- root root 0 1980-01-07 16:15 gpios
+-r-------- root root 0 1980-01-07 16:15 data_port
+-r--r--r-- root root 0 1980-01-07 16:15 test_current
+-rw-r--r-- root root 0 1980-01-07 16:15 test_export
+--w------- root root 0 1980-01-07 16:15 test_reset
+-rw-r--r-- root root 0 1980-01-07 16:15 test_mode
+-rw-r--r-- root root 0 1980-01-07 16:15 test_ctl
+-rw-r--r-- root root 0 1980-01-07 16:15 lpbk_data
+-rw-r--r-- root root 0 1980-01-07 16:15 lpbk_flags
+-rw-r--r-- root root 0 1980-01-07 16:15 clk_ref
+-rw-r--r-- root root 0 1980-01-07 16:15 time_limit
+-rw-r--r-- root root 0 1980-01-07 16:15 sts_ctl
+
+TSIF clocks are off when TSIF is not running.
+To control TSIF through low level register access, it should be set to the
+mode 3 ("debug"); in addition, TSIF start/stop actions may be executed using
+debugfs action file:
+
+adb shell 'echo open > /sys/kernel/debug/msm_tsif.0/action'
+
+Possible actions are "open" and "close".
+
+DMA activity
+
+DMA activity may be queried using debugfs dma file:
+
+$ adb shell cat /sys/kernel/debug/msm_tsif.0/dma
+ri 16 | wi 24 | dmwi 40 | [ 24]{ 32} [ 32]{ 40}
+
+This file provides ri/wi/dmwi indexes
+(dmwi is for Data Mover write index - index for first location where
+next DMA may be scheduled);
+and 2 Data Mover transfer tasks, each in [wi] {next_wi} format.
+Here, wi is index DMA is scheduled for; next_wi is where driver's
+wi will be set after DMA completion.
+
+Driver status
+
+Driver status available through stats device attribute:
+
+$ adb shell cat /sys/devices/platform/msm_tsif.0/stats
+Device msm_tsif.0
+Mode = 1
+Time limit = 60
+State running
+Client = bf036f68
+Pkt/Buf = 64
+Pkt/chunk = 8
+--statistics--
+Rx chunks = 3288898
+Overflow = 4606
+Lost sync = 0
+Timeout = 1
+DMA error = 0
+Soft drop = 0
+IFI = 48
+--debug--
+GLBL_CLK_ENA = 0x637dfe23
+ROW_RESET = 0x000008c1
+CLK_HALT_STATEB = 0xde6d80ff
+TV_NS_REG = 0xf8e00b44
+TSIF_NS_REG = 0x00000b40
+
+GPIO
+
+Current GPIO values may be read using debugfs gpio file:
+$ adb shell cat /sys/kernel/debug/msm_tsif.0/gpios
+ tsif_clk: 0
+ tsif_en: 0
+ tsif_data: 0
+ tsif_sync: 0
+
+In normal regime, signals changed too fast for this facility to provide
+change by change log; it should be seen as random time capture.
+When debugging TSIF input connectivity, it may be helpful to run
+
+watch -d adb shell cat /sys/kernel/debug/msm_tsif.0/gpios
+
+to see if input ever changes. If nothing changes at all; it is indication
+for mis-configured input.
+
+Another tip: in case of wire connection between components, one may connect
+TSIF input pin to logical 1 instead of actual signal source,
+to verify this is the pin required.
+
+Inter frame interval
+
+To estimate incoming bit rate, TSIF driver measure average time interval
+between packets. Interval measured in tsif_ref_clk ticks. Actually, TSIF
+gets TTS from 1-st and last packets in chunk and use this time to calculate
+inter frame interval.
+Inter frame interval available as part of device statistics.
+
+Tip: to measure tsif_ref_clk frequency, this approach may be used:
+
+adb shell cat /sys/kernel/debug/msm_tsif.0/clk_ref; sleep 10; adb shell cat /sys/kernel/debug/msm_tsif.0/clk_ref
+0x8db70ec8
+0x8dc6974b
+
+Then, calculate (0x8dc6974b - 0x8db70ec8)/10 that is 101798.7 Hz
+
+
+
diff --git a/Documentation/crypto/msm/qce.txt b/Documentation/crypto/msm/qce.txt
new file mode 100644
index 0000000..18435d1
--- /dev/null
+++ b/Documentation/crypto/msm/qce.txt
@@ -0,0 +1,228 @@
+Introduction:
+=============
+
+The Qualcomm crypto engine (qce) driver is a module that
+provides common services for accessing the Qualcomm crypto device.
+Currently, the two main clients of qce are
+-qcrypto driver (module provided for accessing CE HW by kernel space apps)
+-qcedev driver (module provided for accessing CE HW by user space apps)
+
+
+The crypto engine (qce) driver is a client to the DMA driver for the Qualcomm
+DMA device - Application Data Mover (ADM). ADM is used to provide the DMA
+transfer capability between Qualcomm crypto device hardware and DDR memory
+for crypto operations.
+
+ Figure 1.
+ ---------
+
+ Linux kernel
+ (ex:IPSec)<--*Qualcomm crypto driver----+
+ (qcrypto) |
+ (for kernel space app) |
+ |
+ +-->|
+ |
+ | *qce <----> Qualcomm
+ | driver ADM driver <---> ADM HW
+ +-->| | |
+ | | |
+ | | |
+ | | |
+ Linux kernel | | |
+ misc device <--- *QCEDEV Driver-------+ | |
+ interface (qcedev) (Reg interface) (DMA interface)
+ (for user space app) \ /
+ \ /
+ \ /
+ \ /
+ \ /
+ \ /
+ \ /
+ Qualcomm crypto CE3 HW
+
+
+ The entities marked with (*) in the Figure 1, are the software components of
+ the Linux Qualcomm crypto modules.
+
+===============
+IMPORTANT NOTE:
+===============
+(1) The CE hardware can be accessed either from user space OR kernel space,
+ at one time. Both user space and kernel space clients cannot access the
+ qce driver (and the CE hardware) at the same time.
+ - If your device has user space apps that needs to access the crypto
+ hardware, make sure to have the qcrypto module disabled/unloaded.
+ This will result in the kernel space apps to use the registered
+ software implementation of the crypto algorithms.
+ - If your device has kernel space apps that needs to access the
+ crypto hardware, make sure to have qcedev module disabled/unloaded
+ and implement your user space application to use the software
+ implemenation (ex: openssl/crypto) of the crypto algorithms.
+
+(2) If your device has Playready(Windows Media DRM) application enabled and
+ uses the qcedev module to access the crypto hardware accelarator,
+ please be informed that for performance reasons, the CE hardware will need
+ to be dedicated to playready application. Any other user space application
+ should be implemented to use the software implemenation (ex: openssl/crypto)
+ of the crypto algorithms.
+
+
+Hardware description:
+=====================
+
+Qualcomm Crypto HW device family provides a series of algorithms implemented
+in the device hardware.
+
+Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES
+algorithms, and concurrent operations of hashing, and ciphering.
+
+In addition to those functions provided by Crypto 2 HW, Crypto 3 HW provides
+fast AES algorithms.
+
+In addition to those functions provided by Crypto 3 HW, Crypto 3E provides
+HMAC-SHA1 hashing algorithm, and Over The Air (OTA) f8/f9 algorithms as
+defined by the 3GPP forum.
+
+
+Software description
+====================
+
+The crypto device is defined as a platform device. The driver is
+independent of the platform. The driver supports multiple instances of
+crypto HW.
+All the platform specific parameters are defined in the board init
+file, eg. arch/arm/mach-msm/board-msm7x30.c for MSM7x30.
+
+The qce driver provide the common services of HW crypto
+access to the two drivers as listed above (qcedev, qcrypto. It sets up
+the crypto HW device for the operation, then it requests ADM driver for
+the DMA of the crypto operation.
+
+Two ADM channels and two command lists (one command list for each
+channel) are involved in an operation.
+
+The setting up of the command lists and the procedure of the operation
+of the crypto device are described in the following sections.
+
+The command list for the first DMA channel is set up as follows:
+
+ 1st command of the list is for the DMA transfer from DDR memory to the
+ crypto device to input data to crypto device. The dst crci of the command
+ is set for crci-in for this crypto device.
+
+ 2nd command is for the DMA tansfer is from crypto device to DDR memory for
+ the authentication result. The src crci is set as crci-hash-done of the
+ crypto device. If authentication is not required in the operation,
+ the 2nd command is not used.
+
+The command list for the second DMA channel is set up as follows:
+
+ One command to DMA data from crypto device to DDR memory for encryption or
+ decryption output from crypto device.
+
+To accomplish ciphering and authentication concurrent operations, the driver
+performs the following steps:
+ (a). set up HW crypto device
+ (b). hit the crypto go register.
+ (c). issue the DMA command of first channel to the ADM driver,
+ (d). issue the DMA command of 2nd channel to the ADM driver.
+
+SHA1/SHA256 is an authentication/integrity hash algorithm. To accomplish
+hash operation (or any authentication only algorithm), 2nd DMA channel is
+not required. Only steps (a) to (c) are performed.
+
+At the completion of the DMA operation (for (c) and (d)) ADM driver
+invokes the callback registered to the DMA driver. This signifies the end of
+the DMA operation(s). The driver reads the status and other information from
+the CE hardware register and then invokes the callback to the qce driver client.
+This signal the completion and the results of the DMA along with the status of
+the CE hardware to the qce driver client. This completes a crypto operation.
+
+In the qce driver initialization, memory for the two command lists, descriptor
+lists for each crypto device are allocated out of coherent memory, using Linux
+DMA API. The driver pre-configures most of the two ADM command lists
+in the initialization. During each crypto operation, minimal set up is required.
+src_dscr or/and dst_dscr descriptor list of the ADM command are populated
+from the information obtained from the corresponding data structure. eg: for
+AEAD request, the following data structure provides the information:
+
+ struct aead_request *req
+ ......
+ req->assoc
+ req->src
+ req->dst
+
+The DMA address of a scatter list will be retrieved and set up in the
+descriptor list of an ADM command.
+
+Power Management
+================
+ none
+
+
+Interface:
+==========
+
+The interface is defined in kernel/drivers/crypto/msm/inc/qce.h
+
+The clients qcrypto, qcedev drivers are the clients using
+the interfaces.
+
+The following services are provided by the qce driver -
+
+ qce_open(), qce_close(), qce_ablk_cipher_req(),
+ qce_hw_support(), qce_process_sha_req()
+
+ qce_open() is the first request from the client, ex. Qualcomm crypto
+ driver (qcedev, qcrypto), to open a crypto engine. It is normally
+ called at the probe function of the client for a device. During the
+ probe,
+ - ADM command list structure will be set up
+ - Crypto device will be initialized.
+ - Resource associated with the crypto engine is retrieved by doing
+ platform_get_resource() or platform_get_resource_byname().
+
+ The resources for a device are
+ - crci-in, crci-out, crci-hash-done
+ - two DMA channel IDs, one for encryption and decryption input, one for
+ output.
+ - base address of the HW crypto device.
+
+ qce_close() is the last request from the client. Normally, it is
+ called from the remove function of the client.
+
+ qce_hw_support() allows the client to query what is supported
+ by the crypto engine hardware.
+
+ qce_ablk_cipher_req() provides ciphering service to the client.
+ qce_process_sha_req() provide hashing service to the client.
+ qce_aead_req() provide aead service to the client.
+
+Module parameters:
+==================
+
+The following module parameters are defined in the board init file.
+-CE hardware nase register address
+-Data mover channel used for transfer to/from CE hardware
+These parameters differ in each platform.
+
+
+Dependencies:
+=============
+
+Existing DMA driver.
+The transfers are DMA'ed between the crypto hardware and DDR memory via the
+data mover, ADM. The data transfers are set up to use the existing dma driver.
+
+User space utilities:
+=====================
+ n/a
+
+Known issues:
+=============
+ n/a
+
+To do:
+======
+ n/a
diff --git a/Documentation/crypto/msm/qce40.txt b/Documentation/crypto/msm/qce40.txt
new file mode 100644
index 0000000..e99f7d7
--- /dev/null
+++ b/Documentation/crypto/msm/qce40.txt
@@ -0,0 +1,241 @@
+Introduction:
+=============
+
+The Qualcomm crypto engine (qce40) driver is a module that
+provides common services for accessing the Qualcomm crypto device.
+Currently, the two main clients of qce40 are
+-qcrypto driver (module provided for accessing CE HW by kernel space apps)
+-qcedev driver (module provided for accessing CE HW by user space apps)
+This module provides the same interface to the clients as does qce.c and is
+based off qce.c. Following are the updates from qce.c
+- Add support for AES XTS mode
+- Add support for CMAC mode
+- Add support for AES CCM mode
+- Add support for SHA1/SHA256 HMAC
+- Read HASH/MAC information directly from CE hardware registers instead of
+ using datamover.
+
+The crypto engine (qce40) module is a client to the DMA driver for the Qualcomm
+DMA device - Application Data Mover (ADM). ADM is used to provide the DMA
+transfer capability between Qualcomm crypto device hardware and DDR memory
+for crypto operations.
+
+ Figure 1.
+ ---------
+
+ Linux kernel
+ (ex:IPSec)<--*Qualcomm crypto driver----+
+ (qcrypto) |
+ (for kernel space app) |
+ |
+ +-->|
+ |
+ | *qce40 <----> Qualcomm
+ | driver ADM driver <---> ADM HW
+ +-->| | |
+ | | |
+ | | |
+ | | |
+ Linux kernel | | |
+ misc device <--- *QCEDEV Driver-------+ | |
+ interface (qcedev) (Reg interface) (DMA interface)
+ (for user space app) \ /
+ \ /
+ \ /
+ \ /
+ \ /
+ \ /
+ \ /
+ Qualcomm crypto CE3 HW
+
+
+ The entities marked with (*) in the Figure 1, are the software components of
+ the Linux Qualcomm crypto modules.
+
+===============
+IMPORTANT NOTE:
+===============
+(1) The CE hardware can be accessed either from user space OR kernel space,
+ at one time. Both user space and kernel space clients cannot access the
+ qce driver (and the CE hardware) at the same time.
+ - If your device has user space apps that needs to access the crypto
+ hardware, make sure to have the qcrypto module disabled/unloaded.
+ This will result in the kernel space apps to use the registered
+ software implementation of the crypto algorithms.
+ - If your device has kernel space apps that needs to access the
+ crypto hardware, make sure to have qcedev module disabled/unloaded
+ and implement your user space application to use the software
+ implemenation (ex: openssl/crypto) of the crypto algorithms.
+
+(2) If your device has Playready(Windows Media DRM) application enabled and
+ uses the qcedev module to access the crypto hardware accelarator,
+ please be informed that for performance reasons, the CE hardware will need
+ to be dedicated to playready application. Any other user space application
+ should be implemented to use the software implemenation (ex: openssl/crypto)
+ of the crypto algorithms.
+
+
+Hardware description:
+=====================
+
+Qualcomm Crypto HW device family provides a series of algorithms implemented
+in the device hardware.
+
+Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES
+algorithms, and concurrent operations of hashing and ciphering.
+
+In addition to those functions provided by Crypto 2 HW, Crypto 3 HW provides
+fast AES algorithms.
+
+In addition to those functions provided by Crypto 3 HW, Crypto 3E provides
+HMAC-SHA1 hashing algorithm, and Over The Air (OTA) f8/f9 algorithms as
+defined by the 3GPP forum.
+
+
+Software description
+====================
+
+The crypto device is defined as a platform device. The driver is
+independent of the platform. The driver supports multiple instances of
+crypto HW.
+All the platform specific parameters are defined in the board init
+file, eg. arch/arm/mach-msm/board-msm8960.c for MSM8960.
+
+The qce40 driver provide the common services of HW crypto
+access to the two drivers as listed above (qcedev, qcrypto. It sets up
+the crypto HW device for the operation, then it requests ADM driver for
+the DMA of the crypto operation.
+
+Two ADM channels and two command lists (one command list for each
+channel) are involved in an operation.
+
+The setting up of the command lists and the procedure of the operation
+of the crypto device are described in the following sections.
+
+The command lists contains a single command. For the first DMA channel it
+is set up as follows:
+
+ The command is for the DMA transfer from DDR memory to the
+ crypto device to input data to crypto device. The dst crci of the command
+ is set for crci-in for this crypto device.
+
+The command list for the second DMA channel is set up as follows:
+
+ One command to DMA data from crypto device to DDR memory for encryption or
+ decryption output from crypto device.
+
+To accomplish ciphering and authentication concurrent operations, the driver
+performs the following steps:
+ (a). set up HW crypto device
+ (b). hit the crypto go register.
+ (c). issue the DMA command of first channel to the ADM driver,
+ (d). issue the DMA command of 2nd channel to the ADM driver.
+
+SHA1/SHA256 is an authentication/integrity hash algorithm. To accomplish
+hash operation (or any authentication only algorithm), 2nd DMA channel is
+not required. Only steps (a) to (c) are performed.
+
+At the completion of the DMA operation (for (c) and (d)) ADM driver
+invokes the callback registered to the DMA driver. This signifies the end of
+the DMA operation(s). The driver reads the status and other information from
+the CE hardware register. For HASH functions (SHA1/SHA256, HMAC, CMAC and
+CCM) were the MAC/HASH information is read off hardware registers.
+
+[ NOTE: This is different from what is done in the qce module that support
+CE3.x hardware. In CE4.0 there is not CRCI_HASH and hence we cannot rely
+on the data mover to populate the HMAC/SHA information. This information
+is acquired fromte h ahrdware by reading directly from some registers that
+hold this information ]
+
+The driver than nvokes the callback to the qce driver client.
+This signal the completion and the results of the DMA along with the status of
+the CE hardware to the qce40 driver client. This completes a crypto operation.
+
+In the qce40 driver initialization, memory for the two command lists, descriptor
+lists for each crypto device are allocated out of coherent memory, using Linux
+DMA API. The driver pre-configures most of the two ADM command lists
+in the initialization. During each crypto operation, minimal set up is required.
+src_dscr or/and dst_dscr descriptor list of the ADM command are populated
+from the information obtained from the corresponding data structure. eg: for
+AEAD request, the following data structure provides the information:
+
+ struct aead_request *req
+ ......
+ req->assoc
+ req->src
+ req->dst
+
+The DMA address of a scatter list will be retrieved and set up in the
+descriptor list of an ADM command.
+
+Power Management
+================
+ none
+
+
+Interface:
+==========
+
+The interface is defined in kernel/drivers/crypto/msm/inc/qce.h
+
+The clients qcrypto, qcedev drivers are the clients using
+the interfaces.
+
+The following services are provided by the qce driver -
+
+ qce_open(), qce_close(), qce_ablk_cipher_req(),
+ qce_hw_support(), qce_process_sha_req()
+
+ qce_open() is the first request from the client, ex. Qualcomm crypto
+ driver (qcedev, qcrypto), to open a crypto engine. It is normally
+ called at the probe function of the client for a device. During the
+ probe,
+ - ADM command list structure will be set up
+ - Crypto device will be initialized.
+ - Resource associated with the crypto engine is retrieved by doing
+ platform_get_resource() or platform_get_resource_byname().
+
+ The resources for a device are
+ - crci-in, crci-out, crci-hash-done
+ - two DMA channel IDs, one for encryption and decryption input, one for
+ output.
+ - base address of the HW crypto device.
+
+ qce_close() is the last request from the client. Normally, it is
+ called from the remove function of the client.
+
+ qce_hw_support() allows the client to query what is supported
+ by the crypto engine hardware.
+
+ qce_ablk_cipher_req() provides ciphering service to the client.
+ qce_process_sha_req() provides hashing service to the client.
+ qce_aead_req() provides aead service to the client.
+
+
+Module parameters:
+==================
+
+The following module parameters are defined in the board init file.
+-CE hardware base register address
+-Data mover channel used for transfer to/from CE hardware
+These parameters differ in each platform.
+
+
+Dependencies:
+=============
+
+Existing DMA driver.
+The transfers are DMA'ed between the crypto hardware and DDR memory via the
+data mover, ADM. The data transfers are set up to use the existing dma driver.
+
+User space utilities:
+=====================
+ n/a
+
+Known issues:
+=============
+ n/a
+
+To do:
+======
+ n/a
diff --git a/Documentation/crypto/msm/qcedev.txt b/Documentation/crypto/msm/qcedev.txt
new file mode 100644
index 0000000..fde69bb
--- /dev/null
+++ b/Documentation/crypto/msm/qcedev.txt
@@ -0,0 +1,232 @@
+Introduction:
+=============
+
+This driver provides IOCTLS for user space application to access crypto
+engine hardware for the qcedev crypto services. The driver supports the
+following crypto algorithms
+- AES-128, AES-256 (ECB, CBC and CTR mode)
+- AES-192, (ECB, CBC and CTR mode)
+ (support exists on platform supporting CE 3.x hardware)
+- SHA1/SHA256
+- AES-128, AES-256 (XTS), AES CMAC, SHA1/SHA256 HMAC
+ (support exists on platform supporting CE 4.x hardware)
+
+Hardware description:
+=====================
+Crypto 3E provides cipher and hash algorithms as defined in the
+3GPP forum specifications.
+
+
+Software description
+====================
+
+The driver is a Linux platform device driver. For an msm target,
+there can be multiple crypto devices assigned for QCEDEV.
+
+The driver is a misc device driver as well.
+The following operations are registered in the driver,
+-qcedev_ioctl()
+-qcedev_open()
+-qcedev_release()
+
+The following IOCTLS are available to the user space application(s)-
+
+ Cipher IOCTLs:
+ --------------
+ QCEDEV_IOCTL_ENC_REQ is for encrypting data.
+ QCEDEV_IOCTL_DEC_REQ is for decrypting data.
+
+ Hashing/HMAC IOCTLs
+ -------------------
+
+ QCEDEV_IOCTL_SHA_INIT_REQ is for initializing a hash/hmac request.
+ QCEDEV_IOCTL_SHA_UPDATE_REQ is for updating hash/hmac.
+ QCEDEV_IOCTL_SHA_FINAL_REQ is for ending the hash/mac request.
+ QCEDEV_IOCTL_GET_SHA_REQ is for retrieving the hash/hmac for data
+ packet of known size.
+ QCEDEV_IOCTL_GET_CMAC_REQ is for retrieving the MAC (using AES CMAC
+ algorithm) for data packet of known size.
+
+The requests are synchronous. The driver will put the process to
+sleep, waiting for the completion of the requests using wait_for_completion().
+
+Since the requests are coming out of user space application, before giving
+the requests to the low level qce driver, the ioctl requests and the
+associated input/output buffer will have to be safe checked, and copied
+to/from kernel space.
+
+The extra copying of requests/buffer can affect the performance. The issue
+with copying the data buffer is resolved by having the client use PMEM
+allocated buffers.
+
+NOTE: Using memory allocated via PMEM is supported only for in place
+ operations where source and destination buffers point to the same
+ location. Support for different source and destination buffers
+ is not supported currently.
+ Furthermore, when using PMEM, and in AES CTR mode, when issuing an
+ encryption or decryption request, a non-zero byteoffset is not
+ supported.
+
+The design of the driver is to allow multiple open, and multiple requests
+to be issued from application(s). Therefore, the driver will internally queue
+the requests, and serialize the requests to the low level qce (or qce40) driver.
+
+On an IOCTL request from an application, if there is no outstanding
+request, a the driver will issue a "qce" request, otherwise,
+the request is queued in the driver queue. The process is suspended
+waiting for completion.
+
+On completion of a request by the low level qce driver, the internal
+tasklet (done_tasklet) is scheduled. The sole purpose of done_tasklet is
+to call the completion of the current active request (complete()), and
+issue more requests to the qce, if any.
+When the process wakes up from wait_for_completion(), it will collect the
+return code, and return the ioctl.
+
+A spin lock is used to protect the critical section of internal queue to
+be accessed from multiple tasks, SMP, and completion callback
+from qce.
+
+The driver maintains a set of statistics using debug fs. The files are
+in /debug/qcedev/stats1, /debug/qcedev/stats2, /debug/qcedev/stats3;
+one for each instance of device. Reading the file associated with
+a device will retrieve the driver statistics for that device.
+Any write to the file will clear the statistics.
+
+
+Power Management
+================
+n/a
+
+
+Interface:
+==========
+
+Linux user space applications will need to open a handle
+(file desrciptor) to the qcedev device. This is achieved by doing
+the following to retrieve a file desrciptor to the device.
+
+ fd = open("/dev/qce", O_RDWR);
+ ..
+ ioctl(fd, ...);
+
+Once a valid fd is retrieved, user can call the following ioctls with
+the fd as the first parameter and a pointer to an appropriate data
+structure, qcedev_cipher_op_req or qcedev_sha_op_req (depending on
+cipher/hash functionality) as the second parameter.
+
+The following IOCTLS are available to the user space application(s)-
+
+ Cipher IOCTLs:
+ --------------
+ QCEDEV_IOCTL_ENC_REQ is for encrypting data.
+ QCEDEV_IOCTL_DEC_REQ is for decrypting data.
+
+ The caller of the IOCTL passes a pointer to the structure shown
+ below, as the second parameter.
+
+ struct qcedev_cipher_op_req {
+ int use_pmem;
+ union{
+ struct qcedev_pmem_info pmem;
+ struct qcedev_vbuf_info vbuf;
+ };
+ uint32_t entries;
+ uint32_t data_len;
+ uint8_t in_place_op;
+ uint8_t enckey[QCEDEV_MAX_KEY_SIZE];
+ uint32_t encklen;
+ uint8_t iv[QCEDEV_MAX_IV_SIZE];
+ uint32_t ivlen;
+ uint32_t byteoffset;
+ enum qcedev_cipher_alg_enum alg;
+ enum qcedev_cipher_mode_enum mode;
+ enum qcedev_oper_enum op;
+ };
+
+ Hashing/HMAC IOCTLs
+ -------------------
+
+ QCEDEV_IOCTL_SHA_INIT_REQ is for initializing a hash/hmac request.
+ QCEDEV_IOCTL_SHA_UPDATE_REQ is for updating hash/hmac.
+ QCEDEV_IOCTL_SHA_FINAL_REQ is for ending the hash/mac request.
+ QCEDEV_IOCTL_GET_SHA_REQ is for retrieving the hash/hmac for data
+ packet of known size.
+ QCEDEV_IOCTL_GET_CMAC_REQ is for retrieving the MAC (using AES CMAC
+ algorithm) for data packet of known size.
+
+ The caller of the IOCTL passes a pointer to the structure shown
+ below, as the second parameter.
+
+ struct qcedev_sha_op_req {
+ struct buf_info data[QCEDEV_MAX_BUFFERS];
+ uint32_t entries;
+ uint32_t data_len;
+ uint8_t digest[QCEDEV_MAX_SHA_DIGEST];
+ uint32_t diglen;
+ uint8_t *authkey;
+ uint32_t authklen;
+ enum qcedev_sha_alg_enum alg;
+ struct qcedev_sha_ctxt ctxt;
+ };
+
+The IOCTLs and associated request data structures are defined in
+ kernel/drivers/crypto/msm/inc/qcedev.h..
+
+
+Module parameters:
+==================
+
+The following module parameters are defined in the board init file.
+-CE hardware nase register address
+-Data mover channel used for transfer to/from CE hardware
+These parameters differ in each platform.
+
+
+
+Dependencies:
+=============
+qce driver. Please see Documentation/arm/msm/qce.txt.
+
+
+User space utilities:
+=====================
+
+none
+
+Known issues:
+=============
+
+none.
+
+
+To do:
+======
+ Enhance Cipher functionality:
+ (1) Add support for handling > 32KB for ciphering functionality when
+ - operation is not an "in place" operation (source != destination).
+ (when using PMEM allocated memory)
+
+Limitations:
+============
+ (1) In case of cipher functionality, Driver does not support
+ a combination of different memory sources for source/destination.
+ In other words, memory pointed to by src and dst,
+ must BOTH (src/dst) be "pmem" or BOTH(src/dst) be "vbuf".
+
+ (2) In case of hash functionality, driver does not support handling data
+ buffers allocated via PMEM.
+
+ (3) Do not load this driver if your device already has kernel space apps
+ that need to access the crypto hardware.
+ Make sure to have qcedev module disabled/unloaded and implement your user
+ space application to use the software implemenation (ex: openssl/crypto)
+ of the crypto algorithms.
+ (NOTE: Please refer to details on the limitations listed in qce.txt)
+
+ (4) If your device has Playready (Windows Media DRM) application enabled
+ and uses the qcedev module to access the crypto hardware accelarator,
+ please be informed that for performance reasons, the CE hardware will
+ need to be dedicated to playready application. Any other user space
+ application should be implemented to use the software implemenation
+ (ex: openssl/crypto) of the crypto algorithms.
diff --git a/Documentation/crypto/msm/qcrypto.txt b/Documentation/crypto/msm/qcrypto.txt
new file mode 100644
index 0000000..81aa194
--- /dev/null
+++ b/Documentation/crypto/msm/qcrypto.txt
@@ -0,0 +1,144 @@
+Introduction:
+=============
+
+Qualcomm Crypto (qcrypto) driver is a Linux crypto driver which interfaces
+with the Linux kernel crypto API layer to provide the HW crypto functions.
+This driver is accessed by kernel space apps via the kernel crypto API layer.
+At present there is no means for user space apps to access this module.
+
+Hardware description:
+=====================
+
+Qualcomm Crypto HW device family provides a series of algorithms implemented
+in the device.
+
+Crypto 2 hardware provides hashing - SHA-1, SHA-256, ciphering - DES, 3DES, AES
+algorithms, and concurrent operations of hashing, and ciphering.
+
+In addition to those functions provided by Crypto 2 HW, Crypto 3 provides fast
+AES algorithms.
+
+In addition to those functions provided by Crypto 3 HW, Crypto 3E provides
+HMAC-SHA1 hashing algorithm.
+
+In addition to those functions provided by Crypto 3 HW, Crypto 4.0 provides
+HMAC-SHA1/SHA256, AES CBC-MAC hashing algorithm and AES XTS/CCM cipher
+algorithms.
+
+
+Software description
+====================
+
+The module init function (_qcrypto_init()), does a platform_register(),
+to register the driver. As the result, the driver probe function,
+_qcrypto_probe(), will be invoked for each registered device.
+
+In the probe function, driver opens the low level CE (qce_open), and
+registers the supported algorithms to the kernel crypto API layer.
+Currently, qcrypto supports the following algorithms.
+
+ ablkcipher -
+ cbc(aes),ecb(aes),ctr(aes)
+ ahash -
+ sha1, sha256
+ aead -
+ authenc(hmac(sha1),cbc(aes))
+
+ The hmac(sha1), hmac(sha256, authenc(hmac(sha1),cbc(aes)), ccm(aes)
+ and xts(aes) algorithms are registered for some platforms that
+ support these in the CE hardware
+
+The HW device can support various algorithms. However, the most important
+algorithms to gain the performance using a HW crypto accelerator are
+AEAD, and ABLKCIPHER.
+
+AEAD stands for "authentication encryption with association data".
+ABLKCIPHER stands of "asynchronous block cipher".
+
+The AEAD structure is described in the following header file
+ LINUX/opensource/kernel/include/crypto/aead.h
+
+The design of the driver is to allow multiple requests
+issued from kernel client SW (eg IPSec).
+Therefore, the driver will have to internally queue the requests, and
+serialize the requests to the low level qce driver.
+
+When a request is received from the client, if there is no outstanding
+request, a qce (or qce40) request is issued, otherwise, the request is
+queued in the driver queue.
+
+On completion of a request, the qce (or qce40) invokes the registered
+callback from the qcrypto. The internal tasklet (done_tasklet) is scheduled
+in this callback function. The sole purpose of done_tasklet is
+to call the completion of the current active request, and
+issue more requests to the qce (or qce40), if any exists.
+
+A spin lock is used to protect the critical section of internal queue to
+be accessed from multiple tasks, SMP, and completion callback
+from qce.
+
+The driver maintains a set of statistics using debug fs. The files are
+in /debug/qcrypto/stats1, /debug/qcrypto/stats2, /debug/qcrypto/stats3;
+one for each instance of device. Reading the file associated with
+a device will retrieve the driver statistics for that device.
+Any write to the file will clear the statistics.
+
+Test vectors for authenc(hmac(sha1),cbc(aes)) algorithm are
+developed offline, and imported to crypto/testmgr.c, and crypto/testmgr.h.
+
+
+Power Management
+================
+ none
+
+
+Interface:
+==========
+The kernel interface is defined in
+ LINUX/opensource/kernel/include/linux/crypto.h.
+
+
+Module parameters:
+==================
+
+All the platform specific parameters are defined in the board init
+file, eg. arch/arm/mach-msm/board-mssm7x30.c for msm7x30.
+
+Dependencies:
+=============
+qce driver.
+
+
+User space utilities:
+=====================
+ n/a
+
+Known issues:
+=============
+ n/a
+
+To do:
+======
+ Add Hashing algorithms.
+
+
+Limitations:
+===============
+(1) Each packet transfer size (for cipher and hash) is limited to maximum of
+ 32KB. This is a limitation in the crypto engine hardware. Client will
+ have to break packets larger than 32KB into multiple requests of smaller
+ size data packets.
+
+(2) Do not load this driver if your device has user space apps that needs to
+ access the crypto hardware. Please make sure to have the qcrypto module
+ disabled/unloaded.
+ Not having the driver loaded, will result in the kernel space apps to use
+ the registered software implementation of the crypto algorithms.
+
+(3) If your device has Playready application enabled and uses the qcedev module
+ to access the crypto hardware accelarator, please be informed that for
+ performance reasons, the CE hardware will need to be dedicated to playready
+ application. Any other user space or kernel application should be implemented
+ to use the software implemenation of the crypto algorithms.
+
+ (NOTE: Please refer to details on the limitations listed in qce/40.txt)
diff --git a/Documentation/csdio.txt b/Documentation/csdio.txt
new file mode 100644
index 0000000..22d5e35
--- /dev/null
+++ b/Documentation/csdio.txt
@@ -0,0 +1,189 @@
+Introduction
+============
+The Char SDIO Device Driver is an interface which exposes an SDIO
+card/function from kernel space as a char device in user space.
+
+The driver doesn't interact with any HW directly. It relies on SDIO
+card/function interface provided as a part of Linux kernel.
+
+Hardware description
+====================
+Each SDIO device/card contains an SDIO client HW block.
+The host interacts with the device by sending byte sequences called
+command (CMD). Some commands can be followed by data blocks. The
+device sends back a byte sequence called response (R) and a data
+block if required. CMD3, CMD5 and CMD7 are used to initialize the
+device. CMD52 and CMD53 are used to access the device. Command
+format and properties are defined by SDIO Specification document
+published by SD Association:
+ http://www.sdcard.org/developers/tech/sdio/.
+
+CMD52 and CMD53 can access up to 8 address spaces called Functions.
+Function 0 contains system information predefined by SD/SDIO
+standard and Functions 1-7 are defined by the SDIO device
+manufacturer.
+
+An SDIO device/card can send an interrupt to SDIO host. This
+interrupt is intercepted and handled by SDIO host.
+
+Software description
+====================
+Linux provides a framework for handling SDIO devices. It implements
+kind of plug-and-play model in which the Linux SDIO Host Driver is
+responsible for initializing an SDIO device upon insertion. It also
+reads device/card identification information and enumerates functions
+provided by the device and then looks up in the list of
+preregistered user SDIO drivers for a suitable one.
+
+During its lifecycle the user SDIO driver interacts with the Linux
+SDIO Host Driver in order to send/receive information to/from SDIO
+device/card. The user SDIO driver doesn't work with CMD52/CMD53
+directly. Instead it uses an abstraction provided by the Linux SDIO
+Host Driver.
+
+The Linux SDIO Host Driver is also in charge of handling SDIO
+interrupts. User SDIO driver can register its own callback in SDIO
+Host Driver and get a notification about interrupt event.
+
+The Char SDIO Device Driver follows the design guidelines mentioned
+above. It provides the following functionality:
+
+ - Register itself in the user SDIO drivers list;
+ - Handle Probe event upon insertion of supported card/device;
+ - Creates and maintains a char device driver for each SDIO Function
+ found in the card/device;
+ - Translates read/write/ioctl calls to appropriate SDIO call
+ sequences;
+
+In order to handle general SDIO configuration functionality and
+Function 0 the Char SDIO Device Driver provides additional
+simplified char device driver.
+
+The Manufacturer and Device IDs of handled SDIO device should be
+provided as parameters for kernel module or as configuration
+parameters in case of statically linked driver.
+
+Design
+======
+The main goal of the Char SDIO Device Driver is to expose an SDIO
+card/device from kernel space to user space as a char device driver.
+The driver should be generic and simple as far as possible.
+
+The biggest design tradeoff is maintaining a balance between the
+system call overhead required to initiate an SDIO transaction from
+user space and overall SDIO communication performance. But luckily,
+because of nature of SDIO protocol, this overhead is negligible
+comparing to time required to execute SDIO transaction itself. So,
+each CMD52 (read or write) consists from single ioctl system call.
+And each CMD53 invokes single ioctl system call followed by read or
+write system call.
+
+The Char SDIO Device Driver registers its own class of the devices
+called 'csdio'. This class will serve as a common roof for all SDIO
+devices served by different instances of the Char SDIO Device Driver.
+Additional benefit from maintaining its own class is the driver
+ability to overwrite default permissions of the dev nodes created by
+the driver.
+
+Power Management
+================
+None
+
+SMP/multi-core
+==============
+The driver does not anticipate any issues related to multi-core
+since it is expected to run on one core only.
+
+Security
+========
+None
+
+Performance
+===========
+None
+
+Interface
+=========
+The Char SDIO Device Driver has two char device interfaces:
+ - Control Interface;
+ - Function Interface.
+
+Char SDIO Device Driver Control Interface consists of:
+ - open() - device node is /dev/csdio0;
+ - close()
+ - ioctl() - the following options are available:
+ - CSDIO_IOC_ENABLE_HIGHSPEED_MODE;
+ - CSDIO_IOC_SET_DATA_TRANSFER_CLOCKS;
+ - CSDIO_IOC_ENABLE_ISR;
+ - CSDIO_IOC_DISABLE_ISR.
+
+Char SDIO Device Driver Function Interface consists of:
+ - open() - device node is /dev/csdiofX, where X is Function Id;
+ - close()
+ - read() - send CMD53 read;
+ - write() - send CMD53 write;
+ - ioctl() - the following options are available:
+ - CSDIO_IOC_SET_OP_CODE - 0 fixed adrress, 1 autoincrement.
+ - CSDIO_IOC_FUNCTION_SET_BLOCK_SIZE;
+ - CSDIO_IOC_SET_BLOCK_MODE - 0 byte mode, 1 block mode;
+ - CSDIO_IOC_CMD52 - execute CMD52, receives the
+ following structure as a parameter:
+ struct csdio_cmd52_ctrl_t {
+ uint32_t m_write; // 0 - read, 1 -write
+ uint32_t m_address;
+ uint32_t m_data; // data to write or read data
+ uint32_t m_ret; // command execution status
+ }__attribute__ ((packed));
+ - CSDIO_IOC_CMD53 - setup CMD53 data transfer, receives the
+ following structure as a parameter:
+ struct csdio_cmd53_ctrl_t {
+ uint32_t m_block_mode;
+ uint32_t m_op_code;
+ uint32_t m_address;
+ }__attribute__ ((packed));
+ - CSDIO_IOC_CONNECT_ISR;
+ - CSDIO_IOC_DISCONNECT_ISR;
+ - CSDIO_IOC_GET_VDD;
+ - CSDIO_IOC_SET_VDD.
+
+Additionally, user space application can use fcntl system call with
+parameters F_SETOWN and F_SETFL in order to set an asynchronous
+callback for SDIO interrupt.
+
+Driver parameters
+=================
+If the driver is compiled as a kernel module, the following
+parameters can be used in order to provide Manufacturer and Device IDs
+upon module download:
+ - csdio_vendor_id;
+ - csdio_device_id.
+If the driver is intended to work with specific SDIO host the
+host_name parameter should be added followed by the name of the MMC
+host platform device.
+
+Config options
+==============
+These are the kernel configuration options:
+ - CONFIG_CSDIO_VENDOR_ID;
+ - CONFIG_CSDIO_DEVICE_ID.
+
+Dependencies
+============
+The Char SDIO Device Driver depends on Linux SDIO Host Driver.
+
+User space utilities
+====================
+None
+
+Other
+=====
+None
+
+Known issues
+============
+None
+
+To do
+=====
+Provide mechanism to support a number of SDIO devices simultaneously
+connected to different SDIO hosts.
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index aa47be7..729e146 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2349,6 +2349,10 @@
1: Fast pin select (default)
2: ATC IRMode
+ snddev_icodec.msm_codec_i2s_slave_mode= [ARM-MSM]
+ 1, codec is I2S master
+ 0, MSM is I2S master (default)
+
softlockup_panic=
[KNL] Should the soft-lockup detector generate panics.
Format: <integer>
diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt
index bfe9242..d6114ed 100644
--- a/Documentation/networking/ip-sysctl.txt
+++ b/Documentation/networking/ip-sysctl.txt
@@ -1043,9 +1043,15 @@
This referred to as global forwarding.
-proxy_ndp - BOOLEAN
+proxy_ndp - INTEGER
Do proxy ndp.
+ Possible values are:
+ 0 Proxy NDP is disabled
+ 1 Proxy NDP is enabled
+ 2 NDP packets are sent to userspace, where a userspace proxy
+ can be implemented
+
conf/interface/*:
Change special settings per interface.
diff --git a/Documentation/networking/qfec.txt b/Documentation/networking/qfec.txt
new file mode 100644
index 0000000..182043f
--- /dev/null
+++ b/Documentation/networking/qfec.txt
@@ -0,0 +1,309 @@
+Driver name: Qualcomm FSM9xxx Ethernet Driver
+
+Supported hardware: FSM9xxx Ethernet Controller
+
+Maintainer(s):
+Author(s):
+
+
+Introduction:
+=============
+
+The FSM9xxx Ethernet controller is register based with separate TX and RX DMA
+engines supporting scatter/gather and support 1EEE-1588 timestamping.
+MII, RevMII and RgMII interfaces are support. RgMII support 1G.
+
+The driver supports gather but not scatter, uses the controller DMA engines,
+and timestamping.
+
+
+Hardware description:
+=====================
+
+The Ethernet Controller is a memory mapped register device with two
+internal DMA engines for TX and RX path processing using separate
+buffer-descriptors (BD) allocated from non-cached main memory for the TX
+and RX paths. These BDs support scatter-gather but are only used to
+transfer single max sized Ethernet frames. The BDs are sequentially
+accessed as a ring, with an end-of-ring bit set in the last BD. Ownership
+bits control access by hardware and software to individual BDs.
+
+An additional 4 words of space can be configured and is allocated between
+each BD to store additional information about the sk_buff associated with it.
+The driver software uses 2 ring structures and local functions to manage
+them to keep in sync with the hardware the BDs . The number of BDs is
+determined from the space allocated for them (PAGE_SIZE). The ratio of RX
+to TX BD is set by a #define.
+
+Interrupts are used to service and replenish pre-allocated sk_buff for each
+RX BD. TX frames are allocated to a TX BD and transmitted frames are
+freed within the xmit() invoked to send the frame. No TX interrupts are
+processed since sk_buffs are freed in the xmit().
+
+Three PHY interfaces are supported: MII, RevMII and RgMII. The selected
+interface is determined from the resource structure (to be completed) and
+programmed into a register prior to resetting the Ethernet controller.
+
+Separate PLLs are managed to provide MAC/PHY clocks in RevMii and RgMii
+modes, and a 25mHz clock timestamping.
+
+
+
+Software description
+====================
+
+Structures
+
+struct qfec_buf_desc {
+ uint32_t status;
+ uint32_t ctl;
+ void *p_buf;
+ void *next;
+};
+
+struct buf_desc {
+ struct qfec_buf_desc desc; /* must be first */
+
+ struct sk_buff *skb;
+ void *buf_virt_addr;
+ void *buf_phys_addr;
+ uint32_t last_bd_flag;
+};
+
+struct ring {
+ int head;
+ int tail;
+ int n_free;
+ int len;
+};
+
+struct qfec_priv {
+ struct net_device *net_dev;
+ struct net_device_stats stats; /* req statistics */
+
+ struct device dev;
+
+ spinlock_t hw_lock;
+
+ unsigned int state; /* driver state */
+
+ void *bd_base; /* addr buf-desc */
+ dma_addr_t tbd_dma; /* dma/phy-addr buf-desc */
+ dma_addr_t rbd_dma; /* dma/phy-addr buf-desc */
+
+ struct resource *mac_res;
+ void *mac_base; /* mac (virt) base address */
+
+ struct resource *clk_res;
+ void *clk_base; /* clk (virt) base address */
+
+ unsigned int n_tbd; /* # of TX buf-desc */
+ struct ring ring_tbd; /* TX ring */
+ struct buf_desc *p_tbd; /* # TX buf-desc */
+
+ unsigned int n_rbd; /* # of RX buf-desc */
+ struct ring ring_rbd; /* RX ring */
+ struct buf_desc *p_rbd; /* # RX buf-desc */
+
+ unsigned long cntr[cntr_last]; /* activity counters */
+
+ struct mii_if_info mii;
+
+ int mdio_clk; /* phy mdio clock rate */
+ int phy_id; /* default PHY addr (0) */
+ struct timer_list phy_tmr; /* monitor PHY state */
+};
+
+
+
+Initialization is divided between probe() and open() such that the
+net_device is allocated, the address space is mapped for register access,
+and procfs files created in probe(). BD memory is allocated and
+initialized along with interrupts and timers in open(). BD is not
+de-allocated in close() allowing it to be debugged after the interface is
+ifconfig down'd. This approach is intended to aid with debugging by
+allowing configuring the interface down and up may clear some early usage
+problems
+
+Phy link state changes are monitored using a timer using some existing
+functions from the mii library, but also with local functions intended to
+support RGMII in the future.
+
+A variety of information is accessible through procFs. Counters are used
+to track various driver events, these include abnormal and error
+interrupts. Hardware counters of various frame statistics (e.g. types and
+sizes of TX and RX frames) are available. Hardware registers and up to the
+50 TX and RX BDs can be can be displayed. A table of procfs filenames and
+functions are used to create and delete the procfs entries as needed.
+
+Probe()
+
+Allocate and initialize the net_device structure with resource information
+specifying the Ethernet controller, clock control and MAC address memory
+regions. Set netdev_ops to a statically defined sub-structure supporting
+the device.
+
+Open()
+
+Use qfec_mem_alloc() to allocate space for the buffer-descriptors (BD).
+TX BDs are initialized by clearing the ownership bit of each. Each RX BD
+is initialized using qfec_rbd_init(). Qfec_rbd_init() pre-allocates an
+sk_buff, saving the addresses of both the sk_buff and its data buffer in the
+additional BD space, setting the BD buf pointer to the physical address of
+the sk_buff data, and finally setting the ownership bit.
+
+Once the BDs are initialized, interface selected register is set to the
+appropriate PHY interface configuration, and the Ethernet controller is
+reset and its registers initialized, including the starting addresses of
+the TX and RX BDs.
+
+The PHY monitor state is initialized and the timer initialized and started.
+
+Finally, the interrupt for the Ethernet controller is initialized.
+
+ Note - Interrupts from both from the external PHY and internal RevMii
+ PHY, are available, but neither is used in preference to the
+ timer.
+
+
+Interrupt Processing
+
+Besides recognizing abnormal error interrupts, RX, TX and GMAC interrupts
+are recognized, although TX and GMAC interrupts are ignored but cleared and
+counted. (The gmac interrupt can be ignored but must be disabled).
+
+RX interrupts invoke a handler to process the received frame, send it
+to the stack and re-allocate a replacement sk_bufff for the buffer-
+descriptor.
+
+
+Receive Processing
+
+The RX buffer descriptors are initialized by _open() using qfec_rbd_init()
+which pre-allocated an sk_buff, saving its address and the physical address
+of its data in the additional BD space, as well as writing the physical
+address to the BD pbuf entry read by HW. The size of the buffer and
+other control information are written to the BD, as well as setting the
+ownership bit.
+
+A received frame generates an interrupt invoking qfec_rx_int(). It
+repeatedly checks the ownership the next available BD, and passing the
+sk_buff containing the received frame to the stack via netif_rx().
+
+Once all received frames are processed, it repeatedly calls qfec_rbd_init()
+to allocate a new sk_buff with each available BD.
+
+
+Transmit Processing
+
+Frames are transmitted through the start_xmit callback function.
+qfec_tx_replenish() is immediately called to free sk_buffs from BD
+that have been transmitted, before checking is a BD is available.
+The sk_buff address is stored in the additional BD space and the
+physical address of its data is store in the pbuf BD entry used
+by the HW. The TX poll-demand register is accessed, causing the
+HW to recheck the current BD and process it.
+
+While the TX interrupt could be processed to free sk_buffs as BD
+are processed, they are ignored since the sk_buffs will be freed
+with each call to _xmit().
+
+procfs
+
+debug files are available to display the controller registers,
+frame counters from the controller, driver activity counters, and
+the first 50 entries of the RX and TX buffer descriptors.
+
+
+Callbacks
+
+In addition to the functions described above, the following functions
+are used to support their correspondingly named device operations:
+
+ qfec_stop
+ qfec_do_ioctl
+ qfec_tx_timeout
+ qfec_set_mac_address
+ qfec_get_stats
+ qfec_set_config
+
+ eth_change_mtu
+ eth_validate_addr
+
+
+Power Management
+================
+None
+
+
+Interface:
+==========
+
+- Module-init/exit
+- standard network interface functions
+
+
+Module parameters:
+==================
+
+static struct resource qfec_resources [] = {
+ [0] = {
+ .start = QFEC_MAC_BASE,
+ .end = QFEC_MAC_BASE + QFEC_MAC_SIZE,
+ .flags = IORESOURCE_MEM,
+ },
+ [1] = {
+ .start = QFEC_MAC_IRQ,
+ .end = QFEC_MAC_IRQ,
+ .flags = IORESOURCE_IRQ,
+ },
+ [2] = {
+ .start = QFEC_CLK_BASE,
+ .end = QFEC_CLK_BASE + QFEC_CLK_SIZE,
+ .flags = IORESOURCE_IO,
+ },
+ [3] = {
+ .start = QFEC_MAC_FUSE_BASE,
+ .end = QFEC_MAC_FUSE_BASE + QFEC_MAC_FUSE_SIZE,
+ .flags = IORESOURCE_DMA,
+ },
+};
+
+static struct platform_device qfec_device = {
+ .name = "qfec",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(qfec_resources),
+ .resource = qfec_resources,
+};
+
+
+Resource entries exist for three address regions and one interrupt. The
+interrupt is identified as IORESOURCE_IRQ, the controller registers as
+OPRESOURCE_MEM, the clock control registers as IORESOURCE_IO, and the
+MAC address fuses as IORESOURCE_DMA.
+
+
+Dependencies:
+=============
+None
+
+
+User space utilities:
+=====================
+
+See procfs descriptions
+
+
+Known issues:
+=============
+
+- replace procfs w/ debugfs
+
+
+To do:
+======
+
+- specify interface (MII/RevMII/RgMii) in resource structure
+- RevMii support untested
+- RgMii (10/100/1000)
+- generic timestamp support
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 5e7cb39..6d7ca56 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -21,6 +21,7 @@
- acct
- bootloader_type [ X86 only ]
- bootloader_version [ X86 only ]
+- boot_reason [ ARM only ]
- callhome [ S390 only ]
- auto_msgmni
- core_pattern
@@ -126,6 +127,19 @@
==============================================================
+boot_reason:
+
+ARM -- reason for device boot
+
+A single bit will be set in the unsigned integer value to identify the
+reason the device was booted / powered on. The value will be zero if this
+feature is not supported on the ARM device being booted.
+
+See the power-on-status field definitions in
+Documentation/arm/msm/boot.txt for Qualcomm's family of devices.
+
+==============================================================
+
callhome:
Controls the kernel's callhome behavior in case of a kernel panic.
diff --git a/Documentation/tzcom.txt b/Documentation/tzcom.txt
new file mode 100644
index 0000000..7472dee
--- /dev/null
+++ b/Documentation/tzcom.txt
@@ -0,0 +1,181 @@
+Introduction
+============
+
+The tzcom (TrustZone Communicator) device driver provides IOCTLs for userspace
+to communicate with TrustZone Operating Environment (TZBSP) using Secure
+Channel Manager (SCM) interface. It also provides a way for TZBSP to utilize
+services in HLOS.
+
+Hardware description
+====================
+
+The hardware interaction is specified in Secure Channel Manager for TZBSP design
+document. This driver exercises the SCM interface (scm_call).
+
+Software description
+====================
+
+This driver is a character device driver and following operations are registered:
+- tzcom_open()
+- tzcom_release()
+- tzcom_ioctl()
+
+
+This driver provides following IOCTL methods:
+ TZCOM_IOCTL_REGISTER_SERVICE_REQ - to register HLOS service
+ TZCOM_IOCTL_UNREGISTER_SERVICE_REQ - to unregister HLOS service
+ TZCOM_IOCTL_SEND_CMD_REQ - send a command to a service
+ TZCOM_IOCTL_READ_NEXT_CMD_REQ - wait for a cmd from TZBSP to use HLOS service
+ TZCOM_IOCTL_CONTINUE_CMD_REQ - continue the last incomplete cmd on TZBSP
+
+TZCOM_IOCTL_REGISTER_SERVICE_REQ sequence diagram:
+
+ +--------------+ +---------------+
+ | USERSPACE | | TZCOM |
+ +------+-------+ +-------+-------+
+ | REGISTER_SERVICE |
+ |----------------->| ___
+ | |,-' ``.
+ | + verify &`.
+ | | add |
+ | | service |
+ | | to a list|
+ | registered |<-.._,,,,/
+ |<-----------------|
+ | |
+
+TZCOM_IOCTL_READ_NEXT_CMD_REQ, TZCOM_IOCTL_SEND_CMD_REQ and
+TZCOM_IOCTL_CONTINUE_CMD_REQ sequence:
+
+ +--------------+ +---------------+ +-------------+ +----------------+
+ | USERSPACE | | TZCOM | | SCM | | TZBSP |
+ +---+--+-------+ +-------+-------+ +------+------+ +-------+--------+
+ | | READ_NEXT_CMD | | |
+ +--|----------------->| | |
+ | | |.--------. | |
+ | | || BLOCKED| | |
+ | | |`--------' | |
+ | | | | |
+ | | | | |
+ | | SEND_CMD | | |
+ | +----------------->| | |
+ | | | scm_call | |
+ | | +---------------->| SEND_CMD |
+ | | | +---------------->|
+ | | | | cmd incomplete |
+ | | | scm_call returns|<----------------+
+ | | |<----------------+ |
+ | | | | |
+ | | |,-'''-. | |
+ | | + READ `. | |
+ | | | NEXT | | |
+ | | | CMD / | |
+ | | READ_NEXT_CMD ret|<.____,' | |
+ |<-|------------------+ | |
+ ,---. | | | | |
+ / \ | | | | |
+/perform\| | | | |
+ received) | | | |
+\command/| | | | |
+ \ / | | | | |
+ `---' | | | | |
+ | | | | |
+ | | CONTINUE_CMD | | |
+ +--|----------------->| | |
+ | | returns | _,... | |
+ | | immediately |' `. | |
+ | | | fill in`. | |
+ | | | incomplete | |
+ | | | cmd ; | |
+ | |<-...---' | |
+ | | scm_call | |
+ | +---------------->| SEND_CMD |
+ | | +---------------->|
+ | | | cmd complete |
+ | | scm_call returns|<----------------+
+ |SEND_CMD return |<----------------+ |
+ |<-----------------+ | |
+ | | | |
+
+
+
+There are three shared buffers between TZCOM driver and TZBSP.
+1) For command and response buffers for SEND_CMD requests
+2) For commands originated from TZBSP and their corresponding responses
+3) For debug service
+
+When calling IOCTL_SEND_CMD_REQ from userspace, command request and response
+buffers are initialized and provided in the IOCTL arguments. Where request and
+response buffers will be passed as an arguments to the smc_call method.
+
+The requests are synchronous. The driver will put the process to sleep,
+waiting for the completion of the requests using wait_for_completion().
+
+This driver uses kmalloc for shared buffer pools which get initialized at driver
+initialization. There are three buffers each 20 KB. If any of the buffers fail
+to initialize then driver will fail to load. Assumption is the allocated
+memory for buffers is contiguous.
+
+
+Design
+======
+
+The goal of this driver is to provide a communication API for the userspace
+application to execute services in TrustZone as well as TrustZone operating
+environment to access services in HLOS.
+
+Currently TZ->HLOS communication happens from a blocking call to READ_NEXT_CMD
+that is initiated from the userspace and on receiving a command request from TZ
+service, command is placed on a queue to unblock READ_NEXT_CMD call. This could
+have been solved by using a callback, but the practice of invoking callbacks in
+userspace from kernel is discouraged.
+
+Power Management
+================
+
+n/a
+
+SMP/multi-core
+==============
+
+TZCOM allows multiple services being registered from HLOS and multiple processes
+or threads can call IOCTL_READ_NEXT_MSG. These services will block until new
+data arrives on the shared buffer (buffer #2 as mentioned in Software
+Description). This is achieved using wait queues.
+
+Security
+========
+
+Please refer to Security Channel Manager design document.
+
+Performance
+===========
+
+Every scm_call is a context switch between non-trusted and trusted operating
+environment. There are no performance related matrix for scm_call available as
+of now.
+
+Interface
+=========
+
+This driver will have a /dev/tzcom node and following IOCTL calls can be made.
+
+Userspace API (ioctl calls):
+ TZCOM_IOCTL_REGISTER_SERVICE_REQ - to register HLOS service
+ TZCOM_IOCTL_UNREGISTER_SERVICE_REQ - to unregister HLOS service
+ TZCOM_IOCTL_SEND_CMD_REQ - send a command to a service
+ TZCOM_IOCTL_READ_NEXT_CMD_REQ - wait for a cmd from TZBSP to use HLOS service
+ TZCOM_IOCTL_CONTINUE_CMD_REQ - continue the last incomplete cmd on TZBSP
+
+
+Dependencies
+============
+
+This driver interacts with Trustzone operating environment, thus depends on
+the TZBSP supported architecture.
+
+
+To do
+=====
+
+TBD
diff --git a/Documentation/usb/ehset_compliance.txt b/Documentation/usb/ehset_compliance.txt
new file mode 100644
index 0000000..3f00cf0
--- /dev/null
+++ b/Documentation/usb/ehset_compliance.txt
@@ -0,0 +1,69 @@
+Introduction
+============
+
+A USB high speed host must pass electrical compliance tests defined
+by the USB-IF. These compliance tests require the host controller to
+support various test modes defined by the USB 2.0 specification.
+
+USB-IF defines a standard method to initiate the test modes on an
+embedded host controller by using a test fixture. During enumeration
+by the USB host, this test fixture provides a Vendor-Id/Product-Id
+(or VID/PID) pair which is used by the host to initiate a particular
+test mode as each VID/PID pair corresponds to a unique test mode.
+
+Hardware description
+====================
+
+The driver doesn't require any new hardware and is like any other
+USB host class driver. It gets notified when a Test Fixture device is
+connected to the host.
+
+The test modes that can be initiated are specific to the high speed
+hosts controllers only.
+
+Software description
+====================
+
+This EHSET (or Embedded High Speed Electrical Test) driver registers
+itself with USB core as the preferred driver for the Test Fixture
+device. During registration it provides the list of the various
+VID/PID pairs which the Test Fixture may present during enumeration.
+The VID is always 0x1A0A, and the PIDs presented by the Test Fixture
+correspond to the following test modes:
+
+__________________________________________________
+ PID Test Mode
+--------------------------------------------------
+ 0x0101 TEST_SE0_NAK
+ 0x0102 TEST_J
+ 0x0103 TEST_K
+ 0x0104 TEST_PACKET
+ 0x0106 HS_HOST_PORT_SUSPEND_RESUME
+ 0x0107 SINGLE_STEP_GET_DEV_DESC
+ 0x0108 SINGLE_STEP_SET_FEATURE
+--------------------------------------------------
+
+The control flow is as follows:
+
+1. USB core notifies the ehset driver when a device (Test Fixture) is
+attached to the host having the VID/PID pair as one of the specified
+above.
+
+2. EHSET driver checks the PID which the Test Fixture presented during
+enumeration and then initiates the corresponding test mode.
+
+
+Dependencies
+============
+
+The driver depends on the USB EHCI Host support.
+
+Other
+=====
+
+The driver's code shall be added as a new file in the
+/kernel/drivers/usb/misc directory.
+
+Embedded High-speed Electrical Test Procedure document is available
+at:
+http://www.usb.org/developers/onthego/EHSET_v1.01.pdf
diff --git a/Documentation/usb/gadget_rmnet.txt b/Documentation/usb/gadget_rmnet.txt
new file mode 100644
index 0000000..2bf05a1
--- /dev/null
+++ b/Documentation/usb/gadget_rmnet.txt
@@ -0,0 +1,222 @@
+Introduction
+============
+
+QUALCOMM MSM Interface (QMI) defines the interface between MSM and
+attached Terminal Equipment (TE). RmNet interface is a new logical
+device in QMI framework for data services. RmNet in accordance with
+QMI architecture defines channels for control and data transfers and
+for example it uses Data I/O channel for IP data transfer and control
+I/O channel for QMI messaging (functionality similar to AT commands).
+RmNet may be used in place of legacy USB modem interface.
+
+Tethered networking is one of the function from MSM which can also be
+supported using QMI protocol. There are other standard protocols exists
+such as CDC-ECM and Windows proprietary RNDIS. On the host-side system,
+the gadget rmnet device looks like a ethernet adapter.
+
+Hardware description
+====================
+
+QMI is a messaging protocol to expose various functionalities of MSM
+and one of the functionality to be tethered networking which is being
+exposed over QMI using RmNet protocol. This usb gadget has one bulk-in,
+one bulk-out and one interrupt-in endpoint.
+
+Design:
+=======
+RmNet function driver design follows two approaches:
+
+Approach 1:
+-----------
+Single function driver is used to communicate with
+Modem(both for data and control). Most of the initial
+MSM targets are following this approach.
+
+The main disadvantage with this approach is there are
+multiple RmNet drivers for any change in DATA and Control
+Layer. There is no re-use in the code.
+
+Approach 2:
+-----------
+RmNet driver is divided into 3 components
+
+1. USB:
+This component has the functionality to deal with composite layer.
+Allocates Interfaces, Endpoints, listens to connect/disconnect
+interrupts and gives connect/disconnect notifications to DATA and
+CONTROL modules.
+
+2. Data:
+This component talks to modem to transfer IP data. Usually DATA
+and CONTROL go over same channel. However, to achieve higher
+data rates new transport channel for DATA may be used.
+
+3. Control:
+This component talks to modem to transfer rmnet control data.
+
+Software description
+====================
+The RmNet suports following data and control transports:
+as follows:
+ 1. SMD Interface
+ 2. SDIO Interface
+ 3. BAM Interface
+ 4. SMD Control Interface
+
+SMD interface uses the Shared memory for the RmNet driver to communicate
+with the MSM modem processor.
+SDIO interface acts as a link for communication of RmNet driver with the
+MDM modem processor.
+
+USB INTERACTION:
+----------------
+
+The RmNet function driver binds with the USB using the struct usb_function.
+The function is added using the usb_function_add().
+Control Transfers: The RmNet handles two Class-specific control
+transfers: SEND_ENCAPSULATED_COMMAND and GET_ENCAPSULATED_RESPONSE.
+The asynchronous protocol QMI which consists of the QMI requests/responses
+is used for handling the transfers between the RmNet and the Host where the
+host sends a new QMI request before receiving the response for the current
+QMI request.
+
+Control & Data flow:
+1. Host issues a SEND_ENCAPSULATED command to send a QMI request.
+SMD: If the SMD control channel has enough room to accomodate a QMI request,
+it is written into the SMD buffer. Otherwise, append/add that request to
+qmi_request queue. A tasklet is scheduled to drain all QMI requests in
+qmi_request queue.
+SDIO: Add each request in the qmi_request queue and is processed until
+the queue is empty.
+
+2. Append/Add QMI response from modem to qmi_response queue.
+A notification on an interrupt end point is used to communicate the QMI
+response to host.
+
+3. Host issues a GET_ENCAPSULATED command to retrieve the QMI response.
+The response from qmi_response queue will be sent to the host.
+
+4. After the connection is fully established data can be sent to
+bulk-out endpoint and data can be received from bulk-in endpoint.
+
+5. Host can send QMI requests even after the connection is established.
+
+RmNet gadget driver is completely unaware of QMI/IP protocol. It just
+acts as a bridge between the modem and the PC.
+
+All the request/response queues in the driver can be accessed either
+from tasklet/workqueue or from interrupt context (either usb or smd/sdio
+interrupt handler). Hence a spinlock is used to protect all data/control req
+lists.
+
+
+SMD Interface:
+--------------
+
+1. Each QMI request/response can at most be 2048 bytes. Eight 2KB buffers
+are allocated using kmalloc for storing maximum of 8 requests/responses.
+
+2. Four 2KB buffers are allocated using kmalloc for data transfers on
+each bulk endpoint.
+
+Data structures:
+struct qmi_buf - Buffer to handle QMI requests & responses
+struct rmnet_smd_info - Control & Data SMD channel private data
+struct rmnet_dev - Endpoint and driver specific data
+
+Workqueues:
+rmnet_connect_work - Called on device connection.
+ Opens SMD channels; enables endpoints
+rmnet_disconnect_work - Called on device disconnection.
+ Closes SMD channels.
+
+Tasklets:
+rmnet_control_rx_tlet
+rmnet_control_tx_tlet - Control transfer data reception and transmission
+ handler
+
+rmnet_data_rx_tlet
+rmnet_data_tx_tlet - Data transfer data reception and transmission handler
+
+
+SMD control interface
+----------------------
+This function driver implements exchnage of control informtion with
+modem over SMD. Uses smd_read/write commands to read or write rmnet
+ctrl packets. Exposes a call back function to usb component to write
+control packet and at the same time call a call back usb component
+callback to send data to usb host.
+
+Data structures and Interfaces are very similar to control interfaces
+explained in "SMD Interface"
+
+BAM MUX interface
+------------------
+BAM Mux interface is very similar to SDIO MUX interface. However there
+are differences in the way BAM and SDIO operate but all of the details
+are masked by MUX Driver.
+
+Refer to the SDIO interfaces for more information on data structures
+
+SDIO Interface:
+---------------
+
+1. Each QMI request/response buffer is allocated depending on the size
+of data to be transmitted for the request/response.
+
+2. A 2KB network buffer is allocated for data transfer on bulk-out
+endpoint. The SDIO allocates the required buffer for data transfers
+on an bulk-in endpoint.
+
+Data structures:
+struct rmnet_sdio_qmi_buf - Buffer to handle QMI requests/responses.
+struct rmnet_dev - Endpoint and driver specific data
+
+Workqueues:
+rmnet_connect_work - Device connection handler. Opens SDIO
+ channels; enables and allocate buffer for
+ endpoints
+rmnet_disconnect_work - Device disconnection handler. Closes
+ SDIO channels; Frees allocated buffers.
+rmnet_control_rx_work - Control data reception handler.
+rmnet_data_rx_work - Network data reception handler.
+
+
+Two SMD/SDIO channels (control and data) are used as communication channels
+between Modem and Apps processor. The driver opens the SMD/SDIO channels
+on USB device connection. Data is either read from/written to the channels
+as one complete packet.
+
+SMD/SDIO provides a notification whenever the Modem processor completes
+read/write of a packet. Based on these SMD/SDIO notifications all the
+pending read/write requests will be handled. Tasklets(SMD)/Workqueues(SDIO)
+are used to get the requests done.
+
+There is another variant of rmnet driver called rmnet_smd_sdio which is used
+on some boards. This driver allows the transport (SMD/SDIO) to be chosen
+at runtime. This is required because either MDM processor or MODEM processor
+is only active at a time for data transfers. As SMD and SDIO interfaces
+are different, different endpoint completion handlers are used. This driver
+leverage the existing rmnet over smd and rmnet over sdio drivers. The control
+messages (QMI) always routed over SDIO. After the control messages exchange,
+user space will come to know about the available data transport (SMD/SDIO).
+User space notify the same to driver and the corresponding transport is
+activated. It is assumed that transport will not change while a USB cable
+is connected.
+
+Rmnet over SMD and rmnet over SDIO doesn't expose any of its interfaces to
+either kernelspace or userspace. But rmnet over smd/sdio expose a sysfs
+interface for userspace to notify the available transport to driver.
+
+The sysfs file can be found at
+/sys/class/usb_composite/rmnet_smd_sdio/transport
+
+The below command activates the SMD transport
+echo 0 > /sys/class/usb_composite/rmnet_smd_sdio/transport
+
+The below command activates the SDIO transport
+echo 1 > /sys/class/usb_composite/rmnet_smd_sdio/transport
+
+-EINVAL is returned if a write is attempted to transport when a USB cable
+is not connected.
+
diff --git a/Documentation/usb/gadget_sdio.txt b/Documentation/usb/gadget_sdio.txt
new file mode 100644
index 0000000..d0f1d63
--- /dev/null
+++ b/Documentation/usb/gadget_sdio.txt
@@ -0,0 +1,32 @@
+Introduction
+============
+
+Gadget serial driver is divided into two parts.
+1. f_serial.c : Interacts with USB Gadget Layer
+2. u_serial.c : Interacts with TTY Layer
+
+Gadget sdio driver adds capability to interact with SDIO Layer in
+case modem device is inter-connected with sdio interface.
+
+S/W Description
+===============
+Gadget SDIO driver is a simple bridge driver between usb serial
+gadget and sdio abstraction layer. It registers with sdio
+abstraction layer with read/write call backs and provides
+USB connect/disconnect call backs usb gadget serial driver.
+
+
+S/W Control Flow:
+=================
+Driver maintains two sdio channels, one for data and one for control.
+Data pipe is dedicated sdio channel where as control is a muxed channel.
+Incase of sdio control pipe, driver registers for control information
+chagnes from modem side. Whenever new information is available, it
+would queue a interrupt endpoint w/ new info. Laptop can also send the
+DTR and RTS information as part of SET Encapsulated command.
+
+Data pipe of sdio channel also has notification mechanism to indicate
+the READ/WRITE availability. When READ is available on SDIO pipe,
+driver would read the data and hands it over to USB In ept and when
+it receives the data from USB driver would queue the same to SDIO
+channel(if write buffers are available).
diff --git a/Documentation/usb/gadget_smd.txt b/Documentation/usb/gadget_smd.txt
new file mode 100644
index 0000000..18b93d8
--- /dev/null
+++ b/Documentation/usb/gadget_smd.txt
@@ -0,0 +1,27 @@
+Introduction
+============
+
+Gadget serial driver is divided into two parts.
+1. f_serial.c : Interacts with USB Gadget Layer
+2. u_serial.c : Interacts with TTY Layer
+
+Gadget smd driver adds capability to interact with smd layer in
+case modem device is inter-connected with smd interface.
+
+S/W Description
+===============
+Gadget smd driver is a simple bridge driver between usb serial
+gadget and smd abstraction layer. It registers with smd
+abstraction layer with notification call back and provides
+USB connect/disconnect call backs usb gadget serial driver.
+
+
+S/W Control Flow:
+=================
+USB SMD driver registers w/ SMD driver and provides notification
+call back. SMD Driver calls this call back whenever DATA is available
+to read, buffer is available to write or modem control signals changed.
+Upon receiving notification from SMD driver, USB driver appropriately
+schedules read/write works. In case of control singals, USB driver
+notifies gadget component with changed control information.
+
diff --git a/Documentation/usb/msm_otg.txt b/Documentation/usb/msm_otg.txt
new file mode 100644
index 0000000..29b6f1a
--- /dev/null
+++ b/Documentation/usb/msm_otg.txt
@@ -0,0 +1,382 @@
+Introduction
+============
+This driver implements Session Request Protocol (SRP) and Host negotiation
+Protocol (HNP) described in On-The-Go (OTG) Supplement to the USB 2.0
+Specification. It also provides support for Accessory Charger Adapter (ACA)
+defined in the Battery Charging Specification 1.1.
+
+These protocols provide a means for USB host devices to intelligently manage
+power on VBUS and USB peripheral devices to become the host when paired with
+another OTG device.
+
+Hardware description
+====================
+USB hardware found in Qualcomm chipsets like MSM7x27, MSM7x30, QSD8x50 and
+MSM8660 is compliant to USB 2.0 high speed On-The-Go protocol.
+The transceiver, aka PHY is integrated on the chip and ULPI interface is used for
+communication.
+
+USB hardware interfaces to the system memory via AHB BUS. DMA engine is included
+to move all of the data to be transferred over the USB between USB core and
+system memory. Device controller can support 16 endpoints of all types
+(control/bulk/interrupt /isochronous) defined in USB 2.0 specification. The
+host controller is compliant to EHCI specification. Directly connected USB 1.1
+Full/Low speed devices are supported without a companion controller by having
+inbuilt Transaction Translator (TT).
+
+USB_HS_CLK, USB_HS_PCLK and USB_HS_CCLK are required for USB operation.
+Phy feeds 60MHZ HS_CLK to link when ULPI interface is used. This clock needs to
+be turned on only while resetting the link. HS_PCLK (Pbus clock) is required to
+move data to/from hardware FIFO. This clock may not be required on targets like
+MSM8660 where USB is part of smart peripheral subsystem. AXI bus frequency needs
+to be kept at maximum value while USB data transfers are happening. HS_CCLK
+(core clock) is introduced in MSM7x30 to get rid of dependency on AXI bus
+frequency.
+
+The same irq line is shared across OTG, Device controller and Host controller
+drivers. Phy is integrated on the chip and no gpios are required to connect link
+and PHY.
+
+Phy can monitor VBUS and ID lines while operating in low power mode (LPM). But
+leaving comparators ON in LPM increases power consumption. Hence VBUS line is
+routed to PMIC hardware which can generate interrupt (when accessed by Apps
+processor) or send RPC callback. This is also useful when an External LDO to
+power up 3.3V of PHY is not installed. An internal LDO is turned upon
+receiving notification from PMIC. Id line is not routed to PMIC. Hence OTG mode
+can not be supported with this configuration and External LDO must be present.
+
+Hardware can generate interrupt when voltage on VBUS line is reached
+above/below A-VBUS Valid and B-Session Valid threshold values defined in OTG
+specification. Interrupt is generated when Id line is grounded i.e Micro-A
+cable is connected.
+
+The following hardware features help in meeting the SRP and HNP protocol
+timings.
+
+Hardware Assist Data-pulse (HADP):
+---------------------------------
+When software programs HADP, Hardware start a data pulse of approximately 7ms
+in duration and then automatically ceases the data pulsing. This automation
+relieves software from controlling the data-pulse duration. This assist will
+ensure data pulsing meets the OTG requirement of > 5ms and < 10ms.
+
+Hardware Assist Auto-Reset (HAAR):
+---------------------------------
+When software programs HAAR, Hardware will automatically start a reset after
+a connect event. This shortcuts the normal process where software is notified
+of the connect event and starts the reset. Software will still receive
+notification of the connect event but should not write the reset bit when the
+HAAR is set. Software will be notified again after the reset is complete via
+the enable change bit in the PORTSC register which cause a port change
+interrupt.
+
+Hardware Assist B-Disconnect to A-Connect (HABA):
+------------------------------------------------
+During Host negotiation Protocol(HNP), A-Device must enable pull-up on D+ as
+soon as possible after detecting disconnect from B-device.
+
+When Software programs HABA, the Host Controller port is in suspend mode, and
+the B-device disconnects, then this hardware assist begins.
+1. Reset the OTG core
+2. Write the OTG core into device mode.
+3. Write the device run bit to a '1' and enable necessary interrupts including:
+ * USB Reset Enable (URE) : enables interrupt on usb bus reset to device
+ * Sleep Enable (SLE) : enables interrupt on device suspend
+ * Port Change Detect Enable (PCE) : enables interrupt on device connect
+
+When software has enabled this hardware assist, it must not interfere during the
+transition and should not write any register in the core until it gets an
+interrupt from the device controller signifying that a reset interrupt has
+occurred or at least first verify that the core has entered device mode.
+
+The following hardware feature helps in supporting Accessory Charger Adapter:
+
+PHY Support for ID_A/B/C:
+------------------------
+Accessory Charger Adapter has three ports to attach an OTG, charger and A or
+B-device. So, based on what all device are attached to the ACA, it outputs a
+state on the ID pin (i.e GROUND, ID_A, ID_B, ID_C, FLOAT).
+USB PHY has support for these ID states. Once software enables this support,
+PHY sets corresponding bit in its INTS register based on any changes in the
+ID state.
+
+Software description
+====================
+
+This driver provides OTG functionality when Device controller driver (DCD) and
+Host controller driver (HCD) are enabled. It is enabled even when one of the DCD
+or HCD is enabled to use PHY initialization, clock management, register memory
+mapping, low power mode (LPM) functionalities.
+
+Session Request Protocol (SRP): A-device may turn off power on VBUS upon user
+request or A_WAIT_BCON timeout. SRP detection interrupt is enabled and
+hardware is put into LPM. If Data pulse is detected, A-device starts a new
+session by applying power on VBUS. Hardware Auto Assist Data pulse feature is
+used to program Data pulse
+When acting as a B-device, if SRP initial conditions (SE0 condition for
+TB_SE0_SRP min and previous session was ended before TB_SSEND_SRP) are met, SRP
+is initiated upon user request. Hardware Auto Assist Data pulse feature is
+used to program Data pulse. If remote device does not turn on VBUS before
+TB_SRP_FAIL, an error is reported to user space.
+
+Host Negotiation Protocol (HNP): A-device periodically polls B-device to check
+host request status. When B-device returns true, A-device shall enable HNP and
+suspend the bus with in THOST_REQ_SUSP. HNP polling is implemented in USB core
+software. HCD registers a start_hnp callback method with EHCI framework. This
+method is called after suspending the port if HNP is enabled. HCD notifies OTG
+that B-device is suspended. A_AIDL_BDIS timer is kicked and waits for B-device
+disconnection. If B-device does not signal disconnect within TA_AIDL_BDIS
+timeout, session is closed by powering down VBUS. Otherwise A-device stops HCD
+and starts DCD to enable pull-up. A-device again resumes host role if it had
+observed bus idle for TA_BIDL_ADIS time.
+B-device signals host_request true upon user request. DCD notifies OTG that
+HNP is enabled and bus is idle. OTG driver disable pull-up by stopping DCD and
+kick B_ASE0_BRST timer. If A-device does not signal connect with in
+TB_ASE0_BRST, B-device resumes in peripheral role. Otherwise B-device assert
+the bus reset and enumerate the A-device.
+
+MSM chipsets which have 45nm integrated PHY supports Attach Detection Protocol.
+(A protocol which enables an OTG device to detect when a remote device has been
+attached or detached without supplying VBUS). ADP support needs to be
+implemented to efficiently supply/request power on VBUS. Leakage currents (i.e
+VBUS applied but no peripheral is connected) are very less on MSM hardware. So
+VBUS can be applied when Id becomes false. ADP may be never implemented in
+this driver due to this reason.
+
+The state machine is implemented as described in the OTG specification.
+A few exceptions are mentioned below:
+
+1. Host session request i.e a_bus_request input variable is automatically
+asserted when Id becomes false and SRP is detected.
+It is de-asserted When HCD suspends the bus and asserted again in case of
+remote device remote wakeup.
+2. Output variables like drv_vbus, loc_conn, loc_sof, adp_prb are not
+maintained in the state machine as they serve no purpose.
+3. Bus power down request i.e a_bus_drop is cleared when Micro-A cable is
+connected so that non OTG device can be detected when Micro-A cable is
+connected next time.
+4. Input variables that determine SRP initial condition status b_se0_srp and
+b_ssend_srp are not maintained in state machine processing. When a session is
+ended i.e VBUS falls below B-Session Valid threshold, time stamp is taken and
+is compared against the current time at the time of SRP initiation.
+
+
+Controller gives interrupt for every 1 msec if 1MSIE (1 Msec interrupt enable)
+is set. Timers used in OTG state machine can be implementing using 1MSEC
+timer as a source. But hrtimer on MSM hardware can give at least 1/32KHZ
+precision. So hrtimer framework is used to implement OTG timers. No two OTG
+timers run in parallel. Hence one hrtimer is used for all OTG timers.
+
+OTG state machine processing can not be done in atomic context. Hence a worker
+thread is created for processing the state machine events. A separate worker
+thread is created instead of using default worker thread to meet OTG
+specification timings.
+
+OTG supplement Revision 2.0 has made HNP timings less stringent compared to
+Revision 1.3. TA_BDIS_ACON (The time with in A-Device should enable pull-up
+upon B-device signals disconnect) has been changed to 150 msec from 3 msec.
+DCD can be easily activated within 150 msec. Hence HABA is not used.
+TB_ACON_BSE0 (The time with in B-device should reset the A-device) has been
+changed to 150 msec from 1 sec. Host software would easily meet this timing
+given that de-bounce delays and root hub port power stabilization delays are
+not required during HNP.
+
+Accessory Charger Adapter (ACA): To support ACA there must be support in the
+USB hardware (Controller and PHY) for the ID_A/B/C states. It should be able
+to interrupt software for any ID state changes. On receiving this interrupt,
+interrupt handler checks the current ID state and invokes OTG state machine
+for further handling. Even if the USB Controller doesn't support these ID_A/B/C
+states, driver can still detect the ID state transitions by depending on USB
+PHY if the PHY supports these ID states. For this scenario, driver relies
+on polling of PHY register to determine the ID state changes as long as an
+ACA is attached to the system. This polling is implemented by using a timer
+running at a frequency of 1 sec. This timer checks for the current ID state
+and on detecting any change it invokes OTG state machine for further handling.
+
+Following are the actions performed by the driver as per the ID state:
+* ID_FLOAT: Configure device to act as peripheral and allow charging if VBUS
+ is present, else move it to LPM (low power mode).
+* ID_GROUND: Configure device to act as host and supply VBUS.
+* ID_A: Configure device to act as host and don't supply VBUS. In this state
+ the device can charge as well.
+* ID_B: Keep the device in IDLE state and allow charging.
+* ID_C: Configure device to act as peripheral and allow charging.
+
+Design
+======
+
+The following goals are kept in mind while designing OTG state machine.
+
+1. Avoid User intervention when operating as a standard Host or standard
+peripheral
+2. Support host only and peripheral only modes
+3. Put Hardware in LPM when ever possible
+4. Pass OTG compliance tests
+5. Report notification/error messages to user space
+6. With ACA, allow charging in Host mode as well
+7. Disable LPM as long as ID state polling is happening
+
+Power Management
+================
+
+System suspend is negated by acquiring wakelock while processing OTG state
+machine, or while polling for the PHY ID state in case of ACA.
+Wakelock is released:
+1. After activating the DCD/HCD. It is the responsibility of DCD/HCD to
+acquire wakelock if required.
+2. After putting hardware in LPM.
+3. No state machine events and timers are pending. This would cover scenarios
+mentioned in (1) and (2).
+4. After driver stops polling for ID state in case of ACA.
+
+Wake lock is re-acquired when state machine work is scheduled, which can
+happen from interrupt (exiting LPM), sysfs entries (initiate SRP, clear
+error, bus drop, etc), or from ID state polling routine.
+
+OTG driver provides set_suspend method for DCD/HCD to put hardware in LPM. DCD
+can use this method upon bus suspend. HCD can use this method upon suspending
+the root hub.
+
+LPM entering procedure:
+1. Clear PHY interrupt latch registers.
+2. Enable PHY comparators to detect Id, B-Session Valid interrupts while hardware
+is in LPM.
+3. Turn off PLL block on the PHY to achieve maximum power savings.
+4. Put PHY in suspend mode by setting PHCD bit in PORTSC register.
+5. Enable asynchronous interrupt so that PHY can generate interrupt when
+clocks are disabled.
+6. Disable all USB clocks.
+
+LPM exit procedure:
+1. Enable USB clocks.
+2. Disable asynchronous interrupt.
+3. Put PHY out of suspend mode. This is not required when LPM is exited due to
+hardware activity i.e asynchronous interrupt.
+
+SMP/multi-core
+==============
+
+OTG state machine inputs like bus request, bus drop, srp_detect etc accessed
+from interrupt context, and multiple process contexts. Hence atomic bit ops are
+used. ulpi_read and ulpi_write functions can now be accessed from multiple
+context, hence, these are protected using a spin_lock.
+
+Interface
+=========
+This driver provides the following methods to DCD and HCD.
+
+set_peripheral: DCD use this methods to register/unregister USB gadget.
+
+set_host: HCD use this method to register/unregister USB bus. Unlike gadget
+framework, there are no standard methods to start/stop HCD. Hence start_host
+method is introduced and must be initialized by HCD prior to registration.
+
+set_clk: HCD and DCD use this method to turn on/off USB_HS_CLK clk which is
+required only while resetting the controller.
+
+start_srp: DCD use this method to initiate Session Request Protocol (SRP).
+SRP may be initiated when function drivers use remote wakeup facility, when
+B-Device wishes to become host. OTG driver programs Data-Pulsing if initial
+condition of SRP are met. Otherwise proper error code is returned.
+
+set_suspend: DCD call this method when controller generates suspend
+interrupt or generates reset/port change interrupt before HNP and during HNP.
+If device is in B_PERIPHERAL state, HNP is initiated if host had enabled it.
+If device is in A_PERIPHERAL state, A_BIDL_ADIS timer is kicked in case of
+suspend interrupt. If this timer expires, A-device take back it's host role
+and continue previous session. This timer is deleted in case of
+reset/port change interrupts.
+HCD call this method after suspending the root hub. Hardware is put into LPM.
+
+start_hnp: A-device needs to enable pull-up on D+ within TA_BIDL_ADIS after
+suspending the bus i.e putting port in suspend state. EHCI stack can use this
+method to notify OTG right after suspending the OTG port. OTG driver schedule
+a work to stop host and enable pull-up on D+.
+
+send_event: USB core, DCD and HCD can use otg_send_event() API to send OTG
+notification/error messages to user space. send_event method defined in
+otg_transceiver is invoked by otg_send_event() API. An uevent is sent
+with SUBSYSTEM=platform, MODULE=msm_otg and EVENT=<event>, where event could
+be one of the following events.
+
+OTG_EVENT_DEV_CONN_TMOUT: Device connection timeout or device not responding.
+OTG_EVENT_NO_RESP_FOR_HNP_ENABLE: Device is not responding to B_HNP_ENABLE
+ feature request.
+OTG_EVENT_HUB_NOT_SUPPORTED: Host does not support HUB class peripherals.
+OTG_EVENT_DEV_NOT_SUPPORTED: Host does not support the attached peripheral.
+OTG_EVENT_HNP_FAILED: HNP failed due to not meeting protocol timings.
+OTG_EVENT_NO_RESP_FOR_SRP: No Response for B-device SRP request.
+
+set_power: DCD can use otg_set_power() API to specify about the current that
+can be withdrawn from the VBUS for charging. Based on the current OTG state
+and whether ACA is attached or not, OTG driver makes a decision about the
+charging current and calls the charging APIs.
+
+The following sysfs nodes are provided at /sys/devices/platform/msm_otg
+
+pwr_down: This node can be used to control A-device session. a_bus_drop and
+a_bus_req state machine input variables are altered to start/stop session.
+Write to this node is invalid when device operating as a B-device.
+
+start_srp: This node can be used for requesting session. If all initial
+conditions of SRP are met, SRP is initiated. Write to this node is invalid
+when device operating as an A-device.
+
+clr_err: This node can be used to clear over-current condition. Write to this
+node is invalid when operating as an B-device. Error condition is
+automatically cleared when Id becomes false.
+
+The following sysfs nodes are provided at /sys/devices/platform/msm_hsusb/otg
+
+host_request: This node can be used for requesting host role. A-device shall
+select a_hnp_support feature prior to configuration and poll B-device for host
+request. When '1' is written to this node, host request is asserted. This node
+can also be used for taking host role when A-device operating as a peripheral.
+
+hnp_avail: User space can check this node before requesting the host role.
+Gadget controller driver asserts its internal variable hnp_avail when HNP
+polling request is send by the Host.
+
+Dependencies
+============
+
+If USB clocks are controlled by modem processor, proc_comm interface is used
+to turn on/off clocks.
+
+If VBUS power is controlled by modem processor, RPC interface is used to turn
+on/off VBUS power.
+
+Config options
+==============
+
+CONFIG_USB_MSM_ACA: Enable support for Accessory Charger Adapter (ACA)
+CONFIG_ENABLE_MSM_OTG_A_WAIT_BCON_TIMEOUT: Enable A_WAIT_BCON timeout. VBUS
+will be turned off and SRP detection is enabled upon this timeout. If this
+config is not selected, VBUS will not be turned off when Mini/Micro-A cable
+is connected. But hardware is put into LPM.
+
+Other
+=====
+On-The-Go and Embedded Host Supplement to the USB Revision 2.0 Specification
+(Revision 2.0) found at http://www.usb.org/developers/onthego
+
+Known issues
+============
+Phy instability issues are observed when vbus_valid interrupt is enabled.
+Hence a_vbus_vld state machine variable is explicitly asserted after
+a_wait_vrise timer expiration.
+
+Spurious interrupt is seen when trying to put PHY in Low Power Mode with
+ID_A/B/C interrupts enabled in the PHY. As a result of which PHY doesn't stay
+in LPM. Hence, ID_A/B/C interrupts are disabled before entering LPM, and
+enabled while returning.
+
+To do
+=====
+
+Verify SRP detection on all targets.
+
+Phy instability issues are observed when A-Vbus Valid interrupt is enabled.
+But without this interrupt over current condition can not be determined. Root
+cause analysis for PHY instability issue and alternative methods like PMIC
+interrupt are being pursued.