5 files changed, 450 insertions, 1 deletions

diff --git a/Documentation/misc-devices/apds990x.txt b/Documentation/misc-devices/apds990x.txt
new file mode 100644
index 000000000000..d5408cade32f
--- /dev/null
+++ b/Documentation/misc-devices/apds990x.txt
@@ -0,0 +1,111 @@
+Kernel driver apds990x
+======================
+
+Supported chips:
+Avago APDS990X
+
+Data sheet:
+Not freely available
+
+Author:
+Samu Onkalo <samu.p.onkalo@nokia.com>
+
+Description
+-----------
+
+APDS990x is a combined ambient light and proximity sensor. ALS and proximity
+functionality are highly connected. ALS measurement path must be running
+while the proximity functionality is enabled.
+
+ALS produces raw measurement values for two channels: Clear channel
+(infrared + visible light) and IR only. However, threshold comparisons happen
+using clear channel only. Lux value and the threshold level on the HW
+might vary quite much depending the spectrum of the light source.
+
+Driver makes necessary conversions to both directions so that user handles
+only lux values. Lux value is calculated using information from the both
+channels. HW threshold level is calculated from the given lux value to match
+with current type of the lightning. Sometimes inaccuracy of the estimations
+lead to false interrupt, but that doesn't harm.
+
+ALS contains 4 different gain steps. Driver automatically
+selects suitable gain step. After each measurement, reliability of the results
+is estimated and new measurement is trigged if necessary.
+
+Platform data can provide tuned values to the conversion formulas if
+values are known. Otherwise plain sensor default values are used.
+
+Proximity side is little bit simpler. There is no need for complex conversions.
+It produces directly usable values.
+
+Driver controls chip operational state using pm_runtime framework.
+Voltage regulators are controlled based on chip operational state.
+
+SYSFS
+-----
+
+
+chip_id
+        RO - shows detected chip type and version
+
+power_state
+        RW - enable / disable chip. Uses counting logic
+             1 enables the chip
+             0 disables the chip
+lux0_input
+        RO - measured lux value
+             sysfs_notify called when threshold interrupt occurs
+
+lux0_sensor_range
+        RO - lux0_input max value. Actually never reaches since sensor tends
+             to saturate much before that. Real max value varies depending
+             on the light spectrum etc.
+
+lux0_rate
+        RW - measurement rate in Hz
+
+lux0_rate_avail
+        RO - supported measurement rates
+
+lux0_calibscale
+        RW - calibration value. Set to neutral value by default.
+             Output results are multiplied with calibscale / calibscale_default
+             value.
+
+lux0_calibscale_default
+        RO - neutral calibration value
+
+lux0_thresh_above_value
+        RW - HI level threshold value. All results above the value
+             trigs an interrupt. 65535 (i.e. sensor_range) disables the above
+             interrupt.
+
+lux0_thresh_below_value
+        RW - LO level threshold value. All results below the value
+             trigs an interrupt. 0 disables the below interrupt.
+
+prox0_raw
+        RO - measured proximity value
+             sysfs_notify called when threshold interrupt occurs
+
+prox0_sensor_range
+        RO - prox0_raw max value (1023)
+
+prox0_raw_en
+        RW - enable / disable proximity - uses counting logic
+             1 enables the proximity
+             0 disables the proximity
+
+prox0_reporting_mode
+        RW - trigger / periodic. In "trigger" mode the driver tells two possible
+             values: 0 or prox0_sensor_range value. 0 means no proximity,
+             1023 means proximity. This causes minimal number of interrupts.
+             In "periodic" mode the driver reports all values above
+             prox0_thresh_above. This causes more interrupts, but it can give
+             _rough_ estimate about the distance.
+
+prox0_reporting_mode_avail
+        RO - accepted values to prox0_reporting_mode (trigger, periodic)
+
+prox0_thresh_above_value
+        RW - threshold level which trigs proximity events.
diff --git a/Documentation/misc-devices/bh1770glc.txt b/Documentation/misc-devices/bh1770glc.txt
new file mode 100644
index 000000000000..7d64c014dc70
--- /dev/null
+++ b/Documentation/misc-devices/bh1770glc.txt
@@ -0,0 +1,116 @@
+Kernel driver bh1770glc
+=======================
+
+Supported chips:
+ROHM BH1770GLC
+OSRAM SFH7770
+
+Data sheet:
+Not freely available
+
+Author:
+Samu Onkalo <samu.p.onkalo@nokia.com>
+
+Description
+-----------
+BH1770GLC and SFH7770 are combined ambient light and proximity sensors.
+ALS and proximity parts operates on their own, but they shares common I2C
+interface and interrupt logic. In principle they can run on their own,
+but ALS side results are used to estimate reliability of the proximity sensor.
+
+ALS produces 16 bit lux values. The chip contains interrupt logic to produce
+low and high threshold interrupts.
+
+Proximity part contains IR-led driver up to 3 IR leds. The chip measures
+amount of reflected IR light and produces proximity result. Resolution is
+8 bit. Driver supports only one channel. Driver uses ALS results to estimate
+reliability of the proximity results. Thus ALS is always running while
+proximity detection is needed.
+
+Driver uses threshold interrupts to avoid need for polling the values.
+Proximity low interrupt doesn't exists in the chip. This is simulated
+by using a delayed work. As long as there is proximity threshold above
+interrupts the delayed work is pushed forward. So, when proximity level goes
+below the threshold value, there is no interrupt and the delayed work will
+finally run. This is handled as no proximity indication.
+
+Chip state is controlled via runtime pm framework when enabled in config.
+
+Calibscale factor is used to hide differences between the chips. By default
+value set to neutral state meaning factor of 1.00. To get proper values,
+calibrated source of light is needed as a reference. Calibscale factor is set
+so that measurement produces about the expected lux value.
+
+SYSFS
+-----
+
+chip_id
+        RO - shows detected chip type and version
+
+power_state
+        RW - enable / disable chip. Uses counting logic
+             1 enables the chip
+             0 disables the chip
+
+lux0_input
+        RO - measured lux value
+             sysfs_notify called when threshold interrupt occurs
+
+lux0_sensor_range
+        RO - lux0_input max value
+
+lux0_rate
+        RW - measurement rate in Hz
+
+lux0_rate_avail
+        RO - supported measurement rates
+
+lux0_thresh_above_value
+        RW - HI level threshold value. All results above the value
+             trigs an interrupt. 65535 (i.e. sensor_range) disables the above
+             interrupt.
+
+lux0_thresh_below_value
+        RW - LO level threshold value. All results below the value
+             trigs an interrupt. 0 disables the below interrupt.
+
+lux0_calibscale
+        RW - calibration value. Set to neutral value by default.
+             Output results are multiplied with calibscale / calibscale_default
+             value.
+
+lux0_calibscale_default
+        RO - neutral calibration value
+
+prox0_raw
+        RO - measured proximity value
+             sysfs_notify called when threshold interrupt occurs
+
+prox0_sensor_range
+        RO - prox0_raw max value
+
+prox0_raw_en
+        RW - enable / disable proximity - uses counting logic
+             1 enables the proximity
+             0 disables the proximity
+
+prox0_thresh_above_count
+        RW - number of proximity interrupts needed before triggering the event
+
+prox0_rate_above
+        RW - Measurement rate (in Hz) when the level is above threshold
+             i.e. when proximity on has been reported.
+
+prox0_rate_below
+        RW - Measurement rate (in Hz) when the level is below threshold
+             i.e. when proximity off has been reported.
+
+prox0_rate_avail
+        RO - Supported proximity measurement rates in Hz
+
+prox0_thresh_above0_value
+        RW - threshold level which trigs proximity events.
+             Filtered by persistence filter (prox0_thresh_above_count)
+
+prox0_thresh_above1_value
+        RW - threshold level which trigs event immediately
diff --git a/Documentation/misc-devices/ics932s401 b/Documentation/misc-devices/ics932s401
index 07a739f406d8..bdac67ff6e3f 100644
--- a/Documentation/misc-devices/ics932s401
+++ b/Documentation/misc-devices/ics932s401
@@ -5,7 +5,7 @@ Supported chips:
   * IDT ICS932S401
     Prefix: 'ics932s401'
     Addresses scanned: I2C 0x69
-    Datasheet: Publically available at the IDT website
+    Datasheet: Publicly available at the IDT website
 
 Author: Darrick J. Wong
 
diff --git a/Documentation/misc-devices/lis3lv02d b/Documentation/misc-devices/lis3lv02d
new file mode 100644
index 000000000000..f1a4ec840f86
--- /dev/null
+++ b/Documentation/misc-devices/lis3lv02d
@@ -0,0 +1,92 @@
+Kernel driver lis3lv02d
+=======================
+
+Supported chips:
+
+  * STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
+  * STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
+
+Authors:
+        Yan Burman <burman.yan@gmail.com>
+        Eric Piel <eric.piel@tremplin-utc.net>
+
+
+Description
+-----------
+
+This driver provides support for the accelerometer found in various HP laptops
+sporting the feature officially called "HP Mobile Data Protection System 3D" or
+"HP 3D DriveGuard". It detects automatically laptops with this sensor. Known
+models (full list can be found in drivers/platform/x86/hp_accel.c) will have
+their axis automatically oriented on standard way (eg: you can directly play
+neverball). The accelerometer data is readable via
+/sys/devices/platform/lis3lv02d. Reported values are scaled
+to mg values (1/1000th of earth gravity).
+
+Sysfs attributes under /sys/devices/platform/lis3lv02d/:
+position - 3D position that the accelerometer reports. Format: "(x,y,z)"
+rate - read reports the sampling rate of the accelerometer device in HZ.
+        write changes sampling rate of the accelerometer device.
+        Only values which are supported by HW are accepted.
+selftest - performs selftest for the chip as specified by chip manufacturer.
+
+This driver also provides an absolute input class device, allowing
+the laptop to act as a pinball machine-esque joystick. Joystick device can be
+calibrated. Joystick device can be in two different modes.
+By default output values are scaled between -32768 .. 32767. In joystick raw
+mode, joystick and sysfs position entry have the same scale. There can be
+small difference due to input system fuzziness feature.
+Events are also available as input event device.
+
+Selftest is meant only for hardware diagnostic purposes. It is not meant to be
+used during normal operations. Position data is not corrupted during selftest
+but interrupt behaviour is not guaranteed to work reliably. In test mode, the
+sensing element is internally moved little bit. Selftest measures difference
+between normal mode and test mode. Chip specifications tell the acceptance
+limit for each type of the chip. Limits are provided via platform data
+to allow adjustment of the limits without a change to the actual driver.
+Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are
+measured difference between modes. Axes are not remapped in selftest mode.
+Measurement values are provided to help HW diagnostic applications to make
+final decision.
+
+On HP laptops, if the led infrastructure is activated, support for a led
+indicating disk protection will be provided as /sys/class/leds/hp::hddprotect.
+
+Another feature of the driver is misc device called "freefall" that
+acts similar to /dev/rtc and reacts on free-fall interrupts received
+from the device. It supports blocking operations, poll/select and
+fasync operation modes. You must read 1 bytes from the device.  The
+result is number of free-fall interrupts since the last successful
+read (or 255 if number of interrupts would not fit). See the hpfall.c
+file for an example on using the device.
+
+
+Axes orientation
+----------------
+
+For better compatibility between the various laptops. The values reported by
+the accelerometer are converted into a "standard" organisation of the axes
+(aka "can play neverball out of the box"):
+ * When the laptop is horizontal the position reported is about 0 for X and Y
+        and a positive value for Z
+ * If the left side is elevated, X increases (becomes positive)
+ * If the front side (where the touchpad is) is elevated, Y decreases
+        (becomes negative)
+ * If the laptop is put upside-down, Z becomes negative
+
+If your laptop model is not recognized (cf "dmesg"), you can send an
+email to the maintainer to add it to the database.  When reporting a new
+laptop, please include the output of "dmidecode" plus the value of
+/sys/devices/platform/lis3lv02d/position in these four cases.
+
+Q&A
+---
+
+Q: How do I safely simulate freefall? I have an HP "portable
+workstation" which has about 3.5kg and a plastic case, so letting it
+fall to the ground is out of question...
+
+A: The sensor is pretty sensitive, so your hands can do it. Lift it
+into free space, follow the fall with your hands for like 10
+centimeters. That should be enough to trigger the detection.
diff --git a/Documentation/misc-devices/spear-pcie-gadget.txt b/Documentation/misc-devices/spear-pcie-gadget.txt
new file mode 100644
index 000000000000..02c13ef5e908
--- /dev/null
+++ b/Documentation/misc-devices/spear-pcie-gadget.txt
@@ -0,0 +1,130 @@
+Spear PCIe Gadget Driver:
+
+Author
+=============
+Pratyush Anand (pratyush.anand@st.com)
+
+Location
+============
+driver/misc/spear13xx_pcie_gadget.c
+
+Supported Chip:
+===================
+SPEAr1300
+SPEAr1310
+
+Menuconfig option:
+==========================
+Device Drivers
+        Misc devices
+                PCIe gadget support for SPEAr13XX platform
+purpose
+===========
+This driver has several nodes which can be read/written by configfs interface.
+Its main purpose is to configure selected dual mode PCIe controller as device
+and then program its various registers to configure it as a particular device
+type. This driver can be used to show spear's PCIe device capability.
+
+Description of different nodes:
+=================================
+
+read behavior of nodes:
+------------------------------
+link            :gives ltssm status.
+int_type        :type of supported interrupt
+no_of_msi       :zero if MSI is not enabled by host. A positive value is the
+                number of MSI vector granted.
+vendor_id       :returns programmed vendor id (hex)
+device_id       :returns programmed device id(hex)
+bar0_size:      :returns size of bar0 in hex.
+bar0_address    :returns address of bar0 mapped area in hex.
+bar0_rw_offset  :returns offset of bar0 for which bar0_data will return value.
+bar0_data       :returns data at bar0_rw_offset.
+
+write behavior of nodes:
+------------------------------
+link            :write UP to enable ltsmm DOWN to disable
+int_type        :write interrupt type to be configured and (int_type could be
+                INTA, MSI or NO_INT). Select MSI only when you have programmed
+                no_of_msi node.
+no_of_msi       :number of MSI vector needed.
+inta            :write 1 to assert INTA and 0 to de-assert.
+send_msi        :write MSI vector to be sent.
+vendor_id       :write vendor id(hex) to be programmed.
+device_id       :write device id(hex) to be programmed.
+bar0_size       :write size of bar0 in hex. default bar0 size is 1000 (hex)
+                bytes.
+bar0_address    :write  address of bar0 mapped area in hex. (default mapping of
+                bar0 is SYSRAM1(E0800000). Always program bar size before bar
+                address. Kernel might modify bar size and address for alignment, so
+                read back bar size and address after writing to cross check.
+bar0_rw_offset  :write offset of bar0 for which bar0_data will write value.
+bar0_data       :write data to be written at bar0_rw_offset.
+
+Node programming example
+===========================
+Program all PCIe registers in such a way that when this device is connected
+to the PCIe host, then host sees this device as 1MB RAM.
+#mount -t configfs none /Config
+For nth PCIe Device Controller
+# cd /config/pcie_gadget.n/
+Now you have all the nodes in this directory.
+program vendor id as 0x104a
+# echo 104A >> vendor_id
+
+program device id as 0xCD80
+# echo CD80 >> device_id
+
+program BAR0 size as 1MB
+# echo 100000 >> bar0_size
+
+check for programmed bar0 size
+# cat bar0_size
+
+Program BAR0 Address as DDR (0x2100000). This is the physical address of
+memory, which is to be made visible to PCIe host. Similarly any other peripheral
+can also be made visible to PCIe host. E.g., if you program base address of UART
+as BAR0 address then when this device will be connected to a host, it will be
+visible as UART.
+# echo 2100000 >> bar0_address
+
+program interrupt type : INTA
+# echo INTA >> int_type
+
+go for link up now.
+# echo UP >> link
+
+It will have to be insured that, once link up is done on gadget, then only host
+is initialized and start to search PCIe devices on its port.
+
+/*wait till link is up*/
+# cat link
+wait till it returns UP.
+
+To assert INTA
+# echo 1 >> inta
+
+To de-assert INTA
+# echo 0 >> inta
+
+if MSI is to be used as interrupt, program no of msi vector needed (say4)
+# echo 4 >> no_of_msi
+
+select MSI as interrupt type
+# echo MSI >> int_type
+
+go for link up now
+# echo UP >> link
+
+wait till link is up
+# cat link
+An application can repetitively read this node till link is found UP. It can
+sleep between two read.
+
+wait till msi is enabled
+# cat no_of_msi
+Should return 4 (number of requested MSI vector)
+
+to send msi vector 2
+# echo 2 >> send_msi
+#cd -