[PATCH linux v7 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver

[Jaghathiswari Rankappagounder Natarajan]

This binding provides interface for adding values related to ASPEED
AST2400/2500 PWM and Fan tach controller support.
The PWM controller can support upto 8 PWM output ports.
The Fan tach controller can support upto 16 tachometer inputs.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan 
Acked-by: Rob Herring 
---
 v7:
- Added a semicolon at the end of pwm_tacho_fixed_clk node in Examples section

 v6:
- Changed to aspeed,fan-tach-ch

 v5:
- Changed the naming scheme to aspeed,ast2400/2500-pwm-tacho
- Removed gpio pin muxing
- Added aspeed vendor prefix for fan-tach-ch
- Changed to fan@0/1
- Changed reg to 32 bits

 v4:
- Used 'reg'

 v3:
- Made the structure more common

 v2:
- Removed '_' in node and property names
- Gave some explanation for the properties used

 .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt

diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt 
b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
new file mode 100644
index ..cf4460564adb
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -0,0 +1,68 @@
+ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
+
+The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
+controller can support upto 16 Fan tachometer inputs.
+
+There can be upto 8 fans supported. Each fan can have one PWM output and
+one/two Fan tach inputs.
+
+Required properties for pwm-tacho node:
+- #address-cells : should be 1.
+
+- #size-cells : should be 1.
+
+- reg : address and length of the register set for the device.
+
+- pinctrl-names : a pinctrl state named "default" must be defined.
+
+- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
+
+- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
+  "aspeed,ast2500-pwm-tacho" for AST2500.
+
+- clocks : a fixed clock providing input clock frequency(PWM
+  and Fan Tach clock)
+
+fan subnode format:
+===
+Under fan subnode there can upto 8 child nodes, with each child node
+representing a fan. If there are 8 fans each fan can have one PWM port and
+one/two Fan tach inputs.
+
+Required properties for each child node:
+- reg : should specify PWM source port.
+   integer value in the range 0 to 7 with 0 indicating PWM port A and
+   7 indicating PWM port H.
+
+- aspeed,fan-tach-ch : should specify the Fan tach input channel.
+integer value in the range 0 through 15, with 0 indicating
+   Fan tach channel 0 and 15 indicating Fan tach channel 15.
+   Atleast one Fan tach input channel is required.
+
+Examples:
+
+pwm_tacho_fixed_clk: fixedclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+};
+
+pwm_tacho: pwmtachocontroller@1e786000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x1E786000 0x1000>;
+   compatible = "aspeed,ast2500-pwm-tacho";
+   clocks = <_tacho_fixed_clk>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm0_default _pwm1_default>;
+
+   fan@0 {
+   reg = <0x00>;
+   aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+   };
+
+   fan@1 {
+   reg = <0x01>;
+   aspeed,fan-tach-ch = /bits/ 8 <0x01 0x02>;
+   };
+};
--
2.12.2.715.g7642488e1d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH linux v7 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach

[Jaghathiswari Rankappagounder Natarajan]

The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
inputs.
The device driver matches on the device tree node. The configuration
values are read from the device tree and written to the respective
registers.
The driver provides a sysfs entries through which the user can
configure the duty-cycle value (ranging from 0 to 100 percent) and read
the fan tach rpm value.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan 
---
 v7:
- Made corrections for the sparse errors

 v6:
- Corrected odd line breaks
- Changed upto to up to
- Dropped unrelated changes
- Removed struct and used regs pointer directly
- Made groups to be null terminated
- Made correction in calculation of val/raw_data
- Removed else after return
- Removed unnecessary continuation lines

 v5:
- Changed the driver to suit the changes in the device tree documentation

 v4:
- Modified this driver to suit the representation in the devicetree

 v3:
- Only sent out device tree documentation; did not send this driver

 v2:
- Used BIT()
- Used regmap
- Avoided division when raw data is 0
- Removed empty lines between declaration
- Removed macros; Used two attribute groups and used is_visible callback
- Returned error when properties are undefined
- Removed .owner field
- Used PTR_ERR_OR_ZERO
- Removed explicit of_node_put for child nodes

 Documentation/hwmon/aspeed-pwm-tacho |  22 +
 drivers/hwmon/Kconfig|   9 +
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/aspeed-pwm-tacho.c | 835 +++
 4 files changed, 867 insertions(+)
 create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
 create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c

diff --git a/Documentation/hwmon/aspeed-pwm-tacho 
b/Documentation/hwmon/aspeed-pwm-tacho
new file mode 100644
index ..7cfb34977460
--- /dev/null
+++ b/Documentation/hwmon/aspeed-pwm-tacho
@@ -0,0 +1,22 @@
+Kernel driver aspeed-pwm-tacho
+==
+
+Supported chips:
+   ASPEED AST2400/2500
+
+Authors:
+   
+
+Description:
+
+This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
+controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+fanX_input ro  provide current fan rotation value in RPM as reported
+   by the fan to the device.
+
+pwmX   rw  get or set PWM fan control value. This is an integer
+   value between 0(off) and 255(full speed).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..757b5b0705bf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -341,6 +341,15 @@ config SENSORS_ASB100
  This driver can also be built as a module.  If so, the module
  will be called asb100.

+config SENSORS_ASPEED
+   tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver"
+   help
+ This driver provides support for ASPEED AST2400/AST2500 PWM
+ and Fan Tacho controllers.
+
+ This driver can also be built as a module. If so, the module
+ will be called aspeed_pwm_tacho.
+
 config SENSORS_ATXP1
tristate "Attansic ATXP1 VID controller"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..83025cc9bb45 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o
 obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
 obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
 obj-$(CONFIG_SENSORS_ASC7621)  += asc7621.o
+obj-$(CONFIG_SENSORS_ASPEED)   += aspeed-pwm-tacho.o
 obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o
 obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
 obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o
diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
new file mode 100644
index ..48403a2115be
--- /dev/null
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -0,0 +1,835 @@
+/*
+ * Copyright (c) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or later as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* ASPEED PWM & FAN Tach Register Definition */
+#define ASPEED_PTCR_CTRL   0x00
+#define ASPEED_PTCR_CLK_CTRL   0x04
+#define ASPEED_PTCR_DUTY0_CTRL 0x08
+#define ASPEED_PTCR_DUTY1_CTRL 0x0c
+#define ASPEED_PTCR_TYPEM_CTRL 0x10
+#define ASPEED_PTCR_TYPEM_CTRL10x14
+#define ASPEED_PTCR_TYPEN_CTRL 0x18
+#define 

[PATCH linux v7 0/2] Support for ASPEED AST2400/AST2500 PWM and Fan Tach driver

[Jaghathiswari Rankappagounder Natarajan]

Support for ASPEED AST2400/AST2500 PWM and Fan Tach driver.
Patches based on the upstream tag 4.9. Changes made in Version 4 are indicated
in the individual patches.
The AST2400/AST2500 PWM controller can support 8 PWM output ports.
The AST2400/AST2500 Fan Tach controller can support 16 tachometer inputs.
The hwmon driver provides sysfs entries through which the user can configure the
duty cycle for the particular PWM output port and read the fan rpm value for
the particular tachometer input.
Added devicetree binding documentation for AST2400/AST2500 PWM and Fan Tach
support.

Tested on Zaius board (which has AST2500 chip) and observed that when
duty cycle is lowered then the fan speed is lowered and lower fan rpm value(
corresponding to the duty cycle) is reported and when the duty cycle is
increased then the fan speed increases and higher fan rpm value(corresponding
to the duty cycle) is reported.

Jaghathiswari Rankappagounder Natarajan (2):
  Documentation: dt-bindings: Document bindings for ASPEED
AST2400/AST2500 PWM and Fan tach controller device driver
  drivers: hwmon: Support for ASPEED PWM/Fan tach

 .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt |  68 ++
 Documentation/hwmon/aspeed-pwm-tacho   |  22 +
 drivers/hwmon/Kconfig  |   9 +
 drivers/hwmon/Makefile |   1 +
 drivers/hwmon/aspeed-pwm-tacho.c   | 835 +
 5 files changed, 935 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
 create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
 create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c

--
2.12.2.715.g7642488e1d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 7/9] clk: hi6220: add debug APB clock

[Stephen Boyd]

On 03/26, Leo Yan wrote:
> The debug APB clock is absent in hi6220 driver, so this patch is to add
> support for it.
> 
> Signed-off-by: Leo Yan 
> ---

Applied to clk-next. I suspect we don't need a topic branch for
the DT header because arm-soc won't be taking the dts side of the
changes?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 5/9] coresight: use const for device_node structures

[Stephen Boyd]

On 03/26, Leo Yan wrote:
> Almost low level functions from open firmware have used const to
> qualify device_node structures, so add const for device_node
> parameters in of_coresight related functions.
> 
> Signed-off-by: Leo Yan 
> ---

Reviewed-by: Stephen Boyd 

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [GIT PULL] PCI: Support for configurable PCI endpoint

[Bjorn Helgaas]

On Mon, Mar 27, 2017 at 03:14:56PM +0530, Kishon Vijay Abraham I wrote:
> Hi Bjorn,
> 
> Please find the pull request for PCI endpoint support below. I've
> also included all the history here.

I tentatively applied this to pci/host-designware with the mostly trival
textual changes below.  If you post the series again, please include them.

I saw some acks to prior revisions, but few of them were included in this
series.   Can you collect them up?  If there are no other substantial
changes, I can insert them into my branch manually.

Bjorn



diff --git a/Documentation/PCI/00-INDEX b/Documentation/PCI/00-INDEX
index fd533c79fa19..00c9a90b6f38 100644
--- a/Documentation/PCI/00-INDEX
+++ b/Documentation/PCI/00-INDEX
@@ -15,10 +15,10 @@ pcieaer-howto.txt
 endpoint/pci-endpoint.txt
- guide to add endpoint controller driver and endpoint function driver.
 endpoint/pci-endpoint-cfs.txt
-   - guide to use configfs to configure the pci endpoint function.
+   - guide to use configfs to configure the PCI endpoint function.
 endpoint/pci-test-function.txt
-   - specification of *pci test* function device.
+   - specification of *PCI test* function device.
 endpoint/pci-test-howto.txt
- userguide for PCI endpoint test function.
 endpoint/function/binding/
-   - binding documentation for pci endpoint function
+   - binding documentation for PCI endpoint function
diff --git a/Documentation/PCI/endpoint/function/binding/pci-test.txt 
b/Documentation/PCI/endpoint/function/binding/pci-test.txt
index c44fc18d78cc..3b68b955fb50 100644
--- a/Documentation/PCI/endpoint/function/binding/pci-test.txt
+++ b/Documentation/PCI/endpoint/function/binding/pci-test.txt
@@ -13,5 +13,5 @@ cache_line_size: don't care
 subsys_vendor_id : don't care
 subsys_id   : don't care
 interrupt_pin   : Should be 1 - INTA, 2 - INTB, 3 - INTC, 4 -INTD
-msi_interrupts  : Should be 1 to 32 depending on the number of msi interrupts
+msi_interrupts  : Should be 1 to 32 depending on the number of MSI interrupts
   to test
diff --git a/Documentation/PCI/endpoint/pci-endpoint-cfs.txt 
b/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
index 8b2a8280b131..d740f29960a4 100644
--- a/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
+++ b/Documentation/PCI/endpoint/pci-endpoint-cfs.txt
@@ -1,10 +1,10 @@
CONFIGURING PCI ENDPOINT USING CONFIGFS
 Kishon Vijay Abraham I 
 
-The PCI Endpoint Core exposes configfs entry (pci_ep) in order to configure the
-PCI endpoint function and in order to bind the endpoint function
+The PCI Endpoint Core exposes configfs entry (pci_ep) to configure the
+PCI endpoint function and to bind the endpoint function
 with the endpoint controller. (For introducing other mechanisms to
-configure the PCI Endpoint Function refer [1]).
+configure the PCI Endpoint Function refer to [1]).
 
 *) Mounting configfs
 
diff --git a/Documentation/PCI/endpoint/pci-endpoint.txt 
b/Documentation/PCI/endpoint/pci-endpoint.txt
index 4a3e4388b37b..9b1d66829290 100644
--- a/Documentation/PCI/endpoint/pci-endpoint.txt
+++ b/Documentation/PCI/endpoint/pci-endpoint.txt
@@ -2,27 +2,27 @@
Kishon Vijay Abraham I 
 
 This document is a guide to use the PCI Endpoint Framework in order to create
-endpoint controller driver, endpoint function driver and using configfs
+endpoint controller driver, endpoint function driver, and using configfs
 interface to bind the function driver to the controller driver.
 
 1. Introduction
 
-*Linux* has a comprehensive PCI subsystem to support PCI controllers that
+Linux has a comprehensive PCI subsystem to support PCI controllers that
 operates in Root Complex mode. The subsystem has capability to scan PCI bus,
-assign memory resources and irq resources, load PCI driver (based on
-vendorid, deviceid), support other services like hot-plug, power management,
+assign memory resources and IRQ resources, load PCI driver (based on
+vendor ID, device ID), support other services like hot-plug, power management,
 advanced error reporting and virtual channels.
 
-However PCI controller IPs integrated in certain SoC is capable of operating
+However the PCI controller IP integrated in some SoCs is capable of operating
 either in Root Complex mode or Endpoint mode. PCI Endpoint Framework will
-add endpoint mode support in *Linux*. This will help to run Linux in an
+add endpoint mode support in Linux. This will help to run Linux in an
 EP system which can have a wide variety of use cases from testing or
-validation, co-processor accelerator etc..
+validation, co-processor accelerator, etc.
 
 2. PCI Endpoint Core
 
-The PCI Endpoint Core layer comprises of 3 components: the Endpoint Controller
-library, the Endpoint Function library and the configfs layer to bind the
+The PCI Endpoint Core layer comprises 3 components: the Endpoint Controller
+library, the Endpoint Function library, and the 

[PATCH 2/2] devicetree: Document the max31760 device binding.

[John Muir]

Signed-off-by: John Muir 
---
 .../devicetree/bindings/hwmon/max31760.txt | 58 ++
 1 file changed, 58 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31760.txt

diff --git a/Documentation/devicetree/bindings/hwmon/max31760.txt 
b/Documentation/devicetree/bindings/hwmon/max31760.txt
new file mode 100644
index ..43787a77c322
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/max31760.txt
@@ -0,0 +1,58 @@
+MAX31760 fan controller
+---
+
+This device supports I2C only. Many properties of this device are configurable
+thorugh the hwmon interface. See also Documentation/hwmon/max31760.
+
+Required node properties:
+- compatible : "maxim,max31760"
+- reg : The I2C address of the device. This is 0x50 - 0x57 depending on the
+   hardware configuration.
+
+Optional node properties:
+- maxim,fan1-enabled   - 1 to enable, 0 to disable. Default: 1.
+- maxim,fan2-enabled   - 1 to enable, 0 to disable. Default: 1.
+- maxim,fan1-label - String: Hwmon fan1_label.
+- maxim,fan2-label - String: Hwmon fan2_label.
+- maxim,fan-fail-full-only - Set to 1 to assert a fan failure only when the
+ PWM is at 100%. Default: 0.
+- maxim,fan-rd-signal  - Set to 1 if fan(s) provide a rotation
+ detection (RD) signal, or 0 if the fan
+ generates square-wave pulses. Default: 0.
+- maxim,fan-rd-polarity- 0: RD is low when the fan is running.
+ 1: RD is high when the fan is running.
+ Only relevant when fan-rd-signal is 1.
+ Default: 0.
+- maxim,fan-signal-enabled - Set to 1 if externally driving FF/FS low
+ should force PWM output to 100%. Default: 0.
+- maxim,fan-spin-up-enabled - For fan startup: Set to 1 to set the PWM to
+ 100% until tach is detected or two seconds
+ have passed before reducing to the target
+ value. Default: 0.
+- maxim,pwm-polarity   - 0: 100% PWM is when PWM is high.
+ 1: 100% PWM is when PWM is low.
+ Default: 0.
+- maxim,pwm-pulse-stretch-enabled
+   - 1 to enable PWM pulse stretching, 0 to
+ disable. Default: 0.
+- maxim,pwm-zero-fan-can-fail  - 0: Fan failure detection disabled when PWM is
+ramping to 0%.
+ 1: Fan failure detection enabled for all PWM
+values.
+ Default: 0.
+- maxim,temp1-label- String: Hwmon temp1_label.
+- maxim,temp2-label- String: Hwmon temp2_label.
+- maxim,temp2-ideality - Set ideality factor for the remote temperature
+ sensor. Integer with range 0 to 63,
+ representing a multiplication factor of 0.9844
+ to 1.0489. Default: 24 (1.0080).
+
+Example:
+   max31760@50 {
+   compatible = "maxim,max31760";
+   reg = <0x50>;
+   maxim,fan1-label = "Left";
+   maxim,fan2-label = "Right";
+   maxim,fan-spin-up-enabled = <1>;
+   maxim,temp2-label = "CPU";
+   };
-- 
2.12.2.715.g7642488e1d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] hwmon: Add MAX31760 fan controller driver.

[John Muir]

Add a driver for the Maxim Integrated MAX31760 Precision Fan
Speed Controller.

Signed-off-by: John Muir 
---
 Documentation/hwmon/max31760 |   41 ++
 drivers/hwmon/Kconfig|   10 +
 drivers/hwmon/Makefile   |1 +
 drivers/hwmon/max31760.c | 1430 ++
 4 files changed, 1482 insertions(+)
 create mode 100644 Documentation/hwmon/max31760
 create mode 100644 drivers/hwmon/max31760.c

diff --git a/Documentation/hwmon/max31760 b/Documentation/hwmon/max31760
new file mode 100644
index ..95937844ed18
--- /dev/null
+++ b/Documentation/hwmon/max31760
@@ -0,0 +1,41 @@
+Kernel driver max31760
+==
+
+Supported chips:
+  * Maxim Integrated MAX31760
+Prefix: 'max31760'
+Addresses scanned: none
+Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31760.pdf
+
+Author:
+   John Muir 
+
+Description
+---
+
+The MAX31760 integrates temperature sensing along with precision PWM fan
+control. Please read the datasheet referenced above for a comprehensive
+description of this device.
+
+This device driver's hwmon integration provides the common sysfs interfaces to
+manage two fans and two temperature sensors, and pwm controls for the fan 
speed.
+A temperature to pwm lookup table is exposed via a series of 'auto_point'
+configuration files. See Documentation/hwmon/sysfs-interface for more
+information.
+
+The following custom controls are defined (in the custom sub-directory):
+
+control- Accepts control commands:
+ "reset"   - Execute a soft reset of the device.
+ "clearff" - Clear the fan fault.
+
+eeprom_read- Read from the EEPROM into registers.
+eeprom_write- Write register contents to the EEPROM.
+ Write "0" to these to read or write the entire register
+ contents. Write a bit-field as per the data-sheet to write a
+ portion of the register contents.
+
+pwm1_fan_fault  - PWM value in the range of 0 to 255 used when a fan is faulty.
+
+pwm1_ramp_rate  - PWM increment per second when the PWM value is changed.
+ Accepted values are 8, 16, 32, or 255 (instantaneous).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 2d5447bebab6..3aef5c07f1c3 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -849,6 +849,16 @@ config SENSORS_MAX6697
  This driver can also be built as a module.  If so, the module
  will be called max6697.
 
+config SENSORS_MAX31760
+   tristate "Maxim MAX31760 fan controller"
+   depends on I2C
+   help
+ If you say yes here you get support for the Maxim Integrated
+ MAX31760 Precision Fan-Speed Controller.
+
+ This driver can also be built as a module.  If so, the module
+ will be called max31760.
+
 config SENSORS_MAX31790
tristate "Maxim MAX31790 sensor chip"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index 76e1456ddf2f..7b08f069d5a4 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -116,6 +116,7 @@ obj-$(CONFIG_SENSORS_MAX6639)   += max6639.o
 obj-$(CONFIG_SENSORS_MAX6642)  += max6642.o
 obj-$(CONFIG_SENSORS_MAX6650)  += max6650.o
 obj-$(CONFIG_SENSORS_MAX6697)  += max6697.o
+obj-$(CONFIG_SENSORS_MAX31760)  += max31760.o
 obj-$(CONFIG_SENSORS_MAX31790) += max31790.o
 obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
 obj-$(CONFIG_SENSORS_MCP3021)  += mcp3021.o
diff --git a/drivers/hwmon/max31760.c b/drivers/hwmon/max31760.c
new file mode 100644
index ..735b4fe9a510
--- /dev/null
+++ b/drivers/hwmon/max31760.c
@@ -0,0 +1,1430 @@
+/* Maxim Integrated MAX31760 Precision Fan-Speed Controller driver
+ *
+ * Copyright (C) 2017 John Muir 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "max31760"
+
+#define MAX31760_REG_CR1   0x00 /* Control Register 1 */
+#define MAX31760_CR1_TIS0x01 /* Temperature Index Source */
+#define MAX31760_CR1_MTI0x02 /* Maximum Temperature Index */
+#define MAX31760_CR1_PPS0x04 /* PWM Polarity */
+#define MAX31760_CR1_DRV0x18 /* PWM Frequency */
+#define MAX31760_DRV_33HZ   0x00
+#define MAX31760_DRV_150HZ  0x08
+#define MAX31760_DRV_1500HZ 0x10
+#define MAX31760_DRV_25KHZ  

[PATCH 0/2] Add Maxim Integrated MAX31760 fan controller driver.

[John Muir]

Add a device driver for the MAX31760 I2C device with a hwmon interface and
a few open firmware device properties.

John Muir (2):
  hwmon: Add MAX31760 fan controller driver.
  devicetree: Document the max31760 device binding.

 .../devicetree/bindings/hwmon/max31760.txt |   58 +
 Documentation/hwmon/max31760   |   41 +
 drivers/hwmon/Kconfig  |   10 +
 drivers/hwmon/Makefile |1 +
 drivers/hwmon/max31760.c   | 1430 
 5 files changed, 1540 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31760.txt
 create mode 100644 Documentation/hwmon/max31760
 create mode 100644 drivers/hwmon/max31760.c

-- 
2.12.2.715.g7642488e1d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach

[Guenter Roeck]

On 04/04/2017 05:55 AM, Guenter Roeck wrote:

On 04/03/2017 04:30 PM, Jaghathiswari Rankappagounder Natarajan wrote:

The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
inputs.
The device driver matches on the device tree node. The configuration
values are read from the device tree and written to the respective registers.
The driver provides a sysfs entries through which the user can
configure the duty-cycle value (ranging from 0 to 100 percent) and read
the fan tach rpm value.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan 


Applied.



Follow-up: Sparse complains as follows.

drivers/hwmon/aspeed-pwm-tacho.c:156:14: warning: symbol 'regs' was not 
declared. Should it be static?
drivers/hwmon/aspeed-pwm-tacho.c:324:30: warning: incorrect type in initializer 
(different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:324:30:expected void [noderef] *regs
drivers/hwmon/aspeed-pwm-tacho.c:324:30:got void *context
drivers/hwmon/aspeed-pwm-tacho.c:333:30: warning: incorrect type in initializer 
(different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:333:30:expected void [noderef] *regs
drivers/hwmon/aspeed-pwm-tacho.c:333:30:got void *context
drivers/hwmon/aspeed-pwm-tacho.c:516:25: warning: dubious: !x & !y
drivers/hwmon/aspeed-pwm-tacho.c:793:24: warning: incorrect type in argument 3 
(different address spaces)
drivers/hwmon/aspeed-pwm-tacho.c:793:24:expected void *bus_context
drivers/hwmon/aspeed-pwm-tacho.c:793:24:got void [noderef] 
*[assigned] regs

Can you please look into this and send me a follow-up patch ?

156 seems unnecessary/unused, 324, 333, and 793 might need a typecast, 516 is 
really fishy.

Thanks,
Guenter


Thanks,
Guenter


---
 v6
- Corrected odd line breaks
- Changed upto to up to
- Dropped unrelated changes
- Removed struct and used regs pointer directly
- Made groups to be null terminated
- Made correction in calculation of val/raw_data
- Removed else after return
- Removed unnecessary continuation lines

 v5:
- Changed the driver to suit the changes in the device tree documentation

 v4:
- Modified this driver to suit the representation in the devicetree

 v3:
- Only sent out device tree documentation; did not send this driver

 v2:
- Used BIT()
- Used regmap
- Avoided division when raw data is 0
- Removed empty lines between declaration
- Removed macros; Used two attribute groups and used is_visible callback
- Returned error when properties are undefined
- Removed .owner field
- Used PTR_ERR_OR_ZERO
- Removed explicit of_node_put for child nodes

 Documentation/hwmon/aspeed-pwm-tacho |  22 +
 drivers/hwmon/Kconfig|   9 +
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/aspeed-pwm-tacho.c | 846 +++
 4 files changed, 878 insertions(+)
 create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
 create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c

diff --git a/Documentation/hwmon/aspeed-pwm-tacho 
b/Documentation/hwmon/aspeed-pwm-tacho
new file mode 100644
index ..7cfb34977460
--- /dev/null
+++ b/Documentation/hwmon/aspeed-pwm-tacho
@@ -0,0 +1,22 @@
+Kernel driver aspeed-pwm-tacho
+==
+
+Supported chips:
+ASPEED AST2400/2500
+
+Authors:
+
+
+Description:
+
+This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
+controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+fanX_inputroprovide current fan rotation value in RPM as reported
+by the fan to the device.
+
+pwmXrwget or set PWM fan control value. This is an integer
+value between 0(off) and 255(full speed).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..757b5b0705bf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -341,6 +341,15 @@ config SENSORS_ASB100
   This driver can also be built as a module.  If so, the module
   will be called asb100.

+config SENSORS_ASPEED
+tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver"
+help
+  This driver provides support for ASPEED AST2400/AST2500 PWM
+  and Fan Tacho controllers.
+
+  This driver can also be built as a module. If so, the module
+  will be called aspeed_pwm_tacho.
+
 config SENSORS_ATXP1
 tristate "Attansic ATXP1 VID controller"
 depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..83025cc9bb45 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475)+= adt7475.o
 obj-$(CONFIG_SENSORS_APPLESMC)+= applesmc.o
 obj-$(CONFIG_SENSORS_ARM_SCPI)+= scpi-hwmon.o
 obj-$(CONFIG_SENSORS_ASC7621)+= asc7621.o

Re: [PATCH v6.1 0/4] drm: bridge: dw-hdmi: Add support for Custom PHYs

[Neil Armstrong]

On 04/04/2017 02:31 PM, Neil Armstrong wrote:
> The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
> in combination with a very custom PHY.
> 
> Thanks to Laurent Pinchart's changes, the HW report the following :
>  Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)
> 
> The following differs from common PHY integration as managed in the current
> driver :
>  - Amlogic PHY is not configured through the internal I2C link
>  - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the 
> controller
>  - Amlogic PHY do not export HPD ands RxSense signals to the controller
> 
> And finally, concerning the controller integration :
>  - the Controller registers are not flat memory-mapped, and uses an
> addr+read/write register pair to write all registers.
>  - Inputs only YUV444 pixel data
> 
> Most of these uses case are implemented in Laurent Pinchart v5.1 patchset 
> merged
> in drm-misc-next branch.
> 
> This is why the following patchset implements :
>  - Configure the Input format from the plat_data
>  - Add PHY callback to handle HPD and RxSense out of the dw-hdmi driver
> 
> To implement the input format handling, the Synopsys HDMIT TX Controller input
> V4L bus formats are used and missing formats + documentation are added.
> 
> This patchset makes the Amlogic GX SoCs HDMI output successfully work, and is
> also tested on the RK3288 ACT8846 EVB Board.
> 
> Changes since v6 at [8] :
>  - Dropped already merged media patches in 
> topic/synopsys-media-formats-2017-04-03 tag
>  - Reword the patch "Switch to V4L bus format and encodings" commit message
>  - Fix typo in patch "Switch to V4L bus format and encodings"
>  - Add Laurent Pinchart reviewed/acked-by's
>  - Rebased on drm-misc-next at 9c4ad466d1dd
> 
> Changes since v5.1 at [7] :
>  - Rework of the 48bit tables in V4L bus formats documentation
>  - Add Archit reviewed-by's
> 
> Changes since v5 at [6] :
>  - Small addition in V4L YUV bus formats documentation
> 
> Changes since v4 at [5] :
>  - Rebased on drm-misc-next at bd283d2f66c2
>  - Fix 4:2:0 bus formats naming
>  - Renamed function fd_registered to i2c_init in dw-hdmi.c
> 
> Changes since v3 at [4] :
>  - Fix 4:2:0 bus formats naming
>  - Add separate 36bit and 48bit tables for bus formats documentation
>  - Added 4:2:0 bus config in hdmi_video_sample
>  - Moved dw_hdmi documentation in a "bridge" subdir
>  - Rebase on drm-misc-next at 62c58af32c93
> 
> Changes since v2 at [3] :
>  - Rebase on laurent patch "Extract PHY interrupt setup to a function"
>  - Reduce phy operations
>  - Switch the V4L bus formats and encodings instead of custom enum
> 
> Changes since v1 at [2] :
>  - Drop patches submitted by laurent
> 
> Changes since RFC at [1] :
>  - Regmap fixup for 4bytes register access, tested on RK3288 SoC
>  - Move phy callbacks to phy_ops and move Synopsys PHY calls into default ops
>  - Move HDMI link data into shared header
>  - Move Pixel Encoding enum to shared header
> 
> [1] 
> http://lkml.kernel.org/r/1484656294-6140-1-git-send-email-narmstr...@baylibre.com
> [2] 
> http://lkml.kernel.org/r/1485774318-21916-1-git-send-email-narmstr...@baylibre.com
> [3] 
> http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
> [4] 
> http://lkml.kernel.org/r/1488904944-14285-1-git-send-email-narmstr...@baylibre.com
> [5] 
> http://lkml.kernel.org/r/1490109161-20529-1-git-send-email-narmstr...@baylibre.com
> [6] 
> http://lkml.kernel.org/r/1490864675-17336-1-git-send-email-narmstr...@baylibre.com
> [7] 
> http://lkml.kernel.org/r/1490970319-24981-1-git-send-email-narmstr...@baylibre.com
> [8] 
> http://lkml.kernel.org/r/1491230558-10804-1-git-send-email-narmstr...@baylibre.com
> 
> Laurent Pinchart (1):
>   drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function
> 
> Neil Armstrong (3):
>   drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
>   drm: bridge: dw-hdmi: Add Documentation on supported input formats
>   drm: bridge: dw-hdmi: Move HPD handling to PHY operations
> 
>  Documentation/gpu/bridge/dw-hdmi.rst  |  15 +
>  Documentation/gpu/index.rst   |   1 +
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 470 
> --
>  include/drm/bridge/dw_hdmi.h  |  68 +
>  4 files changed, 398 insertions(+), 156 deletions(-)
>  create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst
> 

Applied to drm-misc-next

Thanks Daniel, Sean,
Neil
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

[Steven Rostedt]

On Tue, 4 Apr 2017 20:24:59 +0900
Masami Hiramatsu  wrote:

> On Mon,  3 Apr 2017 12:36:22 +0200
> Alban Crequy  wrote:
> 
> > From: Alban Crequy 
> > 
> > When a kretprobe is installed on a kernel function, there is a maximum
> > limit of how many calls in parallel it can catch (aka "maxactive"). A
> > kernel module could call register_kretprobe() and initialize maxactive
> > (see example in samples/kprobes/kretprobe_example.c).
> > 
> > But that is not exposed to userspace and it is currently not possible to
> > choose maxactive when writing to /sys/kernel/debug/tracing/kprobe_events
> > 
> > The default maxactive can be as low as 1 on single-core with a
> > non-preemptive kernel. This is too low and we need to increase it not
> > only for recursive functions, but for functions that sleep or resched.
> > 
> > This patch updates the format of the command that can be written to
> > kprobe_events so that maxactive can be optionally specified.
> > 
> > I need this for a bpf program attached to the kretprobe of
> > inet_csk_accept, which can sleep for a long time.
> > 
> > This patch includes a basic selftest:
> >   
> > > # ./ftracetest -v  test.d/kprobe/
> > > === Ftrace unit tests ===
> > > [1] Kprobe dynamic event - adding and removing[PASS]
> > > [2] Kprobe dynamic event - busy event check   [PASS]
> > > [3] Kprobe dynamic event with arguments   [PASS]
> > > [4] Kprobes event arguments with types[PASS]
> > > [5] Kprobe dynamic event with function tracer [PASS]
> > > [6] Kretprobe dynamic event with arguments[PASS]
> > > [7] Kretprobe dynamic event with maxactive[PASS]
> > >
> > > # of passed:  7
> > > # of failed:  0
> > > # of unresolved:  0
> > > # of untested:  0
> > > # of unsupported:  0
> > > # of xfailed:  0
> > > # of undefined(test bug):  0  
> > 
> > BugLink: https://github.com/iovisor/bcc/issues/1072
> > Signed-off-by: Alban Crequy   
> 
> Looks good to me.
> 
> Acked-by: Masami Hiramatsu 
> 

Applied, thanks!

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

[Radim Krčmář]

[Cc qemu-devel as we've gone off-topic]

2017-04-04 15:15+0200, Alexander Graf:
> On 04/04/2017 03:13 PM, Radim Krčmář wrote:
>> 2017-04-04 14:51+0200, Alexander Graf:
>> > Please see my patch to force enable CPUID bits ;).
>> Nice.  MWAIT could also use setting of arbitrary values for its leaf,
>> but a generic interface for that would probably look clunky on the
>> command line ...
> 
> 
> I think we should have an interface similar to smbios for that eventually.
> Something where you can explicitly set arbitrary CPUID leaf information
> using leaf specific syntax. There are more leafs where it would make sense -
> cache topology for example.

Right, separating cpuid from -cpu makes it bearable, like

  -cpuid leaf=%x[,subleaf=%x][,eax=%x][,ebx=%x][,ecx=%x][,edx=%x]

And Having multiple interfaces for the same thing would result in some
corner case decisions ...
I think QEMU should check that feature flags specified flags specified
by -cpu are not cleared by -cpuid.
I'm not sure if setters like "|=" and "&=~" would be beneficial in some
cases.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

[Alexander Graf]

On 04/04/2017 03:13 PM, Radim Krčmář wrote:

2017-04-04 14:51+0200, Alexander Graf:

On 04/04/2017 02:39 PM, Radim Krčmář wrote:

2017-04-03 12:04+0200, Alexander Graf:

So coming back to the original patch, is there anything that should keep us
from exposing MWAIT straight into the guest at all times?

Just minor issues:
   * OS X on Core 2 fails for unknown reason if we disable the instruction
 trapping, which is an argument against doing it by default

So for that we should try and see if changing the exposed CPUID MWAIT leaf
helps. Currently we return 0/0 which is pretty bogus and might be the reason
OSX fails.

We have tried to pass host's CPUID MWAIT leaf and it still failed:
https://www.spinics.net/lists/kvm/msg146686.html

I wouldn't mind breaking that particular combination of OS X and
hardware, but I'm worried to do it because we don't understand why it
broke, so there could be more ...


   * idling guests would consume host CPU, which is a significant change
 in behavior and shouldn't be done without userspace's involvement

That's the same as today, as idling guests with MWAIT would also today end
up in a NOP emulated loop.

Please bear in mind that I do not advocate to expose the MWAIT CPUID flag.
This is only for the instruction trap.

Ah, makes sense.


I think the best compromise is to add a capability for the MWAIT VM-exit
controls and let userspace expose MWAIT if it wishes to.
Will send a patch.

Please see my patch to force enable CPUID bits ;).

Nice.  MWAIT could also use setting of arbitrary values for its leaf,
but a generic interface for that would probably look clunky on the
command line ...



I think we should have an interface similar to smbios for that 
eventually. Something where you can explicitly set arbitrary CPUID leaf 
information using leaf specific syntax. There are more leafs where it 
would make sense - cache topology for example.



Alex


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

[Radim Krčmář]

2017-04-04 14:51+0200, Alexander Graf:
> On 04/04/2017 02:39 PM, Radim Krčmář wrote:
>> 2017-04-03 12:04+0200, Alexander Graf:
>> > So coming back to the original patch, is there anything that should keep us
>> > from exposing MWAIT straight into the guest at all times?
>> Just minor issues:
>>   * OS X on Core 2 fails for unknown reason if we disable the instruction
>> trapping, which is an argument against doing it by default
> 
> So for that we should try and see if changing the exposed CPUID MWAIT leaf
> helps. Currently we return 0/0 which is pretty bogus and might be the reason
> OSX fails.

We have tried to pass host's CPUID MWAIT leaf and it still failed:
https://www.spinics.net/lists/kvm/msg146686.html

I wouldn't mind breaking that particular combination of OS X and
hardware, but I'm worried to do it because we don't understand why it
broke, so there could be more ...

>>   * idling guests would consume host CPU, which is a significant change
>> in behavior and shouldn't be done without userspace's involvement
> 
> That's the same as today, as idling guests with MWAIT would also today end
> up in a NOP emulated loop.
> 
> Please bear in mind that I do not advocate to expose the MWAIT CPUID flag.
> This is only for the instruction trap.

Ah, makes sense.

>> I think the best compromise is to add a capability for the MWAIT VM-exit
>> controls and let userspace expose MWAIT if it wishes to.
>> Will send a patch.
> 
> Please see my patch to force enable CPUID bits ;).

Nice.  MWAIT could also use setting of arbitrary values for its leaf,
but a generic interface for that would probably look clunky on the
command line ...
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH linux v6 2/2] drivers: hwmon: Support for ASPEED PWM/Fan tach

[Guenter Roeck]

On 04/03/2017 04:30 PM, Jaghathiswari Rankappagounder Natarajan wrote:

The ASPEED AST2400/2500 PWM controller supports 8 PWM output ports.
The ASPEED AST2400/2500 Fan tach controller supports 16 tachometer
inputs.
The device driver matches on the device tree node. The configuration
values are read from the device tree and written to the respective registers.
The driver provides a sysfs entries through which the user can
configure the duty-cycle value (ranging from 0 to 100 percent) and read
the fan tach rpm value.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan 


Applied.

Thanks,
Guenter


---
 v6
- Corrected odd line breaks
- Changed upto to up to
- Dropped unrelated changes
- Removed struct and used regs pointer directly
- Made groups to be null terminated
- Made correction in calculation of val/raw_data
- Removed else after return
- Removed unnecessary continuation lines

 v5:
- Changed the driver to suit the changes in the device tree documentation

 v4:
- Modified this driver to suit the representation in the devicetree

 v3:
- Only sent out device tree documentation; did not send this driver

 v2:
- Used BIT()
- Used regmap
- Avoided division when raw data is 0
- Removed empty lines between declaration
- Removed macros; Used two attribute groups and used is_visible callback
- Returned error when properties are undefined
- Removed .owner field
- Used PTR_ERR_OR_ZERO
- Removed explicit of_node_put for child nodes

 Documentation/hwmon/aspeed-pwm-tacho |  22 +
 drivers/hwmon/Kconfig|   9 +
 drivers/hwmon/Makefile   |   1 +
 drivers/hwmon/aspeed-pwm-tacho.c | 846 +++
 4 files changed, 878 insertions(+)
 create mode 100644 Documentation/hwmon/aspeed-pwm-tacho
 create mode 100644 drivers/hwmon/aspeed-pwm-tacho.c

diff --git a/Documentation/hwmon/aspeed-pwm-tacho 
b/Documentation/hwmon/aspeed-pwm-tacho
new file mode 100644
index ..7cfb34977460
--- /dev/null
+++ b/Documentation/hwmon/aspeed-pwm-tacho
@@ -0,0 +1,22 @@
+Kernel driver aspeed-pwm-tacho
+==
+
+Supported chips:
+   ASPEED AST2400/2500
+
+Authors:
+   
+
+Description:
+
+This driver implements support for ASPEED AST2400/2500 PWM and Fan Tacho
+controller. The PWM controller supports upto 8 PWM outputs. The Fan tacho
+controller supports up to 16 tachometer inputs.
+
+The driver provides the following sensor accesses in sysfs:
+
+fanX_input ro  provide current fan rotation value in RPM as reported
+   by the fan to the device.
+
+pwmX   rw  get or set PWM fan control value. This is an integer
+   value between 0(off) and 255(full speed).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 45cef3d2c75c..757b5b0705bf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -341,6 +341,15 @@ config SENSORS_ASB100
  This driver can also be built as a module.  If so, the module
  will be called asb100.

+config SENSORS_ASPEED
+   tristate "ASPEED AST2400/AST2500 PWM and Fan tach driver"
+   help
+ This driver provides support for ASPEED AST2400/AST2500 PWM
+ and Fan Tacho controllers.
+
+ This driver can also be built as a module. If so, the module
+ will be called aspeed_pwm_tacho.
+
 config SENSORS_ATXP1
tristate "Attansic ATXP1 VID controller"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index aecf4ba17460..83025cc9bb45 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -46,6 +46,7 @@ obj-$(CONFIG_SENSORS_ADT7475) += adt7475.o
 obj-$(CONFIG_SENSORS_APPLESMC) += applesmc.o
 obj-$(CONFIG_SENSORS_ARM_SCPI) += scpi-hwmon.o
 obj-$(CONFIG_SENSORS_ASC7621)  += asc7621.o
+obj-$(CONFIG_SENSORS_ASPEED)   += aspeed-pwm-tacho.o
 obj-$(CONFIG_SENSORS_ATXP1)+= atxp1.o
 obj-$(CONFIG_SENSORS_CORETEMP) += coretemp.o
 obj-$(CONFIG_SENSORS_DA9052_ADC)+= da9052-hwmon.o
diff --git a/drivers/hwmon/aspeed-pwm-tacho.c b/drivers/hwmon/aspeed-pwm-tacho.c
new file mode 100644
index ..29010ad94208
--- /dev/null
+++ b/drivers/hwmon/aspeed-pwm-tacho.c
@@ -0,0 +1,846 @@
+/*
+ * Copyright (c) 2016 Google, Inc
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 or later as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* ASPEED PWM & FAN Tach Register Definition */
+#define ASPEED_PTCR_CTRL   0x00
+#define ASPEED_PTCR_CLK_CTRL   0x04
+#define ASPEED_PTCR_DUTY0_CTRL 0x08
+#define ASPEED_PTCR_DUTY1_CTRL 0x0c
+#define ASPEED_PTCR_TYPEM_CTRL 0x10
+#define ASPEED_PTCR_TYPEM_CTRL10x14
+#define 

Re: [PATCH linux v6 1/2] Documentation: dt-bindings: Document bindings for ASPEED AST2400/AST2500 PWM and Fan tach controller device driver

[Guenter Roeck]

On 04/03/2017 04:30 PM, Jaghathiswari Rankappagounder Natarajan wrote:

This binding provides interface for adding values related to ASPEED
AST2400/2500 PWM and Fan tach controller support.
The PWM controller can support upto 8 PWM output ports.
The Fan tach controller can support upto 16 tachometer inputs.

Signed-off-by: Jaghathiswari Rankappagounder Natarajan 


Applied with Acked-by: From Rob (for v5 with the requested changes made).

Thanks,
Guenter


---
 v6:
- Changed to aspeed,fan-tach-ch

 v5:
- Changed the naming scheme to aspeed,ast2400/2500-pwm-tacho
- Removed gpio pin muxing
- Added aspeed vendor prefix for fan-tach-ch
- Changed to fan@0/1
- Changed reg to 32 bits

 v4:
- Used 'reg'

 v3:
- Made the structure more common

 v2:
- Removed '_' in node and property names
- Gave some explanation for the properties used

 .../devicetree/bindings/hwmon/aspeed-pwm-tacho.txt | 68 ++
 1 file changed, 68 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt

diff --git a/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt 
b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
new file mode 100644
index ..ac0a69ab0755
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/aspeed-pwm-tacho.txt
@@ -0,0 +1,68 @@
+ASPEED AST2400/AST2500 PWM and Fan Tacho controller device driver
+
+The ASPEED PWM controller can support upto 8 PWM outputs. The ASPEED Fan Tacho
+controller can support upto 16 Fan tachometer inputs.
+
+There can be upto 8 fans supported. Each fan can have one PWM output and
+one/two Fan tach inputs.
+
+Required properties for pwm-tacho node:
+- #address-cells : should be 1.
+
+- #size-cells : should be 1.
+
+- reg : address and length of the register set for the device.
+
+- pinctrl-names : a pinctrl state named "default" must be defined.
+
+- pinctrl-0 : phandle referencing pin configuration of the PWM ports.
+
+- compatible : should be "aspeed,ast2400-pwm-tacho" for AST2400 and
+  "aspeed,ast2500-pwm-tacho" for AST2500.
+
+- clocks : a fixed clock providing input clock frequency(PWM
+  and Fan Tach clock)
+
+fan subnode format:
+===
+Under fan subnode there can upto 8 child nodes, with each child node
+representing a fan. If there are 8 fans each fan can have one PWM port and
+one/two Fan tach inputs.
+
+Required properties for each child node:
+- reg : should specify PWM source port.
+   integer value in the range 0 to 7 with 0 indicating PWM port A and
+   7 indicating PWM port H.
+
+- aspeed,fan-tach-ch : should specify the Fan tach input channel.
+integer value in the range 0 through 15, with 0 indicating
+   Fan tach channel 0 and 15 indicating Fan tach channel 15.
+   Atleast one Fan tach input channel is required.
+
+Examples:
+
+pwm_tacho_fixed_clk: fixedclk {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2400>;
+}
+
+pwm_tacho: pwmtachocontroller@1e786000 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   reg = <0x1E786000 0x1000>;
+   compatible = "aspeed,ast2500-pwm-tacho";
+   clocks = <_tacho_fixed_clk>;
+   pinctrl-names = "default";
+   pinctrl-0 = <_pwm0_default _pwm1_default>;
+
+   fan@0 {
+   reg = <0x00>;
+   aspeed,fan-tach-ch = /bits/ 8 <0x00>;
+   };
+
+   fan@1 {
+   reg = <0x01>;
+   aspeed,fan-tach-ch = /bits/ 8 <0x01 0x02>;
+   };
+};
--
2.12.2.715.g7642488e1d-goog

--
To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

[Alexander Graf]

On 04/04/2017 02:39 PM, Radim Krčmář wrote:

2017-04-03 12:04+0200, Alexander Graf:

On 03/29/2017 02:11 PM, Radim Krčmář wrote:

2017-03-28 13:35-0700, Jim Mattson:

On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář  wrote:

2017-03-27 15:34+0200, Alexander Graf:

On 15/03/2017 22:22, Michael S. Tsirkin wrote:

Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a problem:
unless explicitly provided with kernel command line argument
"idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability,
without checking CPUID.

We currently emulate that as a NOP but on VMX we can do better: let
guest stop the CPU until timer, IPI or memory change.  CPU will be busy
but that isn't any worse than a NOP emulation.

Note that mwait within guests is not the same as on real hardware
because halt causes an exit while mwait doesn't.  For this reason it
might not be a good idea to use the regular MWAIT flag in CPUID to
signal this capability.  Add a flag in the hypervisor leaf instead.

So imagine we had proper MWAIT emulation capabilities based on page faults.
In that case, we could do something as fancy as

Treat MWAIT as pass-through by default

Have a per-vcpu monitor timer 10 times a second in the background that
checks which instruction we're in

If we're in mwait for the last - say - 1 second, switch to emulated MWAIT,
if $IP was in non-mwait within that time, reset counter.

Or we could reuse external interrupts for sampling.  Exits trigerred by
them would check for current instruction (probably would be best to
limit just to timer tick) and a sufficient ratio (> 0?) of other exits
would imply that MWAIT is not used.


Or instead maybe just reuse the adapter hlt logic?

Emulated MWAIT is very similar to emulated HLT, so reusing the logic
makes sense.  We would just add new wakeup methods.


Either way, with that we should be able to get super low latency IPIs
running while still maintaining some sanity on systems which don't have
dedicated CPUs for workloads.

And we wouldn't need guest modifications, which is a great plus. So older
guests (and Windows?) could benefit from mwait as well.

There is no need guest modifications -- it could be exposed as standard
MWAIT feature to the guest, with responsibilities for guest/host-impact
on the user.

I think that the page-fault based MWAIT would require paravirt if it
should be enabled by default, because of performance concerns:
Enabling write protection on a page needs a VM exit on all other VCPUs
when beginning monitoring (to reload page permissions and prevent missed
writes).
We'd want to keep trapping writes to the page all the time because
toggling is slow, but this could regress performance for an OS that has
other data accessed by other VCPUs in that page.
No current interface can tell the guest that it should reserve the whole
page instead of what CPUID[5] says and that writes to the monitored page
are not "cheap", but can trigger a VM exit ...

CPUID.05H:EBX is supposed to address the false sharing issue. IIRC,
VMware Fusion reports 64 in CPUID.05H:EAX and 4096 in CPUID.05H:EBX
when running Mac OS X guests. Per Intel's SDM volume 3, section
8.10.5, "To avoid false wake-ups; use the largest monitor line size to
pad the data structure used to monitor writes. Software must make sure
that beyond the data structure, no unrelated data variable exists in
the triggering area for MWAIT. A pad may be needed to avoid this
situation." Unfortunately, most operating systems do not follow this
advice.

Right, EBX provides what we need to expose that the whole page is
monitored, thanks!

So coming back to the original patch, is there anything that should keep us
from exposing MWAIT straight into the guest at all times?

Just minor issues:
  * OS X on Core 2 fails for unknown reason if we disable the instruction
trapping, which is an argument against doing it by default


So for that we should try and see if changing the exposed CPUID MWAIT 
leaf helps. Currently we return 0/0 which is pretty bogus and might be 
the reason OSX fails.



  * idling guests would consume host CPU, which is a significant change
in behavior and shouldn't be done without userspace's involvement


That's the same as today, as idling guests with MWAIT would also today 
end up in a NOP emulated loop.


Please bear in mind that I do not advocate to expose the MWAIT CPUID 
flag. This is only for the instruction trap.



I think the best compromise is to add a capability for the MWAIT VM-exit
controls and let userspace expose MWAIT if it wishes to.
Will send a patch.



Please see my patch to force enable CPUID bits ;).



Alex


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 untested] kvm: better MWAIT emulation for guests

[Radim Krčmář]

2017-04-03 12:04+0200, Alexander Graf:
> On 03/29/2017 02:11 PM, Radim Krčmář wrote:
>> 2017-03-28 13:35-0700, Jim Mattson:
>> > On Tue, Mar 28, 2017 at 7:28 AM, Radim Krčmář  wrote:
>> > > 2017-03-27 15:34+0200, Alexander Graf:
>> > > > On 15/03/2017 22:22, Michael S. Tsirkin wrote:
>> > > > > Guests running Mac OS 5, 6, and 7 (Leopard through Lion) have a 
>> > > > > problem:
>> > > > > unless explicitly provided with kernel command line argument
>> > > > > "idlehalt=0" they'd implicitly assume MONITOR and MWAIT availability,
>> > > > > without checking CPUID.
>> > > > > 
>> > > > > We currently emulate that as a NOP but on VMX we can do better: let
>> > > > > guest stop the CPU until timer, IPI or memory change.  CPU will be 
>> > > > > busy
>> > > > > but that isn't any worse than a NOP emulation.
>> > > > > 
>> > > > > Note that mwait within guests is not the same as on real hardware
>> > > > > because halt causes an exit while mwait doesn't.  For this reason it
>> > > > > might not be a good idea to use the regular MWAIT flag in CPUID to
>> > > > > signal this capability.  Add a flag in the hypervisor leaf instead.
>> > > > So imagine we had proper MWAIT emulation capabilities based on page 
>> > > > faults.
>> > > > In that case, we could do something as fancy as
>> > > > 
>> > > > Treat MWAIT as pass-through by default
>> > > > 
>> > > > Have a per-vcpu monitor timer 10 times a second in the background that
>> > > > checks which instruction we're in
>> > > > 
>> > > > If we're in mwait for the last - say - 1 second, switch to emulated 
>> > > > MWAIT,
>> > > > if $IP was in non-mwait within that time, reset counter.
>> > > Or we could reuse external interrupts for sampling.  Exits trigerred by
>> > > them would check for current instruction (probably would be best to
>> > > limit just to timer tick) and a sufficient ratio (> 0?) of other exits
>> > > would imply that MWAIT is not used.
>> > > 
>> > > > Or instead maybe just reuse the adapter hlt logic?
>> > > Emulated MWAIT is very similar to emulated HLT, so reusing the logic
>> > > makes sense.  We would just add new wakeup methods.
>> > > 
>> > > > Either way, with that we should be able to get super low latency IPIs
>> > > > running while still maintaining some sanity on systems which don't have
>> > > > dedicated CPUs for workloads.
>> > > > 
>> > > > And we wouldn't need guest modifications, which is a great plus. So 
>> > > > older
>> > > > guests (and Windows?) could benefit from mwait as well.
>> > > There is no need guest modifications -- it could be exposed as standard
>> > > MWAIT feature to the guest, with responsibilities for guest/host-impact
>> > > on the user.
>> > > 
>> > > I think that the page-fault based MWAIT would require paravirt if it
>> > > should be enabled by default, because of performance concerns:
>> > > Enabling write protection on a page needs a VM exit on all other VCPUs
>> > > when beginning monitoring (to reload page permissions and prevent missed
>> > > writes).
>> > > We'd want to keep trapping writes to the page all the time because
>> > > toggling is slow, but this could regress performance for an OS that has
>> > > other data accessed by other VCPUs in that page.
>> > > No current interface can tell the guest that it should reserve the whole
>> > > page instead of what CPUID[5] says and that writes to the monitored page
>> > > are not "cheap", but can trigger a VM exit ...
>> > CPUID.05H:EBX is supposed to address the false sharing issue. IIRC,
>> > VMware Fusion reports 64 in CPUID.05H:EAX and 4096 in CPUID.05H:EBX
>> > when running Mac OS X guests. Per Intel's SDM volume 3, section
>> > 8.10.5, "To avoid false wake-ups; use the largest monitor line size to
>> > pad the data structure used to monitor writes. Software must make sure
>> > that beyond the data structure, no unrelated data variable exists in
>> > the triggering area for MWAIT. A pad may be needed to avoid this
>> > situation." Unfortunately, most operating systems do not follow this
>> > advice.
>> Right, EBX provides what we need to expose that the whole page is
>> monitored, thanks!
> 
> So coming back to the original patch, is there anything that should keep us
> from exposing MWAIT straight into the guest at all times?

Just minor issues:
 * OS X on Core 2 fails for unknown reason if we disable the instruction
   trapping, which is an argument against doing it by default
 * idling guests would consume host CPU, which is a significant change
   in behavior and shouldn't be done without userspace's involvement

I think the best compromise is to add a capability for the MWAIT VM-exit
controls and let userspace expose MWAIT if it wishes to.
Will send a patch.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/9] convert genericirq.tmpl and kernel-api.tmpl to DocBook

[Mauro Carvalho Chehab]

Em Sun, 2 Apr 2017 14:34:18 -0600
Jonathan Corbet  escreveu:

> On Thu, 30 Mar 2017 17:11:27 -0300
> Mauro Carvalho Chehab  wrote:
> 
> > This series converts just two documents, adding them to the
> > core-api.rst book. It addresses the errors/warnings that popup
> > after the conversion.
> > 
> > I had to add two fixes to scripts/kernel-doc, in order to solve
> > some of the issues.  
> 
> I've applied the set, including the add-on to move some stuff to
> driver-api - thanks.

Thanks!

> For whatever reason, I had a hard time applying a few of these; "git am"
> would tell me this:
> 
> > Applying: docs-rst: core_api: move driver-specific stuff to drivers_api
> > fatal: sha1 information is lacking or useless 
> > (Documentation/driver-api/index.rst).
> > Patch failed at 0001 docs-rst: core_api: move driver-specific stuff to 
> > drivers_api
> > The copy of the patch that failed is found in: .git/rebase-apply/patch  
> 
> I was able to get around this, but it took some hand work.  How are you
> generating these?

That's weird. I'm using this to generate the patches:

git format-patch -o $tmp_dir --stat --summary --patience --signoff 
--thread=shallow

plus some scripting that runs scripts/get_maintainers.

After that, I run:

git send-email $tmp_dir

Then, exim sends the patches to a smart SMTP server (currently,
infradead.org, but I'm switching to s-opensource.org, as I'm getting
some troubles because the IP doesn't match the From: line).

Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6.1 0/4] drm: bridge: dw-hdmi: Add support for Custom PHYs

[Neil Armstrong]

The Amlogic GX SoCs implements a Synopsys DesignWare HDMI TX Controller
in combination with a very custom PHY.

Thanks to Laurent Pinchart's changes, the HW report the following :
 Detected HDMI TX controller v2.01a with HDCP (meson_dw_hdmi_phy)

The following differs from common PHY integration as managed in the current
driver :
 - Amlogic PHY is not configured through the internal I2C link
 - Amlogic PHY do not use the ENTMDS, SVSRET, PDDQ, ... signals from the 
controller
 - Amlogic PHY do not export HPD ands RxSense signals to the controller

And finally, concerning the controller integration :
 - the Controller registers are not flat memory-mapped, and uses an
addr+read/write register pair to write all registers.
 - Inputs only YUV444 pixel data

Most of these uses case are implemented in Laurent Pinchart v5.1 patchset merged
in drm-misc-next branch.

This is why the following patchset implements :
 - Configure the Input format from the plat_data
 - Add PHY callback to handle HPD and RxSense out of the dw-hdmi driver

To implement the input format handling, the Synopsys HDMIT TX Controller input
V4L bus formats are used and missing formats + documentation are added.

This patchset makes the Amlogic GX SoCs HDMI output successfully work, and is
also tested on the RK3288 ACT8846 EVB Board.

Changes since v6 at [8] :
 - Dropped already merged media patches in 
topic/synopsys-media-formats-2017-04-03 tag
 - Reword the patch "Switch to V4L bus format and encodings" commit message
 - Fix typo in patch "Switch to V4L bus format and encodings"
 - Add Laurent Pinchart reviewed/acked-by's
 - Rebased on drm-misc-next at 9c4ad466d1dd

Changes since v5.1 at [7] :
 - Rework of the 48bit tables in V4L bus formats documentation
 - Add Archit reviewed-by's

Changes since v5 at [6] :
 - Small addition in V4L YUV bus formats documentation

Changes since v4 at [5] :
 - Rebased on drm-misc-next at bd283d2f66c2
 - Fix 4:2:0 bus formats naming
 - Renamed function fd_registered to i2c_init in dw-hdmi.c

Changes since v3 at [4] :
 - Fix 4:2:0 bus formats naming
 - Add separate 36bit and 48bit tables for bus formats documentation
 - Added 4:2:0 bus config in hdmi_video_sample
 - Moved dw_hdmi documentation in a "bridge" subdir
 - Rebase on drm-misc-next at 62c58af32c93

Changes since v2 at [3] :
 - Rebase on laurent patch "Extract PHY interrupt setup to a function"
 - Reduce phy operations
 - Switch the V4L bus formats and encodings instead of custom enum

Changes since v1 at [2] :
 - Drop patches submitted by laurent

Changes since RFC at [1] :
 - Regmap fixup for 4bytes register access, tested on RK3288 SoC
 - Move phy callbacks to phy_ops and move Synopsys PHY calls into default ops
 - Move HDMI link data into shared header
 - Move Pixel Encoding enum to shared header

[1] 
http://lkml.kernel.org/r/1484656294-6140-1-git-send-email-narmstr...@baylibre.com
[2] 
http://lkml.kernel.org/r/1485774318-21916-1-git-send-email-narmstr...@baylibre.com
[3] 
http://lkml.kernel.org/r/1488468572-31971-1-git-send-email-narmstr...@baylibre.com
[4] 
http://lkml.kernel.org/r/1488904944-14285-1-git-send-email-narmstr...@baylibre.com
[5] 
http://lkml.kernel.org/r/1490109161-20529-1-git-send-email-narmstr...@baylibre.com
[6] 
http://lkml.kernel.org/r/1490864675-17336-1-git-send-email-narmstr...@baylibre.com
[7] 
http://lkml.kernel.org/r/1490970319-24981-1-git-send-email-narmstr...@baylibre.com
[8] 
http://lkml.kernel.org/r/1491230558-10804-1-git-send-email-narmstr...@baylibre.com

Laurent Pinchart (1):
  drm: bridge: dw-hdmi: Extract PHY interrupt setup to a function

Neil Armstrong (3):
  drm: bridge: dw-hdmi: Switch to V4L bus format and encodings
  drm: bridge: dw-hdmi: Add Documentation on supported input formats
  drm: bridge: dw-hdmi: Move HPD handling to PHY operations

 Documentation/gpu/bridge/dw-hdmi.rst  |  15 +
 Documentation/gpu/index.rst   |   1 +
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 470 --
 include/drm/bridge/dw_hdmi.h  |  68 +
 4 files changed, 398 insertions(+), 156 deletions(-)
 create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst

-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6.1 3/4] drm: bridge: dw-hdmi: Add Documentation on supported input formats

[Neil Armstrong]

This patch adds a new DRM documentation entry and links to the input
format table added in the dw_hdmi header.

Reviewed-by: Archit Taneja 
Acked-by: Laurent Pinchart 
Signed-off-by: Neil Armstrong 
---
 Documentation/gpu/bridge/dw-hdmi.rst | 15 +++
 Documentation/gpu/index.rst  |  1 +
 2 files changed, 16 insertions(+)
 create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst

diff --git a/Documentation/gpu/bridge/dw-hdmi.rst 
b/Documentation/gpu/bridge/dw-hdmi.rst
new file mode 100644
index 000..486faad
--- /dev/null
+++ b/Documentation/gpu/bridge/dw-hdmi.rst
@@ -0,0 +1,15 @@
+===
+ drm/bridge/dw-hdmi Synopsys DesignWare HDMI Controller
+===
+
+Synopsys DesignWare HDMI Controller
+===
+
+This section covers everything related to the Synopsys DesignWare HDMI
+Controller implemented as a DRM bridge.
+
+Supported Input Formats and Encodings
+-
+
+.. kernel-doc:: include/drm/bridge/dw_hdmi.h
+   :doc: Supported input formats and encodings
diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
index e998ee0..d81c6ff 100644
--- a/Documentation/gpu/index.rst
+++ b/Documentation/gpu/index.rst
@@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide
vc4
vga-switcheroo
vgaarbiter
+   bridge/dw-hdmi
todo
 
 .. only::  subproject and html
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v6.1 4/4] drm: bridge: dw-hdmi: Move HPD handling to PHY operations

[Neil Armstrong]

The HDMI TX controller support HPD and RXSENSE signaling from the PHY
via it's STAT0 PHY interface, but some vendor PHYs can manage these
signals independently from the controller, thus these STAT0 handling
should be moved to PHY specific operations and become optional.

The existing STAT0 HPD and RXSENSE handling code is refactored into
a supplementaty set of default PHY operations that are used automatically
when the platform glue doesn't provide its own operations.

Reviewed-by: Jose Abreu 
Reviewed-by: Archit Taneja 
Reviewed-by: Laurent Pinchart 
Signed-off-by: Neil Armstrong 
---
 drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 135 ++
 include/drm/bridge/dw_hdmi.h  |   5 ++
 2 files changed, 86 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 16d5fff3..84cc949 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1229,10 +1229,46 @@ static enum drm_connector_status 
dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
connector_status_connected : connector_status_disconnected;
 }
 
+static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+  bool force, bool disabled, bool rxsense)
+{
+   u8 old_mask = hdmi->phy_mask;
+
+   if (force || disabled || !rxsense)
+   hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
+   else
+   hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
+
+   if (old_mask != hdmi->phy_mask)
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+}
+
+static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+{
+   /*
+* Configure the PHY RX SENSE and HPD interrupts polarities and clear
+* any pending interrupt.
+*/
+   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+
+   /* Enable cable hot plug irq. */
+   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
+
+   /* Clear and unmute interrupts. */
+   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
+   HDMI_IH_PHY_STAT0);
+   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
+   HDMI_IH_MUTE_PHY_STAT0);
+}
+
 static const struct dw_hdmi_phy_ops dw_hdmi_synopsys_phy_ops = {
.init = dw_hdmi_phy_init,
.disable = dw_hdmi_phy_disable,
.read_hpd = dw_hdmi_phy_read_hpd,
+   .update_hpd = dw_hdmi_phy_update_hpd,
+   .setup_hpd = dw_hdmi_phy_setup_hpd,
 };
 
 /* 
-
@@ -1808,35 +1844,10 @@ static void dw_hdmi_update_power(struct dw_hdmi *hdmi)
  */
 static void dw_hdmi_update_phy_mask(struct dw_hdmi *hdmi)
 {
-   u8 old_mask = hdmi->phy_mask;
-
-   if (hdmi->force || hdmi->disabled || !hdmi->rxsense)
-   hdmi->phy_mask |= HDMI_PHY_RX_SENSE;
-   else
-   hdmi->phy_mask &= ~HDMI_PHY_RX_SENSE;
-
-   if (old_mask != hdmi->phy_mask)
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-}
-
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi)
-{
-   /*
-* Configure the PHY RX SENSE and HPD interrupts polarities and clear
-* any pending interrupt.
-*/
-   hdmi_writeb(hdmi, HDMI_PHY_HPD | HDMI_PHY_RX_SENSE, HDMI_PHY_POL0);
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-
-   /* Enable cable hot plug irq. */
-   hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
-
-   /* Clear and unmute interrupts. */
-   hdmi_writeb(hdmi, HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE,
-   HDMI_IH_PHY_STAT0);
-   hdmi_writeb(hdmi, ~(HDMI_IH_PHY_STAT0_HPD | HDMI_IH_PHY_STAT0_RX_SENSE),
-   HDMI_IH_MUTE_PHY_STAT0);
+   if (hdmi->phy.ops->update_hpd)
+   hdmi->phy.ops->update_hpd(hdmi, hdmi->phy.data,
+ hdmi->force, hdmi->disabled,
+ hdmi->rxsense);
 }
 
 static enum drm_connector_status
@@ -2028,6 +2039,41 @@ static irqreturn_t dw_hdmi_hardirq(int irq, void *dev_id)
return ret;
 }
 
+void __dw_hdmi_setup_rx_sense(struct dw_hdmi *hdmi, bool hpd, bool rx_sense)
+{
+   mutex_lock(>mutex);
+
+   if (!hdmi->force) {
+   /*
+* If the RX sense status indicates we're disconnected,
+* clear the software rxsense status.
+*/
+   if (!rx_sense)
+   hdmi->rxsense = false;
+
+   /*
+* Only set the software 

[PATCH v2 18/37] docs: input/joystick-api: convert it to ReST format

[Mauro Carvalho Chehab]

This file require some adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/joystick-api.txt | 138 +++
 1 file changed, 75 insertions(+), 63 deletions(-)

diff --git a/Documentation/input/joystick-api.txt 
b/Documentation/input/joystick-api.txt
index 943b18eac918..9b9d26833086 100644
--- a/Documentation/input/joystick-api.txt
+++ b/Documentation/input/joystick-api.txt
@@ -1,12 +1,11 @@
- Joystick API Documentation-*-Text-*-
+==
+Joystick API Documentation
+==
 
-   Ragnar Hojland Espinosa
- 
+:Author: Ragnar Hojland Espinosa  - 7 Aug 1998
 
- 7 Aug 1998
-
-1. Initialization
-~
+Initialization
+==
 
 Open the joystick device following the usual semantics (that is, with open).
 Since the driver now reports events instead of polling for changes,
@@ -14,18 +13,20 @@ immediately after the open it will issue a series of 
synthetic events
 (JS_EVENT_INIT) that you can read to check the initial state of the
 joystick.
 
-By default, the device is opened in blocking mode.
+By default, the device is opened in blocking mode::
 
int fd = open ("/dev/input/js0", O_RDONLY);
 
 
-2. Event Reading
-
+Event Reading
+=
+
+::
 
struct js_event e;
read (fd, , sizeof(e));
 
-where js_event is defined as
+where js_event is defined as::
 
struct js_event {
__u32 time; /* event timestamp in milliseconds */
@@ -38,10 +39,10 @@ If the read is successful, it will return sizeof(e), unless 
you wanted to read
 more than one event per read as described in section 3.1.
 
 
-2.1 js_event.type
-~
+js_event.type
+-
 
-The possible values of ``type'' are
+The possible values of ``type`` are::
 
#define JS_EVENT_BUTTON 0x01/* button pressed/released */
#define JS_EVENT_AXIS   0x02/* joystick moved */
@@ -49,47 +50,50 @@ The possible values of ``type'' are
 
 As mentioned above, the driver will issue synthetic JS_EVENT_INIT ORed
 events on open. That is, if it's issuing a INIT BUTTON event, the
-current type value will be
+current type value will be::
 
int type = JS_EVENT_BUTTON | JS_EVENT_INIT; /* 0x81 */
 
 If you choose not to differentiate between synthetic or real events
-you can turn off the JS_EVENT_INIT bits
+you can turn off the JS_EVENT_INIT bits::
 
type &= ~JS_EVENT_INIT; /* 0x01 */
 
 
-2.2 js_event.number
-~~~
+js_event.number
+---
 
-The values of ``number'' correspond to the axis or button that
+The values of ``number`` correspond to the axis or button that
 generated the event. Note that they carry separate numeration (that
 is, you have both an axis 0 and a button 0). Generally,
 
-   number
+=== ===
+   Axisnumber
+=== ===
1st Axis X  0
1st Axis Y  1
2nd Axis X  2
2nd Axis Y  3
...and so on
+=== ===
 
 Hats vary from one joystick type to another. Some can be moved in 8
 directions, some only in 4, The driver, however, always reports a hat as two
 independent axis, even if the hardware doesn't allow independent movement.
 
 
-2.3 js_event.value
-~~
+js_event.value
+--
 
-For an axis, ``value'' is a signed integer between -32767 and +32767
+For an axis, ``value`` is a signed integer between -32767 and +32767
 representing the position of the joystick along that axis. If you
-don't read a 0 when the joystick is `dead', or if it doesn't span the
+don't read a 0 when the joystick is ``dead``, or if it doesn't span the
 full range, you should recalibrate it (with, for example, jscal).
 
-For a button, ``value'' for a press button event is 1 and for a release
+For a button, ``value`` for a press button event is 1 and for a release
 button event is 0.
 
-Though this
+Though this::
 
if (js_event.type == JS_EVENT_BUTTON) {
buttons_state ^= (1 << js_event.number);
@@ -97,6 +101,8 @@ Though this
 
 may work well if you handle JS_EVENT_INIT events separately,
 
+::
+
if ((js_event.type & ~JS_EVENT_INIT) == JS_EVENT_BUTTON) {
if (js_event.value)
buttons_state |= (1 << js_event.number);
@@ -109,17 +115,17 @@ have to write a separate handler for JS_EVENT_INIT events 
in the first
 snippet, this ends up being shorter.
 
 
-2.4 js_event.time
-~
+js_event.time
+-
 
-The time an event was generated is stored in ``js_event.time''. It's a time
+The time an event was 

[PATCH v2 31/37] docs: input/shape: convert it from xfig to svg

[Mauro Carvalho Chehab]

We're using svg as the standard format for vectorial images.

Convert it to .svg, in a way that it is easily editable.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/shape.fig | 65 ---
 Documentation/input/shape.svg | 39 ++
 2 files changed, 39 insertions(+), 65 deletions(-)
 delete mode 100644 Documentation/input/shape.fig
 create mode 100644 Documentation/input/shape.svg

diff --git a/Documentation/input/shape.fig b/Documentation/input/shape.fig
deleted file mode 100644
index c22bff83d06f..
--- a/Documentation/input/shape.fig
+++ /dev/null
@@ -1,65 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
--2
-1200 2
-2 1 0 2 0 7 50 0 -1 0.000 0 0 -1 0 0 6
-4200 3600 4200 3075 4950 2325 7425 2325 8250 3150 8250 3600
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-4200 3675 4200 5400
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-8250 3675 8250 5400
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-3675 3600 8700 3600
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-8775 3600 10200 3600
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-8325 3150 9075 3150
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-7500 2325 10200 2325
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-3600 3600 3000 3600
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-4125 3075 3000 3075
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
-   0 0 1.00 60.00 120.00
-   0 0 1.00 60.00 120.00
-4200 5400 8175 5400
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
-   0 0 1.00 60.00 120.00
-   0 0 1.00 60.00 120.00
-10125 2325 10125 3600
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
-   0 0 1.00 60.00 120.00
-   0 0 1.00 60.00 120.00
-3000 3150 3000 3600
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
-   0 0 1.00 60.00 120.00
-   0 0 1.00 60.00 120.00
-9075 3150 9075 3600
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-4950 2325 4950 1200
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-7425 2325 7425 1200
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 4
-4200 3075 4200 2400 3600 1800 3600 1200
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 4
-8250 3150 8250 2475 8775 1950 8775 1200
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
-   0 0 1.00 60.00 120.00
-   0 0 1.00 60.00 120.00
-3600 1275 4950 1275
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
-   0 0 1.00 60.00 120.00
-   0 0 1.00 60.00 120.00
-7425 1275 8700 1275
-4 1 0 50 0 0 12 0. 4 135 1140 6075 5325 Effect duration\001
-4 0 0 50 0 0 12 0. 4 180 1305 10200 3000 Effect magnitude\001
-4 0 0 50 0 0 12 0. 4 135 780 9150 3450 Fade level\001
-4 1 0 50 0 0 12 0. 4 180 1035 4275 1200 Attack length\001
-4 1 0 50 0 0 12 0. 4 180 885 8175 1200 Fade length\001
-4 2 0 50 0 0 12 0. 4 135 930 2925 3375 Attack level\001
diff --git a/Documentation/input/shape.svg b/Documentation/input/shape.svg
new file mode 100644
index ..fc0af44db3f7
--- /dev/null
+++ b/Documentation/input/shape.svg
@@ -0,0 +1,39 @@
+http://www.w3.org/2000/svg;>
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ Effect duration
+ Effect 
magnitude
+ Fade level
+ Attack length
+ Fade length
+ Attack level
+
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 16/37] docs: input/iforce-protocol: convert it to ReST format

[Mauro Carvalho Chehab]

This file seems to be using some other markup language,
(maybe mediawiki?). Manually convert it to ReST markup,
with is the one we're using along the Kernel documentaiton.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/iforce-protocol.txt | 495 
 1 file changed, 309 insertions(+), 186 deletions(-)

diff --git a/Documentation/input/iforce-protocol.txt 
b/Documentation/input/iforce-protocol.txt
index 66287151c54a..8634beac3fdb 100644
--- a/Documentation/input/iforce-protocol.txt
+++ b/Documentation/input/iforce-protocol.txt
@@ -1,4 +1,17 @@
-** Introduction
+===
+Iforce Protocol
+===
+
+:Author: Johann Deneux 
+
+Home page at ``_
+
+:Additions: by Vojtech Pavlik.
+
+
+Introduction
+
+
 This document describes what I managed to discover about the protocol used to
 specify force effects to I-Force 2.0 devices.  None of this information comes
 from Immerse. That's why you should not trust what is written in this
@@ -6,238 +19,350 @@ document. This document is intended to help understanding 
the protocol.
 This is not a reference. Comments and corrections are welcome.  To contact me,
 send an email to: johann.den...@gmail.com
 
-** WARNING **
-I shall not be held responsible for any damage or harm caused if you try to
-send data to your I-Force device based on what you read in this document.
+.. warning::
+
+I shall not be held responsible for any damage or harm caused if you try to
+send data to your I-Force device based on what you read in this document.
+
+Preliminary Notes
+=
 
-** Preliminary Notes:
 All values are hexadecimal with big-endian encoding (msb on the left). Beware,
 values inside packets are encoded using little-endian.  Bytes whose roles are
 unknown are marked ???  Information that needs deeper inspection is marked (?)
 
-** General form of a packet **
+General form of a packet
+
+
 This is how packets look when the device uses the rs232 to communicate.
+
+== == ===  ==
 2B OP LEN DATA CS
+== == ===  ==
+
 CS is the checksum. It is equal to the exclusive or of all bytes.
 
 When using USB:
+
+== 
 OP DATA
-The 2B, LEN and CS fields have disappeared, probably because USB handles 
frames and
-data corruption is handled or unsignificant.
+== 
+
+The 2B, LEN and CS fields have disappeared, probably because USB handles
+frames and data corruption is handled or unsignificant.
 
 First, I describe effects that are sent by the device to the computer
 
-** Device input state
+Device input state
+==
+
 This packet is used to indicate the state of each button and the value of each
-axis
-OP= 01 for a joystick, 03 for a wheel
-LEN= Varies from device to device
-00 X-Axis lsb
-01 X-Axis msb
-02 Y-Axis lsb, or gas pedal for a wheel
-03 Y-Axis msb, or brake pedal for a wheel
-04 Throttle
-05 Buttons
-06 Lower 4 bits: Buttons
-   Upper 4 bits: Hat
-07 Rudder
-
-** Device effects states
-OP= 02
-LEN= Varies
-00 ? Bit 1 (Value 2) is the value of the deadman switch
-01 Bit 8 is set if the effect is playing. Bits 0 to 7 are the effect id.
-02 ??
-03 Address of parameter block changed (lsb)
-04 Address of parameter block changed (msb)
-05 Address of second parameter block changed (lsb)
-... depending on the number of parameter blocks updated
-
-** Force effect **
-OP=  01
-LEN= 0e
-00 Channel (when playing several effects at the same time, each must be 
assigned a channel)
-01 Wave form
-   Val 00 Constant
-   Val 20 Square
-   Val 21 Triangle
-   Val 22 Sine
-   Val 23 Sawtooth up
-   Val 24 Sawtooth down
-   Val 40 Spring (Force = f(pos))
-   Val 41 Friction (Force = f(velocity)) and Inertia (Force = 
f(acceleration))
-
-
-02 Axes affected and trigger
-   Bits 4-7: Val 2 = effect along one axis. Byte 05 indicates direction
- Val 4 = X axis only. Byte 05 must contain 5a
- Val 8 = Y axis only. Byte 05 must contain b4
- Val c = X and Y axes. Bytes 05 must contain 60
-   Bits 0-3: Val 0 = No trigger
- Val x+1 = Button x triggers the effect
-   When the whole byte is 0, cancel the previously set trigger
-
-03-04 Duration of effect (little endian encoding, in ms)
-
-05 Direction of effect, if applicable. Else, see 02 for value to assign.
-
-06-07 Minimum time between triggering.
-
-08-09 Address of periodicity or magnitude parameters
-0a-0b Address of attack and fade parameters, or  if none.
-*or*
-08-09 Address of interactive parameters for X-axis, or  if not applicable
-0a-0b Address of interactive parameters for Y-axis, or  if not applicable
-
-0c-0d Delay before execution of effect (little endian encoding, in ms)
-
-
-** Time based parameters **
-
-*** Attack and fade ***
-OP=  02
-LEN= 08
-00-01 Address where to store the 

[PATCH v2 13/37] docs: input/gamepad: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/gamepad.txt | 43 +
 1 file changed, 31 insertions(+), 12 deletions(-)

diff --git a/Documentation/input/gamepad.txt b/Documentation/input/gamepad.txt
index 3f6d8a5e9cdc..8bc7fdea3705 100644
--- a/Documentation/input/gamepad.txt
+++ b/Documentation/input/gamepad.txt
@@ -1,5 +1,9 @@
-Linux Gamepad API
-
+-
+Linux Gamepad API
+-
+
+:Author: 2013 by David Herrmann 
+
 
 1. Intro
 
@@ -9,7 +13,7 @@ document defines how gamepads are supposed to report their 
data.
 
 2. Geometry
 ~~~
-As "gamepad" we define devices which roughly look like this:
+As "gamepad" we define devices which roughly look like this::
 
   __
/ [__ZL__]  [__ZR__] \   |
@@ -35,6 +39,7 @@ As "gamepad" we define devices which roughly look like this:
   Menu Pad
 
 Most gamepads have the following features:
+
   - Action-Pad
 4 buttons in diamonds-shape (on the right side). The buttons are
 differently labeled on most devices so we define them as NORTH,
@@ -60,6 +65,7 @@ Most gamepads have the following features:
 
 3. Detection
 
+
 All gamepads that follow the protocol described here map BTN_GAMEPAD. This is
 an alias for BTN_SOUTH/BTN_A. It can be used to identify a gamepad as such.
 However, not all gamepads provide all features, so you need to test for all
@@ -87,6 +93,7 @@ events.
 
 4. Events
 ~
+
 Gamepads report the following events:
 
 Action-Pad:
@@ -94,8 +101,10 @@ Action-Pad:
   device reports BTN_SOUTH (which BTN_GAMEPAD is an alias for). Regardless
   of the labels on the buttons, the codes are sent according to the
   physical position of the buttons.
+
   Please note that 2- and 3-button pads are fairly rare and old. You might
   want to filter gamepads that do not report all four.
+
 2-Button Pad:
   If only 2 action-buttons are present, they are reported as BTN_SOUTH and
   BTN_EAST. For vertical layouts, the upper button is BTN_EAST. For
@@ -118,42 +127,52 @@ D-Pad:
   may even report both. The kernel does not convert between these so
   applications should support both and choose what is more appropriate if
   both are reported.
+
 Digital buttons are reported as:
+
   BTN_DPAD_*
+
 Analog buttons are reported as:
+
   ABS_HAT0X and ABS_HAT0Y
-  (for ABS values negative is left/up, positive is right/down)
+
+  (for ABS values negative is left/up, positive is right/down)
 
 Analog-Sticks:
   The left analog-stick is reported as ABS_X, ABS_Y. The right analog stick is
   reported as ABS_RX, ABS_RY. Zero, one or two sticks may be present.
   If analog-sticks provide digital buttons, they are mapped accordingly as
   BTN_THUMBL (first/left) and BTN_THUMBR (second/right).
-(for ABS values negative is left/up, positive is right/down)
+
+  (for ABS values negative is left/up, positive is right/down)
 
 Triggers:
   Trigger buttons can be available as digital or analog buttons or both. User-
   space must correctly deal with any situation and choose the most appropriate
   mode.
+
   Upper trigger buttons are reported as BTN_TR or ABS_HAT1X (right) and BTN_TL
   or ABS_HAT1Y (left). Lower trigger buttons are reported as BTN_TR2 or
   ABS_HAT2X (right/ZR) and BTN_TL2 or ABS_HAT2Y (left/ZL).
+
   If only one trigger-button combination is present (upper+lower), they are
   reported as "right" triggers (BTN_TR/ABS_HAT1X).
-(ABS trigger values start at 0, pressure is reported as positive values)
+
+  (ABS trigger values start at 0, pressure is reported as positive values)
 
 Menu-Pad:
   Menu buttons are always digital and are mapped according to their location
   instead of their labels. That is:
-1-button Pad: Mapped as BTN_START
-2-button Pad: Left button mapped as BTN_SELECT, right button mapped as
-  BTN_START
+
+1-button Pad:
+   Mapped as BTN_START
+
+2-button Pad:
+   Left button mapped as BTN_SELECT, right button mapped as BTN_START
+
   Many pads also have a third button which is branded or has a special symbol
   and meaning. Such buttons are mapped as BTN_MODE. Examples are the Nintendo
   "HOME" button, the XBox "X"-button or Sony "PS" button.
 
 Rumble:
   Rumble is advertised as FF_RUMBLE.
-
-
-  Written 2013 by David Herrmann 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

[PATCH v2 33/37] docs: ff.rst: use svg files instead of xfig

[Mauro Carvalho Chehab]

Now that the images got converted to svg, add them at the
ff.rst file.

NOTE: After merging upstream, the "figure" tag should be
replaced by the new "kernel-figure" tag, in order for the
SVG images to be included at the PDF files.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/ff.rst | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/Documentation/input/ff.rst b/Documentation/input/ff.rst
index 6d6688a63dd8..c30f185216a0 100644
--- a/Documentation/input/ff.rst
+++ b/Documentation/input/ff.rst
@@ -5,8 +5,8 @@ Force feedback for Linux
 :Author: Johann Deneux  on 2001/04/22.
 :Updated: Anssi Hannula  on 2006/04/09.
 
-You may redistribute this file. Please remember to include shape.fig and
-interactive.fig as well.
+You may redistribute this file. Please remember to include shape.svg and
+interactive.svg as well.
 
 Introduction
 
@@ -127,8 +127,15 @@ allocate a new effect.
 Effects are file descriptor specific.
 
 See  for a description of the ff_effect struct. You should also
-find help in a few sketches, contained in files shape.fig and interactive.fig.
-You need xfig to visualize these files.
+find help in a few sketches, contained in files shape.svg and interactive.svg:
+
+.. figure:: shape.svg
+
+Shape
+
+.. figure:: interactive.svg
+
+Interactive
 
 
 Removing an effect from the device
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 14/37] docs: input/gameport-programming: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST.

Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/gameport-programming.txt | 83 
 1 file changed, 59 insertions(+), 24 deletions(-)

diff --git a/Documentation/input/gameport-programming.txt 
b/Documentation/input/gameport-programming.txt
index 03a74fc3b496..c96911df1c54 100644
--- a/Documentation/input/gameport-programming.txt
+++ b/Documentation/input/gameport-programming.txt
@@ -1,11 +1,12 @@
+
 Programming gameport drivers
 
 
-1. A basic classic gameport
-~~~
+A basic classic gameport
+
 
 If the gameport doesn't provide more than the inb()/outb() functionality,
-the code needed to register it with the joystick drivers is simple:
+the code needed to register it with the joystick drivers is simple::
 
struct gameport gameport;
 
@@ -37,12 +38,12 @@ space only when something really is using it. Disable it 
again in the
 callback, so that it doesn't fail if some of the possible addresses are
 already occupied by other gameports.
 
-2. Memory mapped gameport
-~
+Memory mapped gameport
+~~
 
 When a gameport can be accessed through MMIO, this way is preferred, because
 it is faster, allowing more reads per second. Registering such a gameport
-isn't as easy as a basic IO one, but not so much complex:
+isn't as easy as a basic IO one, but not so much complex::
 
struct gameport gameport;
 
@@ -53,19 +54,21 @@ isn't as easy as a basic IO one, but not so much complex:
 
unsigned char my_read(struct gameport *gameport)
{
-   return my_mmio; 
+   return my_mmio;
}
 
gameport.read = my_read;
gameport.trigger = my_trigger;
gameport_register_port();
 
-3. Cooked mode gameport
-~~~
+.. _gameport_pgm_cooked_mode:
+
+Cooked mode gameport
+
 
 There are gameports that can report the axis values as numbers, that means
 the driver doesn't have to measure them the old way - an ADC is built into
-the gameport. To register a cooked gameport:
+the gameport. To register a cooked gameport::
 
struct gameport gameport;
 
@@ -95,8 +98,8 @@ See analog.c and input.c for handling of fuzz - the fuzz 
value determines
 the size of a gaussian filter window that is used to eliminate the noise
 in the data.
 
-4. More complex gameports
-~
+More complex gameports
+~~
 
 Gameports can support both raw and cooked modes. In that case combine either
 examples 1+2 or 1+3. Gameports can support internal calibration - see below,
@@ -104,65 +107,91 @@ and also lightning.c and analog.c on how that works. If 
your driver supports
 more than one gameport instance simultaneously, use the ->private member of
 the gameport struct to point to your data.
 
-5. Unregistering a gameport
-~~~
+Unregistering a gameport
+
 
-Simple:
+Simple::
 
-gameport_unregister_port();
+gameport_unregister_port();
 
-6. The gameport structure
-~
+The gameport structure
+~~
 
-struct gameport {
+.. note::
+
+This section is outdated. There are several fields here that don't
+match what's there at include/linux/gameport.h.
+
+::
+
+struct gameport {
 
void *private;
 
 A private pointer for free use in the gameport driver. (Not the joystick
 driver!)
 
+::
+
int number;
 
 Number assigned to the gameport when registered. Informational purpose only.
 
+::
+
int io;
 
 I/O address for use with raw mode. You have to either set this, or ->read()
 to some value if your gameport supports raw mode.
 
+::
+
int speed;
 
 Raw mode speed of the gameport reads in thousands of reads per second.
 
+::
+
int fuzz;
 
 If the gameport supports cooked mode, this should be set to a value that
-represents the amount of noise in the data. See section 3.
+represents the amount of noise in the data. See
+:ref:`gameport_pgm_cooked_mode`.
+
+::
 
void (*trigger)(struct gameport *);
 
 Trigger. This function should trigger the ns558 oneshots. If set to NULL,
 outb(0xff, io) will be used.
 
+::
+
unsigned char (*read)(struct gameport *);
 
 Read the buttons and ns558 oneshot bits. If set to NULL, inb(io) will be
 used instead.
 
-   int (*cooked_read)(struct gameport *, int *axes, int *buttons); 
+::
+
+   int (*cooked_read)(struct gameport *, int *axes, int *buttons);
 
 If the gameport supports cooked mode, it should point this to its cooked
 read function. It should fill axes[0..3] with four values of the joystick axes
 and buttons[0] with four bits representing the buttons.
 
-   int (*calibrate)(struct gameport *, int 

[PATCH v2 05/37] docs: input/atarikbd: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

We opted to remove section numbers, as this can be automatically
generated on Sphinx, by using :numbered: tag at index.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/atarikbd.txt | 214 +--
 1 file changed, 161 insertions(+), 53 deletions(-)

diff --git a/Documentation/input/atarikbd.txt b/Documentation/input/atarikbd.txt
index f3a3ba8847ba..032c065a031a 100644
--- a/Documentation/input/atarikbd.txt
+++ b/Documentation/input/atarikbd.txt
@@ -1,7 +1,10 @@
+
 Intelligent Keyboard (ikbd) Protocol
+
 
 
-1. Introduction
+Introduction
+
 
 The Atari Corp. Intelligent Keyboard (ikbd) is a general purpose keyboard
 controller that is flexible enough that it can be used in a variety of
@@ -18,7 +21,8 @@ different applications of the keyboard,  joysticks, or mouse. 
Limited use of
 the controller is possible in applications in which only a unidirectional
 communications medium is available by carefully designing the default modes.
 
-3. Keyboard
+Keyboard
+
 
 The keyboard always returns key make/break scan codes. The ikbd generates
 keyboard scan codes for each key press and release. The key scan make (key
@@ -28,19 +32,23 @@ exists in that position on a particular keyboard. The break 
code for each key
 is obtained by ORing 0x80 with the make code.
 
 The special codes 0xF6 through 0xFF are reserved for use as follows:
+
+=== 
 0xF6status report
 0xF7absolute mouse position record
 0xF8-0xFB   relative mouse position records (lsbs determined by
- mouse button states)
+mouse button states)
 0xFCtime-of-day
 0xFDjoystick report (both sticks)
 0xFEjoystick 0 event
 0xFFjoystick 1 event
+=== 
 
 The two shift keys return different scan codes in this mode. The ENTER key
 and the RETurn key are also distinct.
 
-4. Mouse
+Mouse
+=
 
 The mouse port should be capable of supporting a mouse with resolution of
 approximately 200 counts (phase changes or 'clicks') per inch of travel. The
@@ -53,7 +61,8 @@ key equivalents.
 The mouse buttons can be treated as part of the mouse or as additional
 keyboard keys.
 
-4.1 Relative Position Reporting
+Relative Position Reporting
+---
 
 In relative position mode, the ikbd will return relative mouse position
 records whenever a mouse event occurs. A mouse event consists of a mouse
@@ -67,7 +76,8 @@ been 'paused' ( the event will be stored until keyboard 
communications is
 resumed) (b) while any event is being transmitted.
 
 The relative mouse position record is a three byte record of the form
-(regardless of keyboard mode):
+(regardless of keyboard mode)::
+
 %10xy   ; mouse position record flag
 ; where y is the right button state
 ; and x is the left button state
@@ -81,13 +91,15 @@ If the accumulated motion before the report packet is 
generated exceeds the
 Note that the sign of the delta y reported is a function of the Y origin
 selected.
 
-4.2 Absolute Position reporting
+Absolute Position reporting
+---
 
 The ikbd can also maintain absolute mouse position. Commands exist for
 resetting the mouse position, setting X/Y scaling, and interrogating the
 current mouse position.
 
-4.3 Mouse Cursor Key Mode
+Mouse Cursor Key Mode
+-
 
 The ikbd can translate mouse motion into the equivalent cursor keystrokes.
 The number of mouse clicks per keystroke is independently programmable in
@@ -99,32 +111,38 @@ break code for the appropriate cursor key. The mouse 
buttons produce scan
 codes above those normally assigned for the largest envisioned keyboard (i.e.
 LEFT=0x74 & RIGHT=0x75).
 
-5. Joystick
+Joystick
+
 
-5.1 Joystick Event Reporting
+Joystick Event Reporting
+
 
 In this mode, the ikbd generates a record whenever the joystick position is
 changed (i.e. for each opening or closing of a joystick switch or trigger).
 
-The joystick event record is two bytes of the form:
+The joystick event record is two bytes of the form::
+
 %111x   ; Joystick event marker
 ; where x is Joystick 0 or 1
 %x000   ; where  is the stick position
 ; and x is the trigger
 
-5.2 Joystick Interrogation
+Joystick Interrogation
+--
 
 The current state of the joystick ports may be interrogated at any time in
 this mode by sending an 'Interrogate Joystick' command to the ikbd.
 

[PATCH v2 22/37] docs: input/notifier: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/notifier.txt | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/input/notifier.txt b/Documentation/input/notifier.txt
index 95172ca6f3d2..161350cb865e 100644
--- a/Documentation/input/notifier.txt
+++ b/Documentation/input/notifier.txt
@@ -1,4 +1,6 @@
+=
 Keyboard notifier
+=
 
 One can use register_keyboard_notifier to get called back on keyboard
 events (see kbd_keycode() function for details).  The passed structure is
@@ -23,9 +25,9 @@ For each kind of event but the last, the callback may return 
NOTIFY_STOP in
 order to "eat" the event: the notify loop is stopped and the keyboard event is
 dropped.
 
-In a rough C snippet, we have:
+In a rough C snippet, we have::
 
-kbd_keycode(keycode) {
+kbd_keycode(keycode) {
...
params.value = keycode;
if (notifier_call_chain(KBD_KEYCODE,) == NOTIFY_STOP)
@@ -47,6 +49,6 @@ kbd_keycode(keycode) {
return;
apply keysym;
notifier_call_chain(KBD_POST_KEYSYM,);
-}
+}
 
-NOTE: This notifier is usually called from interrupt context.
+.. note:: This notifier is usually called from interrupt context.
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 37/37] hid-logitech-hidpp: add support for ratchet switch

[Mauro Carvalho Chehab]

Logitech Anywhere MX2 and MX master produce events for
the wheel ratchet/free wheel button. Add support for it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/hid/hid-logitech-hidpp.c | 23 +--
 1 file changed, 21 insertions(+), 2 deletions(-)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index c208a5107511..6177087ffaca 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -1406,6 +1406,19 @@ static int hidpp_mouse_set_wheel_mode(struct 
hidpp_device *hidpp,
return ret;
}
 
+   ret = hidpp_send_fap_command_sync(hidpp, hrd->feature_index,
+ CMD_MOUSE_GET_WHEEL_RATCHET,
+ params, 16, );
+   if (ret > 0) {
+   hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+   __func__, ret);
+   return -EPROTO;
+   }
+   if (ret)
+   return ret;
+
+   hrd->ratchet = response.fap.params[0] & 0x01;
+
params[0] = invert ? 0x4 : 0  |
high_res   ? 0x2 : 0  |
hidpp_mode ? 0x1 : 0;
@@ -1945,10 +1958,11 @@ static int high_res_raw_event(struct hid_device *hdev, 
u8 *data, int size)
input_report_rel(hrd->input, REL_HIRES_WHEEL, delta);
else
input_report_rel(hrd->input, REL_WHEEL, delta);
+   } else if (data[3] == 0x10) {
+   hrd->ratchet = data[4] & 0x01;
+   input_report_switch(hrd->input, SW_RATCHET, hrd->ratchet);
}
 
-   /* FIXME: also report ratchet events to userspace */
-
return 1;
 }
 
@@ -1961,6 +1975,11 @@ static void high_res_populate_input(struct hidpp_device 
*hidpp,
 
__set_bit(REL_WHEEL, hrd->input->relbit);
__set_bit(REL_HIRES_WHEEL, hrd->input->relbit);
+   __set_bit(EV_SW, hrd->input->evbit);
+   __set_bit(SW_RATCHET, hrd->input->swbit);
+
+   /* Report current state of the ratchet switch */
+   input_report_switch(hrd->input, SW_RATCHET, hrd->ratchet);
 }
 
 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 12/37] docs: input/ff: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/ff.txt | 188 +++--
 1 file changed, 112 insertions(+), 76 deletions(-)

diff --git a/Documentation/input/ff.txt b/Documentation/input/ff.txt
index b3867bf49f8f..6d6688a63dd8 100644
--- a/Documentation/input/ff.txt
+++ b/Documentation/input/ff.txt
@@ -1,12 +1,16 @@
-Force feedback for Linux.
-By Johann Deneux  on 2001/04/22.
-Updated by Anssi Hannula  on 2006/04/09.
+
+Force feedback for Linux
+
+
+:Author: Johann Deneux  on 2001/04/22.
+:Updated: Anssi Hannula  on 2006/04/09.
+
 You may redistribute this file. Please remember to include shape.fig and
 interactive.fig as well.
-
 
-1. Introduction
-~~~
+Introduction
+
+
 This document describes how to use force feedback devices under Linux. The
 goal is not to support these devices as if they were simple input-only devices
 (as it is already the case), but to really enable the rendering of force
@@ -15,8 +19,9 @@ This document only describes the force feedback part of the 
Linux input
 interface. Please read joystick.txt and input.txt before reading further this
 document.
 
-2. Instructions to the user
-~~~
+Instructions to the user
+
+
 To enable force feedback, you have to:
 
 1. have your kernel configured with evdev and a driver that supports your
@@ -33,39 +38,48 @@ something goes wrong.
 If you have a serial iforce device, you need to start inputattach. See
 joystick.txt for details.
 
-2.1 Does it work ?
-~~
-There is an utility called fftest that will allow you to test the driver.
-% fftest /dev/input/eventXX
+Does it work ?
+--
+
+There is an utility called fftest that will allow you to test the driver::
+
+% fftest /dev/input/eventXX
+
+Instructions to the developer
+~
 
-3. Instructions to the developer
-~
 All interactions are done using the event API. That is, you can use ioctl()
 and write() on /dev/input/eventXX.
 This information is subject to change.
 
-3.1 Querying device capabilities
-
-#include 
-#include 
+Querying device capabilities
+
 
-#define BITS_TO_LONGS(x) \
-   (((x) + 8 * sizeof (unsigned long) - 1) / (8 * sizeof (unsigned long)))
-unsigned long features[BITS_TO_LONGS(FF_CNT)];
-int ioctl(int file_descriptor, int request, unsigned long *features);
+::
+
+#include 
+#include 
+
+#define BITS_TO_LONGS(x) \
+   (((x) + 8 * sizeof (unsigned long) - 1) / (8 * sizeof (unsigned 
long)))
+unsigned long features[BITS_TO_LONGS(FF_CNT)];
+int ioctl(int file_descriptor, int request, unsigned long *features);
 
 "request" must be EVIOCGBIT(EV_FF, size of features array in bytes )
 
 Returns the features supported by the device. features is a bitfield with the
 following bits:
+
 - FF_CONSTANT  can render constant force effects
 - FF_PERIODIC  can render periodic effects with the following waveforms:
+
   - FF_SQUAREsquare waveform
   - FF_TRIANGLE  triangle waveform
   - FF_SINE  sine waveform
   - FF_SAW_UPsawtooth up waveform
   - FF_SAW_DOWN  sawtooth down waveform
   - FF_CUSTOMcustom waveform
+
 - FF_RAMP   can render ramp effects
 - FF_SPRINGcan simulate the presence of a spring
 - FF_FRICTION  can simulate friction
@@ -75,24 +89,30 @@ following bits:
 - FF_GAIN  gain is adjustable
 - FF_AUTOCENTERautocenter is adjustable
 
-Note: In most cases you should use FF_PERIODIC instead of FF_RUMBLE. All
+.. note::
+
+- In most cases you should use FF_PERIODIC instead of FF_RUMBLE. All
   devices that support FF_RUMBLE support FF_PERIODIC (square, triangle,
   sine) and the other way around.
 
-Note: The exact syntax FF_CUSTOM is undefined for the time being as no driver
+- The exact syntax FF_CUSTOM is undefined for the time being as no driver
   supports it yet.
 
+::
 
-int ioctl(int fd, EVIOCGEFFECTS, int *n);
+int ioctl(int fd, EVIOCGEFFECTS, int *n);
 
 Returns the number of effects the device can keep in its memory.
 
-3.2 Uploading effects to the device
-~~~
-#include 
-#include 
+Uploading effects to the device
+---
 
-int ioctl(int file_descriptor, int request, struct ff_effect *effect);
+::
+
+#include 
+#include 
+
+int ioctl(int file_descriptor, int request, struct ff_effect *effect);
 
 "request" must be EVIOCSFF.
 
@@ -110,34 +130,41 @@ See  for a description of the 

[PATCH v2 11/37] docs: input/event-codes: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
Reviewed-by: Peter Hutterer 
---
 Documentation/input/event-codes.txt | 132 +---
 1 file changed, 92 insertions(+), 40 deletions(-)

diff --git a/Documentation/input/event-codes.txt 
b/Documentation/input/event-codes.txt
index 36ea940e5bb9..92db50954169 100644
--- a/Documentation/input/event-codes.txt
+++ b/Documentation/input/event-codes.txt
@@ -1,3 +1,8 @@
+=
+Input event codes
+=
+
+
 The input protocol uses a map of types and codes to express input device values
 to userspace. This document describes the types and codes and how and when they
 may be used.
@@ -17,82 +22,102 @@ reports supported by a device are also provided by sysfs in
 class/input/event*/device/capabilities/, and the properties of a device are
 provided in class/input/event*/device/properties.
 
-Event types:
+Event types
 ===
+
 Event types are groupings of codes under a logical input construct. Each
 type has a set of applicable codes to be used in generating events. See the
 Codes section for details on valid codes for each type.
 
 * EV_SYN:
+
   - Used as markers to separate events. Events may be separated in time or in
 space, such as with the multitouch protocol.
 
 * EV_KEY:
+
   - Used to describe state changes of keyboards, buttons, or other key-like
 devices.
 
 * EV_REL:
+
   - Used to describe relative axis value changes, e.g. moving the mouse 5 units
 to the left.
 
 * EV_ABS:
+
   - Used to describe absolute axis value changes, e.g. describing the
 coordinates of a touch on a touchscreen.
 
 * EV_MSC:
+
   - Used to describe miscellaneous input data that do not fit into other types.
 
 * EV_SW:
+
   - Used to describe binary state input switches.
 
 * EV_LED:
+
   - Used to turn LEDs on devices on and off.
 
 * EV_SND:
+
   - Used to output sound to devices.
 
 * EV_REP:
+
   - Used for autorepeating devices.
 
 * EV_FF:
+
   - Used to send force feedback commands to an input device.
 
 * EV_PWR:
+
   - A special type for power button and switch input.
 
 * EV_FF_STATUS:
+
   - Used to receive force feedback device status.
 
-Event codes:
+Event codes
 ===
+
 Event codes define the precise type of event.
 
-EV_SYN:
---
+EV_SYN
+--
+
 EV_SYN event values are undefined. Their usage is defined only by when they are
 sent in the evdev event stream.
 
 * SYN_REPORT:
+
   - Used to synchronize and separate events into packets of input data changes
 occurring at the same moment in time. For example, motion of a mouse may 
set
 the REL_X and REL_Y values for one motion, then emit a SYN_REPORT. The next
 motion will emit more REL_X and REL_Y values and send another SYN_REPORT.
 
 * SYN_CONFIG:
+
   - TBD
 
 * SYN_MT_REPORT:
+
   - Used to synchronize and separate touch events. See the
 multi-touch-protocol.txt document for more information.
 
 * SYN_DROPPED:
+
   - Used to indicate buffer overrun in the evdev client's event queue.
 Client should ignore all events up to and including next SYN_REPORT
 event and query the device (using EVIOCG* ioctls) to obtain its
 current state.
 
-EV_KEY:
---
+EV_KEY
+--
+
 EV_KEY events take the form KEY_ or BTN_. For example, KEY_A is 
used
 to represent the 'A' key on a keyboard. When a key is depressed, an event with
 the key's code is emitted with value 1. When the key is released, an event is
@@ -103,6 +128,7 @@ BTN_ is used for other types of momentary switch 
events.
 A few EV_KEY codes have special meanings:
 
 * BTN_TOOL_:
+
   - These codes are used in conjunction with input trackpads, tablets, and
 touchscreens. These devices may be used with fingers, pens, or other tools.
 When an event occurs and a tool is used, the corresponding BTN_TOOL_
@@ -112,6 +138,7 @@ A few EV_KEY codes have special meanings:
 code when events are generated.
 
 * BTN_TOUCH:
+
 BTN_TOUCH is used for touch contact. While an input tool is determined to 
be
 within meaningful physical contact, the value of this property must be set
 to 1. Meaningful physical contact may mean any contact, or it may mean
@@ -132,6 +159,7 @@ future, this distinction will be deprecated and the device 
properties ioctl
 EVIOCGPROP, defined in linux/input.h, will be used to convey the device type.
 
 * BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, BTN_TOOL_TRIPLETAP, BTN_TOOL_QUADTAP:
+
   - These codes denote one, two, three, and four finger interaction on a
 trackpad or touchscreen. For example, if the user uses two fingers and 
moves
 them on the touchpad in an effort to scroll content on screen,
@@ -147,8 +175,9 @@ a value of 1 in the same synchronization frame. This usage 
is deprecated.
 Note: In multitouch drivers, the input_mt_report_finger_count() 

[PATCH v2 35/37] input: add a EV_SW event for ratchet switch

[Mauro Carvalho Chehab]

Some mouses have a switch on their wheel, allowing to switch
between ratchet or free wheel mode. Add support for it.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/event-codes.rst| 16 
 include/linux/mod_devicetable.h|  2 +-
 include/uapi/linux/input-event-codes.h |  4 +++-
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Documentation/input/event-codes.rst 
b/Documentation/input/event-codes.rst
index 0c8591d39bc6..93f14f0ddb3d 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -239,6 +239,22 @@ Upon resume, if the switch state is the same as before 
suspend, then the input
 subsystem will filter out the duplicate switch state reports. The driver does
 not need to keep the state of the switch at any time.
 
+A few EV_SW codes have special meanings:
+
+* SW_RATCHET:
+
+  - Some mouses have a special switch at their wheel that allows to change
+from free wheel mode to ratchet mode.
+
+When such switch is ratchet mode (ON state), the wheel will offer some
+resistance for movements movement. It will also provide a tactile
+feedback when scrolled.
+
+When pressed while in ratchet mode, the wheel will switch to free wheel
+mode (OFF state). In this mode, it will offer no resistance to wheel
+movements nor any tactile feedback. Pressing again returns to ratchet
+mode.
+
 EV_MSC
 --
 
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 8850fcaf50db..038cddf1436a 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -292,7 +292,7 @@ struct pcmcia_device_id {
 #define INPUT_DEVICE_ID_LED_MAX0x0f
 #define INPUT_DEVICE_ID_SND_MAX0x07
 #define INPUT_DEVICE_ID_FF_MAX 0x7f
-#define INPUT_DEVICE_ID_SW_MAX 0x0f
+#define INPUT_DEVICE_ID_SW_MAX 0x1f
 
 #define INPUT_DEVICE_ID_MATCH_BUS  1
 #define INPUT_DEVICE_ID_MATCH_VENDOR   2
diff --git a/include/uapi/linux/input-event-codes.h 
b/include/uapi/linux/input-event-codes.h
index 23b2d377af59..a3eafd0527f1 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -782,7 +782,9 @@
 #define SW_LINEIN_INSERT   0x0d  /* set = inserted */
 #define SW_MUTE_DEVICE 0x0e  /* set = device disabled */
 #define SW_PEN_INSERTED0x0f  /* set = pen inserted */
-#define SW_MAX 0x0f
+#define SW_RATCHET 0x10  /* set = ratchet mode,
+unset: free wheel */
+#define SW_MAX 0x1f
 #define SW_CNT (SW_MAX+1)
 
 /*
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 27/37] docs: input/walkera0701: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/walkera0701.txt | 53 +
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/Documentation/input/walkera0701.txt 
b/Documentation/input/walkera0701.txt
index 49e3ac60dcef..2adda99ca717 100644
--- a/Documentation/input/walkera0701.txt
+++ b/Documentation/input/walkera0701.txt
@@ -1,3 +1,6 @@
+===
+Walkera WK-0701 transmitter
+===
 
 Walkera WK-0701 transmitter is supplied with a ready to fly Walkera
 helicopters such as HM36, HM37, HM60. The walkera0701 module enables to use
@@ -10,7 +13,8 @@ or use cogito:
 cg-clone http://zub.fei.tuke.sk/GIT/walkera0701-joystick
 
 
-Connecting to PC:
+Connecting to PC
+
 
 At back side of transmitter S-video connector can be found. Modulation
 pulses from processor to HF part can be found at pin 2 of this connector,
@@ -19,7 +23,8 @@ modulation pulses to PC, signal pulses must be amplified.
 
 Cable: (walkera TX to parport)
 
-Walkera WK-0701 TX S-VIDEO connector:
+Walkera WK-0701 TX S-VIDEO connector::
+
  (back side of TX)
  __   __  S-video:  canon25
 /  |_|  \ pin 2 (signal)  NPN   parport
@@ -30,10 +35,10 @@ Walkera WK-0701 TX S-VIDEO connector:
  ---3 __| 25 
GND
   E
 
-
 I use green LED and BC109 NPN transistor.
 
-Software:
+Software
+
 
 Build kernel with walkera0701 module. Module walkera0701 need exclusive
 access to parport, modules like lp must be unloaded before loading
@@ -44,7 +49,8 @@ be changed by TX "joystick", check output from 
/proc/interrupts. Value for
 
 
 
-Technical details:
+Technical details
+=
 
 Driver use interrupt from parport ACK input bit to measure pulse length
 using hrtimers.
@@ -53,17 +59,29 @@ Frame format:
 Based on walkera WK-0701 PCM Format description by Shaul Eizikovich.
 (downloaded from http://www.smartpropoplus.com/Docs/Walkera_Wk-0701_PCM.pdf)
 
-Signal pulses:
-   (ANALOG)
-SYNC  BIN   OCT
-  +-+  +--+
-  | |  |  |
---+ +--+  +---
-
-Frame:
+Signal pulses
+-
+
+::
+
+ (ANALOG)
+  SYNC  BIN   OCT
++-+  +--+
+| |  |  |
+  --+ +--+  +---
+
+Frame
+-
+
+::
+
  SYNC , BIN1, OCT1, BIN2, OCT2 ... BIN24, OCT24, BIN25, next frame SYNC ..
 
-pulse length:
+pulse length
+
+
+::
+
Binary values:  Analog octal values:
 
288 uS Binary 0 318 uS   000
@@ -80,7 +98,8 @@ pulse length:
 (Warning, pulses on ACK are inverted by transistor, irq is raised up on sync
 to bin change or octal value to bin change).
 
-Binary data representations:
+Binary data representations
+---
 
 One binary and octal value can be grouped to nibble. 24 nibbles + one binary
 values can be sampled between sync pulses.
@@ -100,10 +119,10 @@ binary value can be sampled. This bit and magic number is 
not used in
 software driver. Some details about this magic numbers can be found in
 Walkera_Wk-0701_PCM.pdf.
 
-Checksum calculation:
+Checksum calculation
+
 
 Summary of octal values in nibbles must be same as octal value in checksum
 nibble (only first 3 bits are used). Binary value for checksum nibble is
 calculated by sum of binary values in checked nibbles + sum of octal values
 in checked nibbles divided by 8. Only bit 0 of this sum is used.
-
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 03/37] docs: input/amijoy: convert it to ReST format

[Mauro Carvalho Chehab]

This file contains lots of tables, but none formatted using
the ReST syntax. Adjust them to match the ReST syntax
and add a title for the document.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/amijoy.txt | 165 +
 1 file changed, 118 insertions(+), 47 deletions(-)

diff --git a/Documentation/input/amijoy.txt b/Documentation/input/amijoy.txt
index 7dc4f175943c..25f516888a29 100644
--- a/Documentation/input/amijoy.txt
+++ b/Documentation/input/amijoy.txt
@@ -1,67 +1,100 @@
+~
+Amiga joystick extensions
+~
+
+
 Amiga 4-joystick parport extension
 ~~
+
 Parallel port pins:
 
- (2) - Up1  (6) - Up2
- (3) - Down1(7) - Down2
- (4) - Left1(8) - Left2
- (5) - Right1   (9) - Right2
-(13) - Fire1   (11) - Fire2
-(18) - Gnd1(18) - Gnd2
+
+=      ==
+PinMeaning  PinMeaning
+=      ==
+ 2 Up1  6 Up2
+ 3 Down17 Down2
+ 4 Left18 Left2
+ 5 Right1   9 Right2
+13 Fire1   11 Fire2
+18 Gnd118 Gnd2
+=      ==
 
 Amiga digital joystick pinout
 ~
-(1) - Up
-(2) - Down
-(3) - Left
-(4) - Right
-(5) - n/c
-(6) - Fire button
-(7) - +5V (50mA)
-(8) - Gnd
-(9) - Thumb button
+
+=== 
+Pin Meaning
+=== 
+1   Up
+2   Down
+3   Left
+4   Right
+5   n/c
+6   Fire button
+7   +5V (50mA)
+8   Gnd
+9   Thumb button
+=== 
 
 Amiga mouse pinout
 ~~
-(1) - V-pulse
-(2) - H-pulse
-(3) - VQ-pulse
-(4) - HQ-pulse
-(5) - Middle button
-(6) - Left button
-(7) - +5V (50mA)
-(8) - Gnd
-(9) - Right button
+
+=== 
+Pin Meaning
+=== 
+1   V-pulse
+2   H-pulse
+3   VQ-pulse
+4   HQ-pulse
+5   Middle button
+6   Left button
+7   +5V (50mA)
+8   Gnd
+9   Right button
+=== 
 
 Amiga analog joystick pinout
 
-(1) - Top button
-(2) - Top2 button
-(3) - Trigger button
-(4) - Thumb button
-(5) - Analog X
-(6) - n/c
-(7) - +5V (50mA)
-(8) - Gnd
-(9) - Analog Y
+
+=== ==
+Pin Meaning
+=== ==
+1   Top button
+2   Top2 button
+3   Trigger button
+4   Thumb button
+5   Analog X
+6   n/c
+7   +5V (50mA)
+8   Gnd
+9   Analog Y
+=== ==
 
 Amiga lightpen pinout
 ~
-(1) - n/c
-(2) - n/c
-(3) - n/c
-(4) - n/c
-(5) - Touch button
-(6) - /Beamtrigger
-(7) - +5V (50mA)
-(8) - Gnd
-(9) - Stylus button
+
+=== =
+Pin Meaning
+=== =
+1   n/c
+2   n/c
+3   n/c
+4   n/c
+5   Touch button
+6   /Beamtrigger
+7   +5V (50mA)
+8   Gnd
+9   Stylus button
+=== =
 
 ---
 
+ ===   == 
 NAME rev ADDR type chip   Description
 JOY0DAT  00A   R   Denise Joystick-mouse 0 data (left vert, horiz)
 JOY1DAT  00C   R   Denise Joystick-mouse 1 data (right vert,horiz)
+ ===   == 
 
 These addresses each read a 16 bit register. These in turn
 are loaded from the MDAT serial stream and are clocked in on
@@ -71,12 +104,16 @@ JOY1DAT  00C   R   Denise Joystick-mouse 1 data (right 
vert,horiz)
 controller ports (8 total) plus 8 miscellaneous control bits
 which are new for LISA and can be read in upper 8 bits of
 LISAID.
+
 Register bits are as follows:
-Mouse counter usage (pins  1,3 =Yclock, pins 2,4 =Xclock)
 
+- Mouse counter usage (pins  1,3 =Yclock, pins 2,4 =Xclock)
+
+ === === === === === === === === == === === === === === === ===
 BIT#  15  14  13  12  11  10  09  08 07  06  05  04  03  02  01  00
 JOY0DAT   Y7  Y6  Y5  Y4  Y3  Y2  Y1  Y0 X7  X6  X5  X4  X3  X2  X1  X0
 JOY1DAT   Y7  Y6  Y5  Y4  Y3  Y2  Y1  Y0 X7  X6  X5  X4  X3  X2  X1  X0
+ === === === === === === === === == === === === === === === ===
 
 0=LEFT CONTROLLER PAIR, 1=RIGHT CONTROLLER PAIR.
 (4 counters total). The bit usage for both left and right
@@ -88,12 +125,19 @@ JOY1DAT   Y7  Y6  Y5  Y4  Y3  Y2  Y1  Y0 X7  X6  X5  
X4  X3  X2  X1  X0
  | Serial | Bit Name | Description |
  ++--+-+
  |   0| M0H  | JOY0DAT Horizontal Clock|
+ ++--+-+
  |   1| M0HQ | JOY0DAT Horizontal Clock (quadrature)   |
+ ++--+-+
  |   2| M0V  | JOY0DAT Vertical Clock  |
+ ++--+-+
  |   3| M0VQ | 

[PATCH v2 10/37] docs: input/elantech: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

We opted to remove section numbers, as this can be automatically
generated on Sphinx, by using :numbered: tag at index.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/elantech.txt | 306 +--
 1 file changed, 165 insertions(+), 141 deletions(-)

diff --git a/Documentation/input/elantech.txt b/Documentation/input/elantech.txt
index 1ec0db7879d3..bb1302246506 100644
--- a/Documentation/input/elantech.txt
+++ b/Documentation/input/elantech.txt
@@ -10,9 +10,7 @@ Elantech Touchpad Driver
received from Woody at Xandros and forwarded to me
by user StewieGriffin at the eeeuser.com forum
 
-
-Contents
-
+.. Contents
 
  1. Introduction
  2. Extra knobs
@@ -45,8 +43,8 @@ Contents
 
 
 
-1. Introduction
-   
+Introduction
+
 
 Currently the Linux Elantech touchpad driver is aware of four different
 hardware versions unimaginatively called version 1,version 2, version 3
@@ -88,11 +86,8 @@ available Elantech documentation the information is provided 
here anyway for
 completeness sake.
 
 
-/
-
-
-2. Extra knobs
-   ~~~
+Extra knobs
+~~~
 
 Currently the Linux Elantech touchpad driver provides three extra knobs under
 /sys/bus/serio/drivers/psmouse/serio? for the user.
@@ -142,18 +137,17 @@ Currently the Linux Elantech touchpad driver provides 
three extra knobs under
Reading the crc_enabled value will show the active value. Echoing
"0" or "1" to this file will set the state to "0" or "1".
 
-/
+Differentiating hardware versions
+=
 
-3. Differentiating hardware versions
-   =
-
-To detect the hardware version, read the version number as 
param[0].param[1].param[2]
+To detect the hardware version, read the version number as 
param[0].param[1].param[2]::
 
  4 bytes version: (after the arrow is the name given in the Dell-provided 
driver)
  02.00.22 => EF013
  02.06.00 => EF019
+
 In the wild, there appear to be more versions, such as 00.01.64, 01.00.21,
-02.00.00, 02.00.04, 02.00.06.
+02.00.00, 02.00.04, 02.00.06::
 
  6 bytes:
  02.00.30 => EF113
@@ -162,6 +156,7 @@ In the wild, there appear to be more versions, such as 
00.01.64, 01.00.21,
  02.0B.00 => EF215
  04.01.XX => Scroll_EF051
  04.02.XX => EF051
+
 In the wild, there appear to be more versions, such as 04.03.01, 04.04.11. 
There
 appears to be almost no difference, except for EF113, which does not report
 pressure/width and has different data consistency checks.
@@ -170,21 +165,20 @@ Probably all the versions with param[0] <= 01 can be 
considered as
 4 bytes/firmware 1. The versions < 02.08.00, with the exception of 02.00.30, as
 4 bytes/firmware 2. Everything >= 02.08.00 can be considered as 6 bytes.
 
-/
 
-4. Hardware version 1
-   ==
+Hardware version 1
+~~
 
-4.1 Registers
-~
+Registers
+-
 
 By echoing a hexadecimal value to a register it contents can be altered.
 
-For example:
+For example::
 
echo -n 0x16 > reg_10
 
-* reg_10
+* reg_10::
 
bit   7   6   5   4   3   2   1   0
  B   C   T   D   L   A   S   E
@@ -198,7 +192,7 @@ For example:
  C: 1 = enable corner tap
  B: 1 = swap left and right button
 
-* reg_11
+* reg_11::
 
bit   7   6   5   4   3   2   1   0
  1   0   0   H   V   1   F   P
@@ -208,40 +202,41 @@ For example:
  V: 1 = enable vertical scroll area
  H: 1 = enable horizontal scroll area
 
-* reg_20
+* reg_20::
 
  single finger width?
 
-* reg_21
+* reg_21::
 
  scroll area width (small: 0x40 ... wide: 0xff)
 
-* reg_22
+* reg_22::
 
  drag lock time out (short: 0x14 ... long: 0xfe;
  0xff = tap again to release)
 
-* reg_23
+* reg_23::
 
  tap make timeout?
 
-* reg_24
+* reg_24::
 
  tap release timeout?
 
-* reg_25
+* reg_25::
 
  smart edge cursor speed (0x02 = slow, 0x03 = medium, 0x04 = fast)
 
-* reg_26
+* reg_26::
 
  smart edge activation area width?
 
 
-4.2 Native relative mode 4 byte packet format
-~
+Native relative mode 4 byte packet format
+-
+
+byte 0::
 
-byte 0:
bit   7   6   5   4   3   2   1   0
  c   c  p2  p1   1   M   R   L
 
@@ -251,20 +246,23 @@ byte 0:
 p1..p2 = byte 1 and 2 odd parity bit
  c = 1 when corner tap detected
 
-byte 1:
+byte 1::
+
bit   7   6   5   4   3   2   1   0
 dx7 dx6 dx5 dx4 dx3 dx2 dx1 dx0
 
  dx7..dx0 = x 

[PATCH v2 34/37] input: add an EV_REL event for high-res vertical wheel

[Mauro Carvalho Chehab]

As some devices can produce either low-res or high-res
vertical wheel EV_REL events, add a new event to allow
userspace to distinguish between them.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/event-codes.rst| 16 +---
 include/uapi/linux/input-event-codes.h |  1 +
 2 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/input/event-codes.rst 
b/Documentation/input/event-codes.rst
index 92db50954169..0c8591d39bc6 100644
--- a/Documentation/input/event-codes.rst
+++ b/Documentation/input/event-codes.rst
@@ -185,10 +185,20 @@ instead of EV_REL codes.
 
 A few EV_REL codes have special meanings:
 
-* REL_WHEEL, REL_HWHEEL:
+* REL_WHEEL:
 
-  - These codes are used for vertical and horizontal scroll wheels,
-respectively.
+  - These codes are used for vertical scroll wheels.
+
+  - REL_WHEEL is for normal wheel operational mode, e. g. low-resolution
+(line-based) scroll.
+
+  - REL_HIRES_WHEEL should be used when the wheel has two resolutions and it
+is in high-resolution mode, e. g. the same angular movement that would
+produce a single REL_WHEEL will produce multiple REL_HIRES_WHEEL events.
+
+* REL_HWHEEL:
+
+  - This code is used for horizontal scroll wheels.
 
 EV_ABS
 --
diff --git a/include/uapi/linux/input-event-codes.h 
b/include/uapi/linux/input-event-codes.h
index 3af60ee69053..23b2d377af59 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -703,6 +703,7 @@
 #define REL_DIAL   0x07
 #define REL_WHEEL  0x08
 #define REL_MISC   0x09
+#define REL_HIRES_WHEEL0x0a
 #define REL_MAX0x0f
 #define REL_CNT(REL_MAX+1)
 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 21/37] docs: input/multi-touch-protocol: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/multi-touch-protocol.txt | 196 +--
 1 file changed, 94 insertions(+), 102 deletions(-)

diff --git a/Documentation/input/multi-touch-protocol.txt 
b/Documentation/input/multi-touch-protocol.txt
index c51f1146f3bd..81775d7c1997 100644
--- a/Documentation/input/multi-touch-protocol.txt
+++ b/Documentation/input/multi-touch-protocol.txt
@@ -1,6 +1,10 @@
+.. include:: 
+
+=
 Multi-touch (MT) Protocol
--
-   Copyright (C) 2009-2010 Henrik Rydberg 
+=
+
+:Copyright: |copy| 2009-2010   Henrik Rydberg 
 
 
 Introduction
@@ -47,12 +51,12 @@ The main difference between the stateless type A protocol 
and the stateful
 type B slot protocol lies in the usage of identifiable contacts to reduce
 the amount of data sent to userspace. The slot protocol requires the use of
 the ABS_MT_TRACKING_ID, either provided by the hardware or computed from
-the raw data [5].
+the raw data [#f5]_.
 
 For type A devices, the kernel driver should generate an arbitrary
 enumeration of the full set of anonymous contacts currently on the
 surface. The order in which the packets appear in the event stream is not
-important.  Event filtering and finger tracking is left to user space [3].
+important.  Event filtering and finger tracking is left to user space [#f3]_.
 
 For type B devices, the kernel driver should associate a slot with each
 identified contact, and use that slot to propagate changes for the contact.
@@ -86,7 +90,7 @@ Protocol Example A
 --
 
 Here is what a minimal event sequence for a two-contact touch would look
-like for a type A device:
+like for a type A device::
 
ABS_MT_POSITION_X x[0]
ABS_MT_POSITION_Y y[0]
@@ -100,14 +104,14 @@ The sequence after moving one of the contacts looks 
exactly the same; the
 raw data for all present contacts are sent between every synchronization
 with SYN_REPORT.
 
-Here is the sequence after lifting the first contact:
+Here is the sequence after lifting the first contact::
 
ABS_MT_POSITION_X x[1]
ABS_MT_POSITION_Y y[1]
SYN_MT_REPORT
SYN_REPORT
 
-And here is the sequence after lifting the second contact:
+And here is the sequence after lifting the second contact::
 
SYN_MT_REPORT
SYN_REPORT
@@ -122,7 +126,7 @@ Protocol Example B
 --
 
 Here is what a minimal event sequence for a two-contact touch would look
-like for a type B device:
+like for a type B device::
 
ABS_MT_SLOT 0
ABS_MT_TRACKING_ID 45
@@ -134,13 +138,13 @@ like for a type B device:
ABS_MT_POSITION_Y y[1]
SYN_REPORT
 
-Here is the sequence after moving contact 45 in the x direction:
+Here is the sequence after moving contact 45 in the x direction::
 
ABS_MT_SLOT 0
ABS_MT_POSITION_X x[0]
SYN_REPORT
 
-Here is the sequence after lifting the contact in slot 0:
+Here is the sequence after lifting the contact in slot 0::
 
ABS_MT_TRACKING_ID -1
SYN_REPORT
@@ -149,7 +153,7 @@ The slot being modified is already 0, so the ABS_MT_SLOT is 
omitted.  The
 message removes the association of slot 0 with contact 45, thereby
 destroying contact 45 and freeing slot 0 to be reused for another contact.
 
-Finally, here is the sequence after lifting the second contact:
+Finally, here is the sequence after lifting the second contact::
 
ABS_MT_SLOT 1
ABS_MT_TRACKING_ID -1
@@ -181,6 +185,8 @@ ABS_MT_PRESSURE may be used to provide the pressure on the 
contact area
 instead. Devices capable of contact hovering can use ABS_MT_DISTANCE to
 indicate the distance between the contact and the surface.
 
+::
+
 
  Linux MT   Win8
  __ ___
@@ -212,7 +218,7 @@ via ABS_MT_BLOB_ID.
 
 The ABS_MT_TOOL_TYPE may be used to specify whether the touching tool is a
 finger or a pen or something else. Finally, the ABS_MT_TRACKING_ID event
-may be used to track identified contacts over time [5].
+may be used to track identified contacts over time [#f5]_.
 
 In the type B protocol, ABS_MT_TOOL_TYPE and ABS_MT_TRACKING_ID are
 implicitly handled by input core; drivers should instead call
@@ -223,117 +229,103 @@ Event Semantics
 ---
 
 ABS_MT_TOUCH_MAJOR
-
-The length of the major axis of the contact. The length should be given in
-surface units. If the surface has an X times Y resolution, the largest
-possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal [4].
+The length of the major axis of the contact. The length should be given in
+surface units. If the surface has an X times Y resolution, the largest
+possible value of ABS_MT_TOUCH_MAJOR is sqrt(X^2 + Y^2), the diagonal 
[#f4]_.
 
 

[PATCH v2 06/37] docs: input/bcm5974: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/bcm5974.txt | 43 +++--
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/Documentation/input/bcm5974.txt b/Documentation/input/bcm5974.txt
index 74d3876d6f34..4aca199b0aa6 100644
--- a/Documentation/input/bcm5974.txt
+++ b/Documentation/input/bcm5974.txt
@@ -1,19 +1,25 @@
+.. include:: 
+
+
 BCM5974 Driver (bcm5974)
 
-   Copyright (C) 2008-2009 Henrik Rydberg 
+
+:Copyright: |copy| 2008-2009   Henrik Rydberg 
 
 The USB initialization and package decoding was made by Scott Shawcroft as
 part of the touchd user-space driver project:
-   Copyright (C) 2008  Scott Shawcroft (scott.shawcr...@gmail.com)
+
+:Copyright: |copy| 2008Scott Shawcroft (scott.shawcr...@gmail.com)
 
 The BCM5974 driver is based on the appletouch driver:
-   Copyright (C) 2001-2004 Greg Kroah-Hartman (g...@kroah.com)
-   Copyright (C) 2005  Johannes Berg (johan...@sipsolutions.net)
-   Copyright (C) 2005  Stelian Pop (stel...@popies.net)
-   Copyright (C) 2005  Frank Arnold (fr...@scirocco-5v-turbo.de)
-   Copyright (C) 2005  Peter Osterlund (pete...@telia.com)
-   Copyright (C) 2005  Michael Hanselmann (linux-ker...@hansmi.ch)
-   Copyright (C) 2006  Nicolas Boichat (nico...@boichat.ch)
+
+:Copyright: |copy| 2001-2004   Greg Kroah-Hartman (g...@kroah.com)
+:Copyright: |copy| 2005Johannes Berg 
(johan...@sipsolutions.net)
+:Copyright: |copy| 2005Stelian Pop (stel...@popies.net)
+:Copyright: |copy| 2005Frank Arnold 
(fr...@scirocco-5v-turbo.de)
+:Copyright: |copy| 2005Peter Osterlund (pete...@telia.com)
+:Copyright: |copy| 2005Michael Hanselmann 
(linux-ker...@hansmi.ch)
+:Copyright: |copy| 2006Nicolas Boichat (nico...@boichat.ch)
 
 This driver adds support for the multi-touch trackpad on the new Apple
 Macbook Air and Macbook Pro laptops. It replaces the appletouch driver on
@@ -44,22 +50,21 @@ Debug output
 
 To ease the development for new hardware version, verbose packet output can
 be switched on with the debug kernel module parameter. The range [1-9]
-yields different levels of verbosity. Example (as root):
+yields different levels of verbosity. Example (as root)::
 
-echo -n 9 > /sys/module/bcm5974/parameters/debug
+echo -n 9 > /sys/module/bcm5974/parameters/debug
 
-tail -f /var/log/debug
+tail -f /var/log/debug
 
-echo -n 0 > /sys/module/bcm5974/parameters/debug
+echo -n 0 > /sys/module/bcm5974/parameters/debug
 
 Trivia
 --
 
-The driver was developed at the ubuntu forums in June 2008 [1], and now has
-a more permanent home at bitmath.org [2].
+The driver was developed at the ubuntu forums in June 2008 [#f1]_, and now has
+a more permanent home at bitmath.org [#f2]_.
 
-Links
--
+.. Links
 
-[1] http://ubuntuforums.org/showthread.php?t=840040
-[2] http://bitmath.org/code/
+.. [#f1] http://ubuntuforums.org/showthread.php?t=840040
+.. [#f2] http://bitmath.org/code/
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 32/37] docs: input/interactive: convert from xfig to svg

[Mauro Carvalho Chehab]

We're using svg as the standard format for vectorial images.

Convert it to .svg, in a way that it is easily editable.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/interactive.fig | 42 -
 Documentation/input/interactive.svg | 24 +
 2 files changed, 24 insertions(+), 42 deletions(-)
 delete mode 100644 Documentation/input/interactive.fig
 create mode 100644 Documentation/input/interactive.svg

diff --git a/Documentation/input/interactive.fig 
b/Documentation/input/interactive.fig
deleted file mode 100644
index 1e7de387723a..
--- a/Documentation/input/interactive.fig
+++ /dev/null
@@ -1,42 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
--2
-1200 2
-2 1 0 2 0 7 50 0 -1 6.000 0 0 -1 0 0 6
-1200 3600 1800 3600 2400 4800 3000 4800 4200 5700 4800 5700
-2 2 0 1 0 7 50 0 -1 4.000 0 0 -1 0 0 5
-1200 3150 4800 3150 4800 6300 1200 6300 1200 3150
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-1200 4800 4800 4800
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 4
-2400 4800 2400 6525 1950 7125 1950 7800
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 4
-3000 4800 3000 6525 3600 7125 3600 7800
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 1 3
-   0 0 1.00 60.00 120.00
-3825 5400 4125 5100 5400 5100
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 1 3
-   0 0 1.00 60.00 120.00
-2100 4200 2400 3900 5400 3900
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-4800 5700 5400 5700
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-1800 3600 5400 3600
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 1 3
-   0 0 1.00 60.00 120.00
-2700 4800 2700 4425 5400 4425
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
-   0 0 1.00 60.00 120.00
-   0 0 1.00 60.00 120.00
-1950 7800 3600 7800
-4 1 0 50 0 0 12 0. 4 135 810 2775 7725 Dead band\001
-4 0 0 50 0 0 12 0. 4 180 1155 5400 5700 right saturation\001
-4 0 0 50 0 0 12 0. 4 135 1065 5400 3600 left saturation\001
-4 0 0 50 0 0 12 0. 4 180 2505 5400 3900 left coeff ( positive in that case 
)\001
-4 0 0 50 0 0 12 0. 4 180 2640 5475 5100 right coeff ( negative in that 
case )\001
-4 0 0 50 0 0 12 0. 4 105 480 5400 4425 center\001
diff --git a/Documentation/input/interactive.svg 
b/Documentation/input/interactive.svg
new file mode 100644
index ..a3513709a09b
--- /dev/null
+++ b/Documentation/input/interactive.svg
@@ -0,0 +1,24 @@
+http://www.w3.org/2000/svg;>
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ Dead band
+ right 
saturation
+ left 
saturation
+ left coeff ( 
positive in that case )
+ right coeff ( 
negative in that case )
+ center
+
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 30/37] docs-rst: create a book with Linux Input documentation

[Mauro Carvalho Chehab]

Now that all files under Documentation/input follows the
ReST markup language, rename them to *.rst and create a
book for the Linux Input subsystem.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/conf.py  |  2 +
 Documentation/input/{alps.txt => alps.rst} |  0
 Documentation/input/{amijoy.txt => amijoy.rst} |  0
 .../input/{appletouch.txt => appletouch.rst}   |  0
 Documentation/input/{atarikbd.txt => atarikbd.rst} |  0
 Documentation/input/{bcm5974.txt => bcm5974.rst}   |  0
 Documentation/input/{cd32.txt => cd32.rst} |  0
 .../input/{cma3000_d0x.txt => cma3000_d0x.rst} |  0
 Documentation/input/conf.py| 10 +++
 Documentation/input/{cs461x.txt => cs461x.rst} |  0
 .../input/{edt-ft5x06.txt => edt-ft5x06.rst}   |  0
 Documentation/input/{elantech.txt => elantech.rst} |  0
 .../input/{event-codes.txt => event-codes.rst} |  0
 Documentation/input/{ff.txt => ff.rst} |  0
 Documentation/input/{gamepad.txt => gamepad.rst}   |  0
 ...rt-programming.txt => gameport-programming.rst} |  0
 .../input/{gpio-tilt.txt => gpio-tilt.rst} |  0
 .../{iforce-protocol.txt => iforce-protocol.rst}   |  0
 Documentation/input/index.rst  | 77 ++
 ...input-programming.txt => input-programming.rst} |  0
 Documentation/input/{input.txt => input.rst}   | 20 --
 .../input/{joystick-api.txt => joystick-api.rst}   |  0
 .../{joystick-parport.txt => joystick-parport.rst} |  0
 Documentation/input/{joystick.txt => joystick.rst} |  0
 ...touch-protocol.txt => multi-touch-protocol.rst} |  0
 Documentation/input/{notifier.txt => notifier.rst} |  0
 Documentation/input/{ntrig.txt => ntrig.rst}   |  0
 .../{rotary-encoder.txt => rotary-encoder.rst} |  0
 Documentation/input/{sentelic.txt => sentelic.rst} |  0
 Documentation/input/{userio.txt => userio.rst} |  0
 .../input/{walkera0701.txt => walkera0701.rst} |  0
 Documentation/input/{xpad.txt => xpad.rst} |  0
 Documentation/input/{yealink.txt => yealink.rst}   |  0
 33 files changed, 89 insertions(+), 20 deletions(-)
 rename Documentation/input/{alps.txt => alps.rst} (100%)
 rename Documentation/input/{amijoy.txt => amijoy.rst} (100%)
 rename Documentation/input/{appletouch.txt => appletouch.rst} (100%)
 rename Documentation/input/{atarikbd.txt => atarikbd.rst} (100%)
 rename Documentation/input/{bcm5974.txt => bcm5974.rst} (100%)
 rename Documentation/input/{cd32.txt => cd32.rst} (100%)
 rename Documentation/input/{cma3000_d0x.txt => cma3000_d0x.rst} (100%)
 create mode 100644 Documentation/input/conf.py
 rename Documentation/input/{cs461x.txt => cs461x.rst} (100%)
 rename Documentation/input/{edt-ft5x06.txt => edt-ft5x06.rst} (100%)
 rename Documentation/input/{elantech.txt => elantech.rst} (100%)
 rename Documentation/input/{event-codes.txt => event-codes.rst} (100%)
 rename Documentation/input/{ff.txt => ff.rst} (100%)
 rename Documentation/input/{gamepad.txt => gamepad.rst} (100%)
 rename Documentation/input/{gameport-programming.txt => 
gameport-programming.rst} (100%)
 rename Documentation/input/{gpio-tilt.txt => gpio-tilt.rst} (100%)
 rename Documentation/input/{iforce-protocol.txt => iforce-protocol.rst} (100%)
 create mode 100644 Documentation/input/index.rst
 rename Documentation/input/{input-programming.txt => input-programming.rst} 
(100%)
 rename Documentation/input/{input.txt => input.rst} (92%)
 rename Documentation/input/{joystick-api.txt => joystick-api.rst} (100%)
 rename Documentation/input/{joystick-parport.txt => joystick-parport.rst} 
(100%)
 rename Documentation/input/{joystick.txt => joystick.rst} (100%)
 rename Documentation/input/{multi-touch-protocol.txt => 
multi-touch-protocol.rst} (100%)
 rename Documentation/input/{notifier.txt => notifier.rst} (100%)
 rename Documentation/input/{ntrig.txt => ntrig.rst} (100%)
 rename Documentation/input/{rotary-encoder.txt => rotary-encoder.rst} (100%)
 rename Documentation/input/{sentelic.txt => sentelic.rst} (100%)
 rename Documentation/input/{userio.txt => userio.rst} (100%)
 rename Documentation/input/{walkera0701.txt => walkera0701.rst} (100%)
 rename Documentation/input/{xpad.txt => xpad.rst} (100%)
 rename Documentation/input/{yealink.txt => yealink.rst} (100%)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 7fadb3b83293..fef209edb4d7 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -348,6 +348,8 @@ latex_documents = [
  'The kernel development community', 'manual'),
 ('driver-api/index', 'driver-api.tex', 'The kernel driver API manual',
  'The kernel development community', 'manual'),
+('input/index', 'linux-input.tex', 'The Linux input driver subsystem',
+ 'The kernel development community', 'manual'),
 ('kernel-documentation', 'kernel-documentation.tex', 'The Linux Kernel 
Documentation',
  'The kernel development community', 

[PATCH v2 25/37] docs: input/sentelic: convert it to ReST format

[Mauro Carvalho Chehab]

This file has its own particular format that doesn't match any
markup one.

Manually change it to get something that would be readable
using ReST markup language.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/sentelic.txt | 1000 --
 1 file changed, 514 insertions(+), 486 deletions(-)

diff --git a/Documentation/input/sentelic.txt b/Documentation/input/sentelic.txt
index 89251e2a3eba..d1a476f973b1 100644
--- a/Documentation/input/sentelic.txt
+++ b/Documentation/input/sentelic.txt
@@ -1,411 +1,437 @@
-Copyright (C) 2002-2011 Sentelic Corporation.
-Last update: Dec-07-2011
+.. include:: 
+
+===
+Sentelic Driver
+===
+
+
+:Copyright: |copy| 2002-2011 Sentelic Corporation.
+
+:Last update: Dec-07-2011
+
+Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons)
+==
 
-==
-* Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons)
-==
 A) MSID 4: Scrolling wheel mode plus Forward page(4th button) and Backward
page (5th button)
-@1. Set sample rate to 200;
-@2. Set sample rate to 200;
-@3. Set sample rate to 80;
-@4. Issuing the "Get device ID" command (0xF2) and waits for the response;
-@5. FSP will respond 0x04.
-
-Packet 1
-   Bit 7 6 5 4 3 2 1 0   7 6 5 4 3 2 1 0  7 6 5 4 3 2 1 0  7 6 5 4 
3 2 1 0
-BYTE  |---|BYTE 
|---|BYTE|---|BYTE|---|
-  1   |Y|X|y|x|1|M|R|L|  2  |X|X|X|X|X|X|X|X|  3 |Y|Y|Y|Y|Y|Y|Y|Y|  4 | | 
|B|F|W|W|W|W|
-  |---| |---||---|
|---|
-
-Byte 1: Bit7 => Y overflow
-Bit6 => X overflow
-Bit5 => Y sign bit
-Bit4 => X sign bit
-Bit3 => 1
-Bit2 => Middle Button, 1 is pressed, 0 is not pressed.
-Bit1 => Right Button, 1 is pressed, 0 is not pressed.
-Bit0 => Left Button, 1 is pressed, 0 is not pressed.
-Byte 2: X Movement(9-bit 2's complement integers)
-Byte 3: Y Movement(9-bit 2's complement integers)
-Byte 4: Bit3~Bit0 => the scrolling wheel's movement since the last data report.
- valid values, -8 ~ +7
-Bit4 => 1 = 4th mouse button is pressed, Forward one page.
-0 = 4th mouse button is not pressed.
-Bit5 => 1 = 5th mouse button is pressed, Backward one page.
-0 = 5th mouse button is not pressed.
-
-B) MSID 6: Horizontal and Vertical scrolling.
-@ Set bit 1 in register 0x40 to 1
-
-# FSP replaces scrolling wheel's movement as 4 bits to show horizontal and
-  vertical scrolling.
-
-Packet 1
-   Bit 7 6 5 4 3 2 1 0   7 6 5 4 3 2 1 0  7 6 5 4 3 2 1 0  7 6 5 4 
3 2 1 0
-BYTE  |---|BYTE 
|---|BYTE|---|BYTE|---|
-  1   |Y|X|y|x|1|M|R|L|  2  |X|X|X|X|X|X|X|X|  3 |Y|Y|Y|Y|Y|Y|Y|Y|  4 | | 
|B|F|r|l|u|d|
-  |---| |---||---|
|---|
-
-Byte 1: Bit7 => Y overflow
-Bit6 => X overflow
-Bit5 => Y sign bit
-Bit4 => X sign bit
-Bit3 => 1
-Bit2 => Middle Button, 1 is pressed, 0 is not pressed.
-Bit1 => Right Button, 1 is pressed, 0 is not pressed.
-Bit0 => Left Button, 1 is pressed, 0 is not pressed.
-Byte 2: X Movement(9-bit 2's complement integers)
-Byte 3: Y Movement(9-bit 2's complement integers)
-Byte 4: Bit0 => the Vertical scrolling movement downward.
-   Bit1 => the Vertical scrolling movement upward.
-   Bit2 => the Horizontal scrolling movement leftward.
-   Bit3 => the Horizontal scrolling movement rightward.
-Bit4 => 1 = 4th mouse button is pressed, Forward one page.
-0 = 4th mouse button is not pressed.
-Bit5 => 1 = 5th mouse button is pressed, Backward one page.
-0 = 5th mouse button is not pressed.
-
-C) MSID 7:
-# FSP uses 2 packets (8 Bytes) to represent Absolute Position.
-  so we have PACKET NUMBER to identify packets.
+
+1. Set sample rate to 200;
+2. Set sample rate to 200;
+3. Set sample rate to 80;
+4. Issuing the "Get device ID" command (0xF2) and waits for the response;
+5. FSP will respond 0x04.
+
+::
+
+Packet 1
+Bit 7 6 5 4 3 2 1 0   7 6 5 4 3 2 1 0  7 6 5 4 3 2 1 0  7 6 5 
4 3 2 1 0
+BYTE  |---|BYTE 
|---|BYTE|---|BYTE|---|
+  1   |Y|X|y|x|1|M|R|L|  2  |X|X|X|X|X|X|X|X|  3 |Y|Y|Y|Y|Y|Y|Y|Y|  4 | | 
|B|F|W|W|W|W|
+ |---| |---||---|
|---|
+
+Byte 1: Bit7 => Y overflow
+   Bit6 => X overflow
+   Bit5 => Y sign bit
+   Bit4 => X sign bit
+   Bit3 => 1
+   Bit2 => 

[PATCH v2 15/37] docs: input/gpio-tilt: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/gpio-tilt.txt | 124 +++---
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/Documentation/input/gpio-tilt.txt 
b/Documentation/input/gpio-tilt.txt
index 2cdfd9bcb1af..23de9eff6a34 100644
--- a/Documentation/input/gpio-tilt.txt
+++ b/Documentation/input/gpio-tilt.txt
@@ -28,76 +28,76 @@ Example:
 
 
 Example configuration for a single TS1003 tilt switch that rotates around
-one axis in 4 steps and emits the current tilt via two GPIOs.
+one axis in 4 steps and emits the current tilt via two GPIOs::
 
-static int sg060_tilt_enable(struct device *dev) {
-   /* code to enable the sensors */
-};
+static int sg060_tilt_enable(struct device *dev) {
+   /* code to enable the sensors */
+};
 
-static void sg060_tilt_disable(struct device *dev) {
-   /* code to disable the sensors */
-};
+static void sg060_tilt_disable(struct device *dev) {
+   /* code to disable the sensors */
+};
 
-static struct gpio sg060_tilt_gpios[] = {
-   { SG060_TILT_GPIO_SENSOR1, GPIOF_IN, "tilt_sensor1" },
-   { SG060_TILT_GPIO_SENSOR2, GPIOF_IN, "tilt_sensor2" },
-};
+static struct gpio sg060_tilt_gpios[] = {
+   { SG060_TILT_GPIO_SENSOR1, GPIOF_IN, "tilt_sensor1" },
+   { SG060_TILT_GPIO_SENSOR2, GPIOF_IN, "tilt_sensor2" },
+};
 
-static struct gpio_tilt_state sg060_tilt_states[] = {
-   {
-   .gpios = (0 << 1) | (0 << 0),
-   .axes = (int[]) {
-   0,
-   },
-   }, {
-   .gpios = (0 << 1) | (1 << 0),
-   .axes = (int[]) {
-   1, /* 90 degrees */
-   },
-   }, {
-   .gpios = (1 << 1) | (1 << 0),
-   .axes = (int[]) {
-   2, /* 180 degrees */
-   },
-   }, {
-   .gpios = (1 << 1) | (0 << 0),
-   .axes = (int[]) {
-   3, /* 270 degrees */
-   },
-   },
-};
+static struct gpio_tilt_state sg060_tilt_states[] = {
+   {
+   .gpios = (0 << 1) | (0 << 0),
+   .axes = (int[]) {
+   0,
+   },
+   }, {
+   .gpios = (0 << 1) | (1 << 0),
+   .axes = (int[]) {
+   1, /* 90 degrees */
+   },
+   }, {
+   .gpios = (1 << 1) | (1 << 0),
+   .axes = (int[]) {
+   2, /* 180 degrees */
+   },
+   }, {
+   .gpios = (1 << 1) | (0 << 0),
+   .axes = (int[]) {
+   3, /* 270 degrees */
+   },
+   },
+};
 
-static struct gpio_tilt_axis sg060_tilt_axes[] = {
-   {
-   .axis = ABS_RY,
-   .min = 0,
-   .max = 3,
-   .fuzz = 0,
-   .flat = 0,
-   },
-};
+static struct gpio_tilt_axis sg060_tilt_axes[] = {
+   {
+   .axis = ABS_RY,
+   .min = 0,
+   .max = 3,
+   .fuzz = 0,
+   .flat = 0,
+   },
+};
 
-static struct gpio_tilt_platform_data sg060_tilt_pdata= {
-   .gpios = sg060_tilt_gpios,
-   .nr_gpios = ARRAY_SIZE(sg060_tilt_gpios),
+static struct gpio_tilt_platform_data sg060_tilt_pdata= {
+   .gpios = sg060_tilt_gpios,
+   .nr_gpios = ARRAY_SIZE(sg060_tilt_gpios),
 
-   .axes = sg060_tilt_axes,
-   .nr_axes = ARRAY_SIZE(sg060_tilt_axes),
+   .axes = sg060_tilt_axes,
+   .nr_axes = ARRAY_SIZE(sg060_tilt_axes),
 
-   .states = sg060_tilt_states,
-   .nr_states = ARRAY_SIZE(sg060_tilt_states),
+   .states = sg060_tilt_states,
+   .nr_states = ARRAY_SIZE(sg060_tilt_states),
 
-   .debounce_interval = 100,
+   .debounce_interval = 100,
 
-   .poll_interval = 1000,
-   .enable = sg060_tilt_enable,
-   .disable = sg060_tilt_disable,
-};
+   .poll_interval = 1000,
+   .enable = sg060_tilt_enable,
+   .disable = sg060_tilt_disable,
+};
 
-static struct platform_device sg060_device_tilt = {
-   .name = "gpio-tilt-polled",
-   .id = -1,
-   .dev = {
-   .platform_data = _tilt_pdata,
-   },
-};
+static struct platform_device sg060_device_tilt = {
+   .name = "gpio-tilt-polled",
+   .id = -1,
+   .dev = {
+   .platform_data = _tilt_pdata,
+   },
+};
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at 

[PATCH v2 36/37] hid-logitech-hidpp: add support for high res wheel

[Mauro Carvalho Chehab]

Some Logitech mouses (MX Anyware 2 and MX Master) have support
for a high-resolution wheel.

This wheel can work in backward-compatible mode, generating
wheel events via HID normal events, or it can use new
HID++ events that report not only the wheel movement, but also
the resolution.

Add support for it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/hid/hid-logitech-hidpp.c | 199 +++
 1 file changed, 199 insertions(+)

diff --git a/drivers/hid/hid-logitech-hidpp.c b/drivers/hid/hid-logitech-hidpp.c
index 2e2515a4c070..c208a5107511 100644
--- a/drivers/hid/hid-logitech-hidpp.c
+++ b/drivers/hid/hid-logitech-hidpp.c
@@ -62,6 +62,7 @@ MODULE_PARM_DESC(disable_tap_to_click,
 #define HIDPP_QUIRK_WTP_PHYSICAL_BUTTONS   BIT(22)
 #define HIDPP_QUIRK_NO_HIDINPUTBIT(23)
 #define HIDPP_QUIRK_FORCE_OUTPUT_REPORTS   BIT(24)
+#define HIDPP_QUIRK_HIRES_SCROLL   BIT(25)
 
 #define HIDPP_QUIRK_DELAYED_INIT   (HIDPP_QUIRK_NO_HIDINPUT | \
 HIDPP_QUIRK_CONNECT_EVENTS)
@@ -1361,6 +1362,67 @@ static int hidpp_ff_deinit(struct hid_device *hid)
return 0;
 }
 
+/* -- 
*/
+/* 0x2121: High Resolution Wheel  
*/
+/* -- 
*/
+
+#define HIDPP_HIGH_RES_WHEEL   0x2121
+
+#define CMD_MOUSE_SET_WHEEL_MODE   0x20
+#define CMD_MOUSE_GET_WHEEL_RATCHET0x30
+
+struct high_res_wheel_data {
+   u8 feature_index;
+   struct input_dev *input;
+   bool ratchet;
+};
+
+/**
+ * hidpp_mouse_set_wheel_mode - Sets high resolution wheel mode
+ *
+ * @invert:if true, inverts wheel movement
+ * @high_res:  if true, wheel is in high-resolution mode. Otherwise, low res
+ * @hidpp: if true, report wheel events via HID++ notification. If false,
+ * use standard HID events
+ */
+static int hidpp_mouse_set_wheel_mode(struct hidpp_device *hidpp,
+ bool invert,
+ bool high_res,
+ bool hidpp_mode)
+{
+   struct high_res_wheel_data *hrd = hidpp->private_data;
+   u8 feature_type;
+   struct hidpp_report response;
+   int ret;
+   u8 params[16] = { 0 };
+
+   if (!hrd->feature_index) {
+   ret = hidpp_root_get_feature(hidpp,
+   HIDPP_HIGH_RES_WHEEL,
+   >feature_index,
+   _type);
+   if (ret)
+   /* means that the device is not powered up */
+   return ret;
+   }
+
+   params[0] = invert ? 0x4 : 0  |
+   high_res   ? 0x2 : 0  |
+   hidpp_mode ? 0x1 : 0;
+
+   ret = hidpp_send_fap_command_sync(hidpp, hrd->feature_index,
+ CMD_MOUSE_SET_WHEEL_MODE,
+ params, 16, );
+   if (ret > 0) {
+   hid_err(hidpp->hid_dev, "%s: received protocol error 0x%02x\n",
+   __func__, ret);
+   return -EPROTO;
+   }
+   if (ret)
+   return ret;
+
+   return 0;
+}
 
 /* ** 
*/
 /*
*/
@@ -1816,6 +1878,119 @@ static int m560_input_mapping(struct hid_device *hdev, 
struct hid_input *hi,
 }
 
 /* - */
+/* Logitech mouse devices with high resolution wheel */
+/* - */
+
+static int high_res_raw_event(struct hid_device *hdev, u8 *data, int size)
+{
+   struct hidpp_device *hidpp = hid_get_drvdata(hdev);
+   struct high_res_wheel_data *hrd = hidpp->private_data;
+
+   /* Don't handle special raw events before setting feature_index */
+   if (!hrd || !hrd->feature_index)
+   return 0;
+
+   if (data[0] != REPORT_ID_HIDPP_LONG ||
+   data[2] != hrd->feature_index)
+   return 1;
+
+   if (size < 8) {
+   hid_err(hdev, "error in report: size = %d: %*ph\n", size,
+   size, data);
+   return 0;
+   }
+
+   /*
+* high res wheel mouse events
+*
+* Wheel movement events are like:
+*
+* 11 03 0b 00 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00
+*
+* data[0] = 0x11
+* data[1] = device-id
+* data[2] = feature index (0b)
+* data[3] = event type: 0x00 - wheel movement
+* data[4] = bitmask:
+  

[PATCH v2 20/37] docs: input/joystick-parport: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/joystick-parport.txt | 708 ---
 1 file changed, 370 insertions(+), 338 deletions(-)

diff --git a/Documentation/input/joystick-parport.txt 
b/Documentation/input/joystick-parport.txt
index 56870c70a796..0aa0fb17bf48 100644
--- a/Documentation/input/joystick-parport.txt
+++ b/Documentation/input/joystick-parport.txt
@@ -1,333 +1,349 @@
-   Linux Joystick parport drivers v2.0
-  (c) 1998-2000 Vojtech Pavlik 
-  (c) 1998 Andree Borrmann 
-Sponsored by SuSE
-
-
-0. Disclaimer
-~
-  Any information in this file is provided as-is, without any guarantee that
+.. include:: 
+
+.. _joystick-parport:
+
+===
+Linux Joystick parport drivers v2.0
+===
+
+:Copyright: |copy| 1998-2000 Vojtech Pavlik 
+:Copyright: |copy| 1998 Andree Borrmann 
+
+
+Sponsored by SuSE
+
+Disclaimer
+==
+
+Any information in this file is provided as-is, without any guarantee that
 it will be true. So, use it at your own risk. The possible damages that can
 happen include burning your parallel port, and/or the sticks and joystick
 and maybe even more. Like when a lightning kills you it is not our problem.
 
-1. Intro
-
-  The joystick parport drivers are used for joysticks and gamepads not
+Intro
+=
+
+The joystick parport drivers are used for joysticks and gamepads not
 originally designed for PCs and other computers Linux runs on. Because of
 that, PCs usually lack the right ports to connect these devices to. Parallel
 port, because of its ability to change single bits at will, and providing
 both output and input bits is the most suitable port on the PC for
 connecting such devices.
 
-2. Devices supported
-
-  Many console and 8-bit computer gamepads and joysticks are supported. The
+Devices supported
+=
+
+Many console and 8-bit computer gamepads and joysticks are supported. The
 following subsections discuss usage of each.
 
-2.1 NES and SNES
-
-  The Nintendo Entertainment System and Super Nintendo Entertainment System
+NES and SNES
+
+
+The Nintendo Entertainment System and Super Nintendo Entertainment System
 gamepads are widely available, and easy to get. Also, they are quite easy to
 connect to a PC, and don't need much processing speed (108 us for NES and
 165 us for SNES, compared to about 1000 us for PC gamepads) to communicate
 with them.
 
-  All NES and SNES use the same synchronous serial protocol, clocked from
+All NES and SNES use the same synchronous serial protocol, clocked from
 the computer's side (and thus timing insensitive). To allow up to 5 NES
 and/or SNES gamepads and/or SNES mice connected to the parallel port at once,
 the output lines of the parallel port are shared, while one of 5 available
 input lines is assigned to each gamepad.
 
-  This protocol is handled by the gamecon.c driver, so that's the one
+This protocol is handled by the gamecon.c driver, so that's the one
 you'll use for NES, SNES gamepads and SNES mice.
 
-  The main problem with PC parallel ports is that they don't have +5V power
+The main problem with PC parallel ports is that they don't have +5V power
 source on any of their pins. So, if you want a reliable source of power
 for your pads, use either keyboard or joystick port, and make a pass-through
 cable. You can also pull the power directly from the power supply (the red
 wire is +5V).
 
-  If you want to use the parallel port only, you can take the power is from
+If you want to use the parallel port only, you can take the power is from
 some data pin. For most gamepad and parport implementations only one pin is
 needed, and I'd recommend pin 9 for that, the highest data bit. On the other
 hand, if you are not planning to use anything else than NES / SNES on the
-port, anything between and including pin 4 and pin 9 will work.
+port, anything between and including pin 4 and pin 9 will work::
 
-(pin 9) -> Power
+(pin 9) -> Power
 
-  Unfortunately, there are pads that need a lot more of power, and parallel
+Unfortunately, there are pads that need a lot more of power, and parallel
 ports that can't give much current through the data pins. If this is your
 case, you'll need to use diodes (as a prevention of destroying your parallel
-port), and combine the currents of two or more data bits together.
+port), and combine the currents of two or more data bits together::
 
-  Diodes
-(pin 9) |>|---+--> Power
- |
-(pin 8) |>|---+
-   

[PATCH v2 17/37] docs: input/input-programming: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/input-programming.txt | 253 +++---
 1 file changed, 128 insertions(+), 125 deletions(-)

diff --git a/Documentation/input/input-programming.txt 
b/Documentation/input/input-programming.txt
index 7f8b9d97bc47..4d3b2e93 100644
--- a/Documentation/input/input-programming.txt
+++ b/Documentation/input/input-programming.txt
@@ -1,77 +1,78 @@
+~
 Programming input drivers
 ~
 
-1. Creating an input device driver
-~~
+Creating an input device driver
+===
 
-1.0 The simplest example
-
+The simplest example
+
 
 Here comes a very simple example of an input device driver. The device has
 just one button and the button is accessible at i/o port BUTTON_PORT. When
-pressed or released a BUTTON_IRQ happens. The driver could look like:
-
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-static struct input_dev *button_dev;
-
-static irqreturn_t button_interrupt(int irq, void *dummy)
-{
-   input_report_key(button_dev, BTN_0, inb(BUTTON_PORT) & 1);
-   input_sync(button_dev);
-   return IRQ_HANDLED;
-}
-
-static int __init button_init(void)
-{
-   int error;
-
-   if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
-printk(KERN_ERR "button.c: Can't allocate irq %d\n", 
button_irq);
-return -EBUSY;
-}
-
-   button_dev = input_allocate_device();
-   if (!button_dev) {
-   printk(KERN_ERR "button.c: Not enough memory\n");
-   error = -ENOMEM;
-   goto err_free_irq;
-   }
-
-   button_dev->evbit[0] = BIT_MASK(EV_KEY);
-   button_dev->keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0);
-
-   error = input_register_device(button_dev);
-   if (error) {
-   printk(KERN_ERR "button.c: Failed to register device\n");
-   goto err_free_dev;
-   }
-
-   return 0;
-
- err_free_dev:
-   input_free_device(button_dev);
- err_free_irq:
-   free_irq(BUTTON_IRQ, button_interrupt);
-   return error;
-}
-
-static void __exit button_exit(void)
-{
-input_unregister_device(button_dev);
-   free_irq(BUTTON_IRQ, button_interrupt);
-}
-
-module_init(button_init);
-module_exit(button_exit);
-
-1.1 What the example does
-~
+pressed or released a BUTTON_IRQ happens. The driver could look like::
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct input_dev *button_dev;
+
+static irqreturn_t button_interrupt(int irq, void *dummy)
+{
+   input_report_key(button_dev, BTN_0, inb(BUTTON_PORT) & 1);
+   input_sync(button_dev);
+   return IRQ_HANDLED;
+}
+
+static int __init button_init(void)
+{
+   int error;
+
+   if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
+   printk(KERN_ERR "button.c: Can't allocate irq %d\n", 
button_irq);
+   return -EBUSY;
+   }
+
+   button_dev = input_allocate_device();
+   if (!button_dev) {
+   printk(KERN_ERR "button.c: Not enough memory\n");
+   error = -ENOMEM;
+   goto err_free_irq;
+   }
+
+   button_dev->evbit[0] = BIT_MASK(EV_KEY);
+   button_dev->keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0);
+
+   error = input_register_device(button_dev);
+   if (error) {
+   printk(KERN_ERR "button.c: Failed to register device\n");
+   goto err_free_dev;
+   }
+
+   return 0;
+
+err_free_dev:
+   input_free_device(button_dev);
+err_free_irq:
+   free_irq(BUTTON_IRQ, button_interrupt);
+   return error;
+}
+
+static void __exit button_exit(void)
+{
+   input_unregister_device(button_dev);
+   free_irq(BUTTON_IRQ, button_interrupt);
+}
+
+module_init(button_init);
+module_exit(button_exit);
+
+What the example does
+~
 
 First it has to include the  file, which interfaces to the
 input subsystem. This provides all the definitions needed.
@@ -85,7 +86,7 @@ and sets up input bitfields. This way the device driver tells 
the other
 parts of the input systems what it is - what events can be generated or
 accepted by this input device. Our example device can only generate EV_KEY
 type events, and from those only BTN_0 event code. Thus we only set these
-two bits. We could have used
+two bits. We could have used::
 
set_bit(EV_KEY, button_dev.evbit);
set_bit(BTN_0, button_dev.keybit);
@@ -93,7 +94,7 @@ two bits. We could have used
 

[PATCH v2 19/37] docs: input/joystick: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/joystick.txt | 541 +--
 1 file changed, 293 insertions(+), 248 deletions(-)

diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt
index 8d027dc86c1f..202f5a090675 100644
--- a/Documentation/input/joystick.txt
+++ b/Documentation/input/joystick.txt
@@ -1,271 +1,291 @@
-  Linux Joystick driver v2.0.0
-  (c) 1996-2000 Vojtech Pavlik 
-Sponsored by SuSE
-
-
-0. Disclaimer
-~
-  This program is free software; you can redistribute it and/or modify it
+.. include:: 
+
+
+Linux Joystick driver v2.0.0
+
+
+:Copyright: |copy| 1996-2000 Vojtech Pavlik  - Sponsored by 
SuSE
+
+
+Disclaimer
+==
+
+This program is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the Free
 Software Foundation; either version 2 of the License, or (at your option)
 any later version.
 
-  This program is distributed in the hope that it will be useful, but
+This program is distributed in the hope that it will be useful, but
 WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
 or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 more details.
 
-  You should have received a copy of the GNU General Public License along
+You should have received a copy of the GNU General Public License along
 with this program; if not, write to the Free Software Foundation, Inc., 59
 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 
-  Should you need to contact me, the author, you can do so either by e-mail
+Should you need to contact me, the author, you can do so either by e-mail
 - mail your message to , or by paper mail: Vojtech Pavlik,
 Simunkova 1594, Prague 8, 182 00 Czech Republic
 
-  For your convenience, the GNU General Public License version 2 is included
+For your convenience, the GNU General Public License version 2 is included
 in the package: See the file COPYING.
 
-1. Intro
-
-  The joystick driver for Linux provides support for a variety of joysticks
+Intro
+=
+
+The joystick driver for Linux provides support for a variety of joysticks
 and similar devices. It is based on a larger project aiming to support all
 input devices in Linux.
 
-  Should you encounter any problems while using the driver, or joysticks
+Should you encounter any problems while using the driver, or joysticks
 this driver can't make complete use of, I'm very interested in hearing about
 them. Bug reports and success stories are also welcome.
 
-  The input project website is at:
+The input project website is at:
 
http://atrey.karlin.mff.cuni.cz/~vojtech/input/
 
-  There is also a mailing list for the driver at:
+There is also a mailing list for the driver at:
 
listp...@atrey.karlin.mff.cuni.cz
 
 send "subscribe linux-joystick Your Name" to subscribe to it.
 
-2. Usage
-
-  For basic usage you just choose the right options in kernel config and
+Usage
+=
+
+For basic usage you just choose the right options in kernel config and
 you should be set.
 
-2.1 inpututils
-~~
+inpututils
+--
+
 For testing and other purposes (for example serial devices), a set of
 utilities is available at the abovementioned website. I suggest you download
 and install it before going on.
 
-2.2 Device nodes
-
+Device nodes
+
+
 For applications to be able to use the joysticks,
-you'll have to manually create these nodes in /dev:
+you'll have to manually create these nodes in /dev::
 
-cd /dev
-rm js*
-mkdir input
-mknod input/js0 c 13 0
-mknod input/js1 c 13 1
-mknod input/js2 c 13 2
-mknod input/js3 c 13 3
-ln -s input/js0 js0
-ln -s input/js1 js1
-ln -s input/js2 js2
-ln -s input/js3 js3
+cd /dev
+rm js*
+mkdir input
+mknod input/js0 c 13 0
+mknod input/js1 c 13 1
+mknod input/js2 c 13 2
+mknod input/js3 c 13 3
+ln -s input/js0 js0
+ln -s input/js1 js1
+ln -s input/js2 js2
+ln -s input/js3 js3
 
-For testing with inpututils it's also convenient to create these:
+For testing with inpututils it's also convenient to create these::
 
-mknod input/event0 c 13 64
-mknod input/event1 c 13 65
-mknod input/event2 c 13 66
-mknod input/event3 c 13 67
+mknod input/event0 c 13 64
+mknod input/event1 c 13 65
+mknod input/event2 c 13 66
+mknod input/event3 c 13 67
 
-2.4 Modules needed 
-~~
-  For all joystick drivers to function, you'll need the userland interface
-module in kernel, either loaded or 

[PATCH v2 07/37] docs: input/cd32: convert it to ReST format

[Mauro Carvalho Chehab]

Currently, it misses a title, and the table is not valid for
ReST.

Adjust them, in order for it to be able to parse on Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/cd32.txt | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/Documentation/input/cd32.txt b/Documentation/input/cd32.txt
index a003d9b41eca..2bffe0f33e5e 100644
--- a/Documentation/input/cd32.txt
+++ b/Documentation/input/cd32.txt
@@ -1,3 +1,7 @@
+==
+Amiga CD32
+==
+
 I have written a small patch that let's me use my Amiga CD32
 joypad connected to the parallel port. Thought I'd share it with you so
 you can add it to the list of supported joysticks (hopefully someone will
@@ -5,15 +9,15 @@ find it useful).
 
 It needs the following wiring:
 
-CD32 pad   |   Parallel port
-
-1 (Up) |2 (D0)
-2 (Down)   |3 (D1)
-3 (Left)   |4 (D2)
-4 (Right)  |5 (D3)
-5 (Fire3)  |   14 (AUTOFD)
-6 (Fire1)  |   17 (SELIN)
-7 (+5V)|1 (STROBE)
-8 (Gnd)|   18 (Gnd)
-9 (Fire2)  |7 (D5)
-
+====
+CD32 pad   Parallel port
+1 (Up)  2 (D0)
+2 (Down)3 (D1)
+3 (Left)4 (D2)
+4 (Right)   5 (D3)
+5 (Fire3)  14 (AUTOFD)
+6 (Fire1)  17 (SELIN)
+7 (+5V) 1 (STROBE)
+8 (Gnd)18 (Gnd)
+9 (Fire2)   7 (D5)
+====
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 29/37] docs: input/yealink: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/yealink.txt | 164 +++-
 1 file changed, 93 insertions(+), 71 deletions(-)

diff --git a/Documentation/input/yealink.txt b/Documentation/input/yealink.txt
index 8277b76ec506..b231d8baf4bb 100644
--- a/Documentation/input/yealink.txt
+++ b/Documentation/input/yealink.txt
@@ -1,8 +1,12 @@
+===
 Driver documentation for yealink usb-p1k phones
+===
+
+Status
+==
 
-0. Status
-~
 The p1k is a relatively cheap usb 1.1 phone with:
+
   - keyboard   full support, yealink.ko / input event API
   - LCDfull support, yealink.ko / sysfs API
   - LEDfull support, yealink.ko / sysfs API
@@ -14,10 +18,11 @@ The p1k is a relatively cheap usb 1.1 phone with:
 For vendor documentation see http://www.yealink.com
 
 
-1. Compilation (stand alone version)
-
+Compilation (stand alone version)
+=
+
 Currently only kernel 2.6.x.y versions are supported.
-In order to build the yealink.ko module do
+In order to build the yealink.ko module do::
 
   make
 
@@ -26,26 +31,28 @@ the Makefile is pointing to the location where your kernel 
sources
 are located, default /usr/src/linux.
 
 
-1.1 Troubleshooting
-~~~
-Q: Module yealink compiled and installed without any problem but phone
-   is not initialized and does not react to any actions.
-A: If you see something like:
-   hiddev0: USB HID v1.00 Device [Yealink Network Technology Ltd. VOIP USB 
Phone
-   in dmesg, it means that the hid driver has grabbed the device first. Try to
-   load module yealink before any other usb hid driver. Please see the
-   instructions provided by your distribution on module configuration.
+Troubleshooting
+~~~
 
-Q: Phone is working now (displays version and accepts keypad input) but I can't
-   find the sysfs files.
-A: The sysfs files are located on the particular usb endpoint. On most
-   distributions you can do: "find /sys/ -name get_icons" for a hint.
+:Q: Module yealink compiled and installed without any problem but phone
+is not initialized and does not react to any actions.
+:A: If you see something like:
+hiddev0: USB HID v1.00 Device [Yealink Network Technology Ltd. VOIP USB 
Phone
+in dmesg, it means that the hid driver has grabbed the device first. Try to
+load module yealink before any other usb hid driver. Please see the
+instructions provided by your distribution on module configuration.
 
+:Q: Phone is working now (displays version and accepts keypad input) but I 
can't
+find the sysfs files.
+:A: The sysfs files are located on the particular usb endpoint. On most
+distributions you can do: "find /sys/ -name get_icons" for a hint.
+
+
+keyboard features
+=
 
-2. keyboard features
-
 The current mapping in the kernel is provided by the map_p1k_to_key
-function:
+function::
 
Physical USB-P1K button layout  input events
 
@@ -60,14 +67,15 @@ function:
 7  8  97, 8, 9,
 *  0  #*, 0, #,
 
-  The "up" and "down" keys, are symbolised by arrows on the button.
-  The "pickup" and "hangup" keys are symbolised by a green and red phone
-  on the button.
+The "up" and "down" keys, are symbolised by arrows on the button.
+The "pickup" and "hangup" keys are symbolised by a green and red phone
+on the button.
 
 
-3. LCD features
-~~~
-The LCD is divided and organised as a 3 line display:
+LCD features
+
+
+The LCD is divided and organised as a 3 line display::
 
 |[]   [][]   [][]   [][]   in   |[][]
 |[] M [][] D [][] : [][]   out  |[][]
@@ -79,18 +87,19 @@ The LCD is divided and organised as a 3 line display:
 [] [] [] [] [] [] [] [] [] [] [] []
 
 
-Line 1 Format (see below)  : 18.e8.M8.88...188
-   Icon names  :   M  D  :  IN OUT STORE
-Line 2  Format : .
-   Icon name   : NEW REP SU MO TU WE TH FR SA
-Line 3  Format : 
+  Line 1  Format (see below)   : 18.e8.M8.88...188
+ Icon names:   M  D  :  IN OUT STORE
+  Line 2  Format   : .
+ Icon name : NEW REP SU MO TU WE TH FR SA
+  Line 3  Format   : 
 
 
 Format description:
   From a userspace perspective the world is separated into "digits" and 
"icons".
   A digit can have a character set, an icon can only be ON or OFF.
 
-  Format specifier
+  Format specifier::
+
 '8' :  Generic 7 segment digit with individual addressable segments
 
 Reduced capability 

[PATCH v2 08/37] docs: input/cma3000_d0x: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/cma3000_d0x.txt | 72 -
 1 file changed, 48 insertions(+), 24 deletions(-)

diff --git a/Documentation/input/cma3000_d0x.txt 
b/Documentation/input/cma3000_d0x.txt
index 29d088db4afd..6f40c17c1aca 100644
--- a/Documentation/input/cma3000_d0x.txt
+++ b/Documentation/input/cma3000_d0x.txt
@@ -1,30 +1,37 @@
 Kernel driver for CMA3000-D0x
-
+=
 
 Supported chips:
 * VTI CMA3000-D0x
+
 Datasheet:
   CMA3000-D0X Product Family Specification 8281000A.02.pdf
   
 
-Author: Hemanth V 
+:Author: Hemanth V 
 
 
 Description
 ---
+
 CMA3000 Tri-axis accelerometer supports Motion detect, Measurement and
 Free fall modes.
 
-Motion Detect Mode: Its the low power mode where interrupts are generated only
-when motion exceeds the defined thresholds.
+Motion Detect Mode:
+Its the low power mode where interrupts are generated only
+when motion exceeds the defined thresholds.
 
-Measurement Mode: This mode is used to read the acceleration data on X,Y,Z
-axis and supports 400, 100, 40 Hz sample frequency.
+Measurement Mode:
+This mode is used to read the acceleration data on X,Y,Z
+axis and supports 400, 100, 40 Hz sample frequency.
 
-Free fall Mode: This mode is intended to save system resources.
+Free fall Mode:
+This mode is intended to save system resources.
 
-Threshold values: Chip supports defining threshold values for above modes
-which includes time and g value. Refer product specifications for more details.
+Threshold values:
+Chip supports defining threshold values for above modes
+which includes time and g value. Refer product specifications for
+more details.
 
 CMA3000 chip supports mutually exclusive I2C and SPI interfaces for
 communication, currently the driver supports I2C based communication only.
@@ -38,28 +45,40 @@ Platform data need to be configured for initial default 
values.
 
 Platform Data
 -
-fuzz_x: Noise on X Axis
 
-fuzz_y: Noise on Y Axis
+fuzz_x:
+Noise on X Axis
 
-fuzz_z: Noise on Z Axis
+fuzz_y:
+Noise on Y Axis
 
-g_range: G range in milli g i.e 2000 or 8000
+fuzz_z:
+Noise on Z Axis
 
-mode: Default Operating mode
+g_range:
+G range in milli g i.e 2000 or 8000
 
-mdthr: Motion detect g range threshold value
+mode:
+Default Operating mode
 
-mdfftmr: Motion detect and free fall time threshold value
+mdthr:
+Motion detect g range threshold value
 
-ffthr: Free fall g range threshold value
+mdfftmr:
+Motion detect and free fall time threshold value
+
+ffthr:
+Free fall g range threshold value
 
 Input Interface
---
+---
+
 Input driver version is 1.0.0
 Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
 Input device name: "cma3000-accelerometer"
-Supported events:
+
+Supported events::
+
   Event type 0 (Sync)
   Event type 3 (Absolute)
 Event code 0 (X)
@@ -87,7 +106,8 @@ Supported events:
 Register/Platform parameters Description
 
 
-mode:
+mode::
+
0: power down mode
1: 100 Hz Measurement mode
2: 400 Hz Measurement mode
@@ -97,19 +117,23 @@ mode:
6: 40 Hz Free fall mode
7: Power off mode
 
-grange:
+grange::
+
2000: 2000 mg or 2G Range
8000: 8000 mg or 8G Range
 
-mdthr:
+mdthr::
+
X: X * 71mg (8G Range)
X: X * 18mg (2G Range)
 
-mdfftmr:
+mdfftmr::
+
X: (X & 0x70) * 100 ms (MDTMR)
   (X & 0x0F) * 2.5 ms (FFTMR 400 Hz)
   (X & 0x0F) * 10 ms  (FFTMR 100 Hz)
 
-ffthr:
+ffthr::
+
X: (X >> 2) * 18mg (2G Range)
X: (X & 0x0F) * 71 mg (8G Range)
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 24/37] docs: input/rotary-encoder: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/rotary-encoder.txt | 74 +-
 1 file changed, 38 insertions(+), 36 deletions(-)

diff --git a/Documentation/input/rotary-encoder.txt 
b/Documentation/input/rotary-encoder.txt
index 46a74f0c551a..4695bea67f9b 100644
--- a/Documentation/input/rotary-encoder.txt
+++ b/Documentation/input/rotary-encoder.txt
@@ -1,8 +1,11 @@
+
 rotary-encoder - a generic driver for GPIO connected devices
-Daniel Mack , Feb 2009
+
 
-0. Function

+:Author: Daniel Mack , Feb 2009
+
+Function
+
 
 Rotary encoders are devices which are connected to the CPU or other
 peripherals with two wires. The outputs are phase-shifted by 90 degrees
@@ -13,7 +16,7 @@ Some encoders have both outputs low in stable states, others 
also have
 a stable state with both outputs high (half-period mode) and some have
 a stable state in all steps (quarter-period mode).
 
-The phase diagram of these two outputs look like this:
+The phase diagram of these two outputs look like this::
 
   _   _   _
  | | | | | |
@@ -40,8 +43,8 @@ For more information, please see
https://en.wikipedia.org/wiki/Rotary_encoder
 
 
-1. Events / state machine
--
+Events / state machine
+--
 
 In half-period mode, state a) and c) above are used to determine the
 rotational direction based on the last stable state. Events are reported in
@@ -65,16 +68,16 @@ d) Falling edge on channel B, channel A in low state
should have happened, unless it flipped back on half the way. The
'armed' state tells us about that.
 
-2. Platform requirements
-
+Platform requirements
+-
 
 As there is no hardware dependent call in this driver, the platform it is
 used with must support gpiolib. Another requirement is that IRQs must be
 able to fire on both edges.
 
 
-3. Board integration
-
+Board integration
+-
 
 To use this driver in your system, register a platform_device with the
 name 'rotary-encoder' and associate the IRQs and some specific platform
@@ -93,34 +96,33 @@ the configuration.
 Because GPIO to IRQ mapping is platform specific, this information must
 be given in separately to the driver. See the example below.
 
---
+::
 
-/* board support file example */
+/* board support file example */
 
-#include 
-#include 
+#include 
+#include 
 
-#define GPIO_ROTARY_A 1
-#define GPIO_ROTARY_B 2
+#define GPIO_ROTARY_A 1
+#define GPIO_ROTARY_B 2
 
-static struct rotary_encoder_platform_data my_rotary_encoder_info = {
-   .steps  = 24,
-   .axis   = ABS_X,
-   .relative_axis  = false,
-   .rollover   = false,
-   .gpio_a = GPIO_ROTARY_A,
-   .gpio_b = GPIO_ROTARY_B,
-   .inverted_a = 0,
-   .inverted_b = 0,
-   .half_period= false,
-   .wakeup_source  = false,
-};
-
-static struct platform_device rotary_encoder_device = {
-   .name   = "rotary-encoder",
-   .id = 0,
-   .dev= {
-   .platform_data = _rotary_encoder_info,
-   }
-};
+static struct rotary_encoder_platform_data my_rotary_encoder_info = {
+   .steps  = 24,
+   .axis   = ABS_X,
+   .relative_axis  = false,
+   .rollover   = false,
+   .gpio_a = GPIO_ROTARY_A,
+   .gpio_b = GPIO_ROTARY_B,
+   .inverted_a = 0,
+   .inverted_b = 0,
+   .half_period= false,
+   .wakeup_source  = false,
+};
 
+static struct platform_device rotary_encoder_device = {
+   .name   = "rotary-encoder",
+   .id = 0,
+   .dev= {
+   .platform_data = _rotary_encoder_info,
+   }
+};
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 28/37] docs: input/xpad: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/xpad.txt | 120 ---
 1 file changed, 68 insertions(+), 52 deletions(-)

diff --git a/Documentation/input/xpad.txt b/Documentation/input/xpad.txt
index d1b23f295db4..0bae002cf17a 100644
--- a/Documentation/input/xpad.txt
+++ b/Documentation/input/xpad.txt
@@ -1,4 +1,6 @@
+===
 xpad - Linux USB driver for Xbox compatible controllers
+===
 
 This driver exposes all first-party and third-party Xbox compatible
 controllers. It has a long history and has enjoyed considerable usage
@@ -15,9 +17,11 @@ the Xbox One's rumble protocol has not been reverse 
engineered but in
 the future could be supported.
 
 
-0. Notes
-
+Notes
+=
+
 The number of buttons/axes reported varies based on 3 things:
+
 - if you are using a known controller
 - if you are using a known dance pad
 - if using an unknown device (one not listed below), what you set in the
@@ -35,8 +39,9 @@ This is not true. Both dpad_to_buttons and 
triggers_to_buttons only affect
 unknown controllers.
 
 
-0.1 Normal Controllers
---
+Normal Controllers
+--
+
 With a normal controller, the directional pad is mapped to its own X/Y axes.
 The jstest-program from joystick-1.2.15 (jstest-version 2.1.0) will report 8
 axes and 10 buttons.
@@ -55,8 +60,9 @@ in game functionality were OK. However, I find it rather 
difficult to
 play first person shooters with a pad. Your mileage may vary.
 
 
-0.2 Xbox Dance Pads

+Xbox Dance Pads
+---
+
 When using a known dance pad, jstest will report 6 axes and 14 buttons.
 
 For dance style pads (like the redoctane pad) several changes
@@ -73,8 +79,9 @@ of buttons, see section 0.3 - Unknown Controllers
 I've tested this with Stepmania, and it works quite well.
 
 
-0.3 Unknown Controllers
---
+Unknown Controllers
+---
+
 If you have an unknown xbox controller, it should work just fine with
 the default settings.
 
@@ -88,9 +95,11 @@ to the list of supported devices, ensuring that it will work 
out of the
 box in the future.
 
 
-1. USB adapters
---
+USB adapters
+
+
 All generations of Xbox controllers speak USB over the wire.
+
 - Original Xbox controllers use a proprietary connector and require adapters.
 - Wireless Xbox 360 controllers require a 'Xbox 360 Wireless Gaming Receiver
   for Windows'
@@ -101,8 +110,9 @@ All generations of Xbox controllers speak USB over the wire.
 
 
 
-1.1 Original Xbox USB adapters
---
+Original Xbox USB adapters
+--
+
 Using this driver with an Original Xbox controller requires an
 adapter cable to break out the proprietary connector's pins to USB.
 You can buy these online fairly cheap, or build your own.
@@ -123,8 +133,8 @@ you can still use the controller with your X-Box, if you 
have one ;)
 
 
 
-2. Driver Installation
---
+Driver Installation
+===
 
 Once you have the adapter cable, if needed, and the controller connected
 the xpad module should be auto loaded. To confirm you can cat
@@ -132,13 +142,15 @@ the xpad module should be auto loaded. To confirm you can 
cat
 
 
 
-3. Supported Controllers
-
+Supported Controllers
+=
+
 For a full list of supported controllers and associated vendor and product
 IDs see the xpad_device[] array[6].
 
 As of the historic version 0.0.6 (2006-10-10) the following devices
-were supported:
+were supported::
+
  original Microsoft XBOX controller (US),vendor=0x045e, product=0x0202
  smaller  Microsoft XBOX controller (US),vendor=0x045e, product=0x0289
  original Microsoft XBOX controller (Japan), vendor=0x045e, product=0x0285
@@ -152,14 +164,16 @@ the module option 'dpad_to_buttons'.
 If you have an unrecognized controller please see 0.3 - Unknown Controllers
 
 
-4. Manual Testing
--
+Manual Testing
+==
+
 To test this driver's functionality you may use 'jstest'.
 
-For example:
-> modprobe xpad
-> modprobe joydev
-> jstest /dev/js0
+For example::
+
+> modprobe xpad
+> modprobe joydev
+> jstest /dev/js0
 
 If you're using a normal controller, there should be a single line showing
 18 inputs (8 axes, 10 buttons), and its values should change if you move
@@ -170,57 +184,59 @@ It works? Voila, you're done ;)
 
 
 
-5. Thanks
--
+Thanks
+==
 
 I have to thank ITO Takayuki for the detailed info on his site
- http://euc.jp/periphs/xbox-controller.ja.html.
- 
+http://euc.jp/periphs/xbox-controller.ja.html.
+
 His useful info and both the usb-skeleton as well as the iforce input driver
 (Greg 

[PATCH v2 09/37] docs: input/cs461x: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/cs461x.txt | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/Documentation/input/cs461x.txt b/Documentation/input/cs461x.txt
index 202e9dbacec3..1450436dcc9e 100644
--- a/Documentation/input/cs461x.txt
+++ b/Documentation/input/cs461x.txt
@@ -1,36 +1,40 @@
-Preface.
+Crystal SoundFusion CS4610/CS4612/CS461 joystick
+
+
+Preface
+---
 
 This is a new low-level driver to support analog joystick attached to
-Crystal SoundFusion CS4610/CS4612/CS4615. This code is based upon 
+Crystal SoundFusion CS4610/CS4612/CS4615. This code is based upon
 Vortex/Solo drivers as an example of decoration style, and ALSA
 0.5.8a kernel drivers as an chipset documentation and samples.
 
-This version does not have cooked mode support; the basic code 
-is present here, but have not tested completely. The button analysis 
-is completed in this mode, but the axis movement is not. 
+This version does not have cooked mode support; the basic code
+is present here, but have not tested completely. The button analysis
+is completed in this mode, but the axis movement is not.
 
 Raw mode works fine with analog joystick front-end driver and cs461x
-driver as a backend. I've tested this driver with CS4610, 4-axis and 
+driver as a backend. I've tested this driver with CS4610, 4-axis and
 4-button joystick; I mean the jstest utility. Also I've tried to
 play in xracer game using joystick, and the result is better than
 keyboard only mode.
 
 The sensitivity and calibrate quality have not been tested; the two
-reasons are performed: the same hardware cannot work under Win95 (blue 
-screen in VJOYD); I have no documentation on my chip; and the existing 
-behavior in my case was not raised the requirement of joystick calibration. 
+reasons are performed: the same hardware cannot work under Win95 (blue
+screen in VJOYD); I have no documentation on my chip; and the existing
+behavior in my case was not raised the requirement of joystick calibration.
 So the driver have no code to perform hardware related calibration.
 
 The patch contains minor changes of Config.in and Makefile files. All
 needed code have been moved to one separate file cs461x.c like ns558.c
 This driver have the basic support for PCI devices only; there is no
-ISA or PnP ISA cards supported. AFAIK the ns558 have support for Crystal 
+ISA or PnP ISA cards supported. AFAIK the ns558 have support for Crystal
 ISA and PnP ISA series.
 
 The driver works with ALSA drivers simultaneously. For example, the xracer
 uses joystick as input device and PCM device as sound output in one time.
 There are no sound or input collisions detected. The source code have
-comments about them; but I've found the joystick can be initialized 
+comments about them; but I've found the joystick can be initialized
 separately of ALSA modules. So, you can use only one joystick driver
 without ALSA drivers. The ALSA drivers are not needed to compile or
 run this driver.
@@ -38,7 +42,7 @@ run this driver.
 There are no debug information print have been placed in source, and no
 specific options required to work this driver. The found chipset parameters
 are printed via printk(KERN_INFO "..."), see the /var/log/messages to
-inspect cs461x: prefixed messages to determine possible card detection 
+inspect cs461x: prefixed messages to determine possible card detection
 errors.
 
 Regards,
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 04/37] docs: input/appletouch: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/appletouch.txt | 33 -
 1 file changed, 20 insertions(+), 13 deletions(-)

diff --git a/Documentation/input/appletouch.txt 
b/Documentation/input/appletouch.txt
index b13de3f89108..d56bd383d99c 100644
--- a/Documentation/input/appletouch.txt
+++ b/Documentation/input/appletouch.txt
@@ -1,12 +1,17 @@
+.. include:: 
+
+--
 Apple Touchpad Driver (appletouch)
 --
-   Copyright (C) 2005 Stelian Pop 
+
+:Copyright: |copy| 2005 Stelian Pop 
 
 appletouch is a Linux kernel driver for the USB touchpad found on post
 February 2005 and October 2005 Apple Aluminium Powerbooks.
 
-This driver is derived from Johannes Berg's appletrackpad driver[1], but it has
-been improved in some areas:
+This driver is derived from Johannes Berg's appletrackpad driver [#f1]_,
+but it has been improved in some areas:
+
* appletouch is a full kernel driver, no userspace program is necessary
* appletouch can be interfaced with the synaptics X11 driver, in order
  to have touchpad acceleration, scrolling, etc.
@@ -27,13 +32,13 @@ In X11, you can configure the touchpad to use the synaptics 
X11 driver, which
 will give additional functionalities, like acceleration, scrolling, 2 finger
 tap for middle button mouse emulation, 3 finger tap for right button mouse
 emulation, etc. In order to do this, make sure you're using a recent version of
-the synaptics driver (tested with 0.14.2, available from [2]), and configure a
-new input device in your X11 configuration file (take a look below for an
-example). For additional configuration, see the synaptics driver documentation.
+the synaptics driver (tested with 0.14.2, available from [#f2]_), and configure
+a new input device in your X11 configuration file (take a look below for an
+example). For additional configuration, see the synaptics driver 
documentation::
 
Section "InputDevice"
-   Identifier  "Synaptics Touchpad"
-   Driver  "synaptics"
+   Identifier  "Synaptics Touchpad"
+   Driver  "synaptics"
Option  "SendCoreEvents""true"
Option  "Device""/dev/input/mice"
Option  "Protocol"  "auto-dev"
@@ -73,13 +78,15 @@ the driver.
 
 You can activate debugging using the 'debug' module parameter. A value of 0
 deactivates any debugging, 1 activates tracing of invalid samples, 2 activates
-full tracing (each sample is being traced):
+full tracing (each sample is being traced)::
+
modprobe appletouch debug=1
or
echo "1" > /sys/module/appletouch/parameters/debug
 
-Links:
---
 
-[1]: http://johannes.sipsolutions.net/PowerBook/touchpad/
-[2]: 
http://web.archive.org/web/*/http://web.telia.com/~u89404340/touchpad/index.html
+.. Links:
+
+.. [#f1] http://johannes.sipsolutions.net/PowerBook/touchpad/
+
+.. [#f2] 
``_
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 02/37] docs: input/alps: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/alps.txt | 43 ++-
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/Documentation/input/alps.txt b/Documentation/input/alps.txt
index 8d1341ccde64..76a71a146e50 100644
--- a/Documentation/input/alps.txt
+++ b/Documentation/input/alps.txt
@@ -1,3 +1,4 @@
+--
 ALPS Touchpad Protocol
 --
 
@@ -78,7 +79,7 @@ of the EC response.
 Packet Format
 -
 
-In the following tables, the following notation is used.
+In the following tables, the following notation is used::
 
  CAPITALS = stick, miniscules = touchpad
 
@@ -88,6 +89,8 @@ extra buttons, stick buttons on a dualpoint, etc.
 PS/2 packet format
 --
 
+::
+
  byte 0:  00 YSGN XSGN1MRL
  byte 1: X7   X6   X5   X4   X3   X2   X1   X0
  byte 2: Y7   Y6   Y5   Y4   Y3   Y2   Y1   Y0
@@ -99,7 +102,9 @@ are on the touchpad, the M R L bits signal the combined 
status of both the
 pointingstick and touchpad buttons.
 
 ALPS Absolute Mode - Protocol Version 1
---
+---
+
+::
 
  byte 0:  10001   x9   x8   x7
  byte 1:  0   x6   x5   x4   x3   x2   x1   x0
@@ -111,6 +116,8 @@ ALPS Absolute Mode - Protocol Version 1
 ALPS Absolute Mode - Protocol Version 2
 ---
 
+::
+
  byte 0:  1???1  PSM  PSR  PSL
  byte 1:  0   x6   x5   x4   x3   x2   x1   x0
  byte 2:  0  x10   x9   x8   x7?  fin  ges
@@ -127,6 +134,8 @@ and PSL bits.
 Dualpoint device -- interleaved packet format
 -
 
+::
+
  byte 0:11001111
  byte 1:0   x6   x5   x4   x3   x2   x1   x0
  byte 2:0  x10   x9   x8   x70  fin  ges
@@ -149,7 +158,7 @@ ALPS protocol version 3 has three different packet formats. 
The first two are
 associated with touchpad events, and the third is associated with trackstick
 events.
 
-The first type is the touchpad position packet.
+The first type is the touchpad position packet::
 
  byte 0:1?   x1   x01111
  byte 1:0  x10   x9   x8   x7   x6   x5   x4
@@ -165,7 +174,7 @@ The second packet type contains bitmaps representing the x 
and y axes. In the
 bitmaps a given bit is set if there is a finger covering that position on the
 given axis. Thus the bitmap packet can be used for low-resolution multi-touch
 data, although finger tracking is not possible.  This packet also encodes the
-number of contacts (f1 and f0 in the table below).
+number of contacts (f1 and f0 in the table below)::
 
  byte 0:11   x1   x01111
  byte 1:0   x8   x7   x6   x5   x4   x3   x2
@@ -178,7 +187,7 @@ This packet only appears after a position packet with the 
mt bit set, and
 usually only appears when there are two or more contacts (although
 occasionally it's seen with only a single contact).
 
-The final v3 packet type is the trackstick packet.
+The final v3 packet type is the trackstick packet::
 
  byte 0:11   x7   y71111
  byte 1:0   x6   x5   x4   x3   x2   x1   x0
@@ -190,7 +199,7 @@ The final v3 packet type is the trackstick packet.
 ALPS Absolute Mode - Protocol Version 4
 ---
 
-Protocol version 4 has an 8-byte packet format.
+Protocol version 4 has an 8-byte packet format::
 
  byte 0:1?   x1   x01111
  byte 1:0  x10   x9   x8   x7   x6   x5   x4
@@ -203,7 +212,7 @@ Protocol version 4 has an 8-byte packet format.
 
 The last two bytes represent a partial bitmap packet, with 3 full packets
 required to construct a complete bitmap packet.  Once assembled, the 6-byte
-bitmap packet has the following format:
+bitmap packet has the following format::
 
  byte 0:01   x7   x6   x5   x4   x3   x2
  byte 1:0   x1   x0   y4   y3   y2   y1   y0
@@ -238,7 +247,7 @@ decode.  It uses the same alps_process_touchpad_packet_v3 
call with a
 specialized decode_fields function pointer to correctly interpret the
 packets.  This appears to only be used by the Dolphin devices.
 
-For single-touch, the 6-byte packet format is:
+For single-touch, the 6-byte packet format is::
 
  byte 0:11001000
  byte 1:0   x6   x5   x4   x3   x2   x1   x0
@@ -247,7 +256,7 @@ For single-touch, the 6-byte packet format is:
  byte 4:   y10  y9   y8   y7  x10   x9   x8   x7
  byte 5:0   z6   z5   z4   z3   z2   z1   z0
 
-For mt, the format is:
+For mt, the format is::
 
  byte 0:111n3   1   n2   n1   x24
  byte 1:1   y7   y6y5  y4   y3   y2y1
@@ -259,7 +268,7 @@ For mt, the format is:
 ALPS Absolute Mode - Protocol Version 6
 

[PATCH v2 23/37] docs: input/ntrig: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/ntrig.txt | 49 ++-
 1 file changed, 30 insertions(+), 19 deletions(-)

diff --git a/Documentation/input/ntrig.txt b/Documentation/input/ntrig.txt
index be1fd981f73f..a6b22ce6c61c 100644
--- a/Documentation/input/ntrig.txt
+++ b/Documentation/input/ntrig.txt
@@ -1,7 +1,11 @@
+.. include:: 
+
+=
 N-Trig touchscreen Driver
--
-   Copyright (c) 2008-2010 Rafi Rubin 
-   Copyright (c) 2009-2010 Stephane Chatty
+=
+
+:Copyright: |copy| 2008-2010 Rafi Rubin 
+:Copyright: |copy| 2009-2010 Stephane Chatty
 
 This driver provides support for N-Trig pen and multi-touch sensors.  Single
 and multi-touch events are translated to the appropriate protocols for
@@ -22,16 +26,18 @@ but only for that one device.
 
 The following parameters are used to configure filters to reduce noise:
 
-activate_slack number of fingers to ignore before processing events
-
-activation_height  size threshold to activate immediately
-activation_width
-
-min_height size threshold bellow which fingers are ignored
-min_width  both to decide activation and during activity
-
-deactivate_slack   the number of "no contact" frames to ignore before
-   propagating the end of activity events
++---+-+
+|activate_slack|number of fingers to ignore before processing 
events |
++---+-+
+|activation_height,|size threshold to activate immediately   |
+|activation_width  | |
++---+-+
+|min_height,   |size threshold bellow which fingers are ignored  |
+|min_width |both to decide activation and during activity|
++---+-+
+|deactivate_slack  |the number of "no contact" frames to ignore before   |
+|  |propagating the end of activity events   |
++---+-+
 
 When the last finger is removed from the device, it sends a number of empty
 frames.  By holding off on deactivation for a few frames we can tolerate false
@@ -44,15 +50,20 @@ Additional sysfs items
 --
 
 These nodes just provide easy access to the ranges reported by the device.
-sensor_logical_height  the range for positions reported during activity
-sensor_logical_width
 
-sensor_physical_height internal ranges not used for normal events but
-sensor_physical_width  useful for tuning
++---+-+
+|sensor_logical_height, | the range for positions reported during activity|
+|sensor_logical_width   | |
++---+-+
+|sensor_physical_height,| internal ranges not used for normal events but  |
+|sensor_physical_width  | useful for tuning   |
++---+-+
 
 All N-Trig devices with product id of 1 report events in the ranges of
-X: 0-9600
-Y: 0-7200
+
+* X: 0-9600
+* Y: 0-7200
+
 However not all of these devices have the same physical dimensions.  Most
 seem to be 12" sensors (Dell Latitude XT and XT2 and the HP TX2), and
 at least one model (Dell Studio 17) has a 17" sensor.  The ratio of physical
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 26/37] docs: input/userio: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/userio.txt | 79 +-
 1 file changed, 47 insertions(+), 32 deletions(-)

diff --git a/Documentation/input/userio.txt b/Documentation/input/userio.txt
index 0880c0f447a6..f780c77931fe 100644
--- a/Documentation/input/userio.txt
+++ b/Documentation/input/userio.txt
@@ -1,37 +1,47 @@
- The userio Protocol
-(c) 2015 Stephen Chandler Paul 
- Sponsored by Red Hat
-
-
-1. Introduction
-~~~
-  This module is intended to try to make the lives of input driver developers
+.. include:: 
+
+===
+The userio Protocol
+===
+
+
+:Copyright: |copy| 2015 Stephen Chandler Paul 
+
+Sponsored by Red Hat
+
+
+Introduction
+=
+
+This module is intended to try to make the lives of input driver developers
 easier by allowing them to test various serio devices (mainly the various
 touchpads found on laptops) without having to have the physical device in front
 of them. userio accomplishes this by allowing any privileged userspace program
 to directly interact with the kernel's serio driver and control a virtual serio
 port from there.
 
-2. Usage overview
-~
-  In order to interact with the userio kernel module, one simply opens the
+Usage overview
+==
+
+In order to interact with the userio kernel module, one simply opens the
 /dev/userio character device in their applications. Commands are sent to the
 kernel module by writing to the device, and any data received from the serio
 driver is read as-is from the /dev/userio device. All of the structures and
 macros you need to interact with the device are defined in  and
 .
 
-3. Command Structure
-
-  The struct used for sending commands to /dev/userio is as follows:
+Command Structure
+=
+
+The struct used for sending commands to /dev/userio is as follows::
 
struct userio_cmd {
__u8 type;
__u8 data;
};
 
-  "type" describes the type of command that is being sent. This can be any one
-of the USERIO_CMD macros defined in . "data" is the argument
+``type`` describes the type of command that is being sent. This can be any one
+of the USERIO_CMD macros defined in . ``data`` is the argument
 that goes along with the command. In the event that the command doesn't have an
 argument, this field can be left untouched and will be ignored by the kernel.
 Each command should be sent by writing the struct directly to the character
@@ -39,31 +49,36 @@ device. In the event that the command you send is invalid, 
an error will be
 returned by the character device and a more descriptive error will be printed
 to the kernel log. Only one command can be sent at a time, any additional data
 written to the character device after the initial command will be ignored.
-  To close the virtual serio port, just close /dev/userio.
 
-4. Commands
-~~~
+To close the virtual serio port, just close /dev/userio.
 
-4.1 USERIO_CMD_REGISTER
-~~~
-  Registers the port with the serio driver and begins transmitting data back 
and
+Commands
+
+
+USERIO_CMD_REGISTER
+~~~
+
+Registers the port with the serio driver and begins transmitting data back and
 forth. Registration can only be performed once a port type is set with
 USERIO_CMD_SET_PORT_TYPE. Has no argument.
 
-4.2 USERIO_CMD_SET_PORT_TYPE
-
-  Sets the type of port we're emulating, where "data" is the port type being
+USERIO_CMD_SET_PORT_TYPE
+
+
+Sets the type of port we're emulating, where ``data`` is the port type being
 set. Can be any of the macros from . For example: SERIO_8042
 would set the port type to be a normal PS/2 port.
 
-4.3 USERIO_CMD_SEND_INTERRUPT
-~
-  Sends an interrupt through the virtual serio port to the serio driver, where
-"data" is the interrupt data being sent.
+USERIO_CMD_SEND_INTERRUPT
+~
 
-5. Userspace tools
-~~
-  The userio userspace tools are able to record PS/2 devices using some of the
+Sends an interrupt through the virtual serio port to the serio driver, where
+``data`` is the interrupt data being sent.
+
+Userspace tools
+===
+
+The userio userspace tools are able to record PS/2 devices using some of the
 debugging information from i8042, and play back the devices on /dev/userio. The
 latest version of these tools can be found at:
 
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to 

[PATCH v2 11/33] docs: input/event-codes: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
Reviewed-by: Peter Hutterer 
---
 Documentation/input/event-codes.txt | 132 +---
 1 file changed, 92 insertions(+), 40 deletions(-)

diff --git a/Documentation/input/event-codes.txt 
b/Documentation/input/event-codes.txt
index 36ea940e5bb9..92db50954169 100644
--- a/Documentation/input/event-codes.txt
+++ b/Documentation/input/event-codes.txt
@@ -1,3 +1,8 @@
+=
+Input event codes
+=
+
+
 The input protocol uses a map of types and codes to express input device values
 to userspace. This document describes the types and codes and how and when they
 may be used.
@@ -17,82 +22,102 @@ reports supported by a device are also provided by sysfs in
 class/input/event*/device/capabilities/, and the properties of a device are
 provided in class/input/event*/device/properties.
 
-Event types:
+Event types
 ===
+
 Event types are groupings of codes under a logical input construct. Each
 type has a set of applicable codes to be used in generating events. See the
 Codes section for details on valid codes for each type.
 
 * EV_SYN:
+
   - Used as markers to separate events. Events may be separated in time or in
 space, such as with the multitouch protocol.
 
 * EV_KEY:
+
   - Used to describe state changes of keyboards, buttons, or other key-like
 devices.
 
 * EV_REL:
+
   - Used to describe relative axis value changes, e.g. moving the mouse 5 units
 to the left.
 
 * EV_ABS:
+
   - Used to describe absolute axis value changes, e.g. describing the
 coordinates of a touch on a touchscreen.
 
 * EV_MSC:
+
   - Used to describe miscellaneous input data that do not fit into other types.
 
 * EV_SW:
+
   - Used to describe binary state input switches.
 
 * EV_LED:
+
   - Used to turn LEDs on devices on and off.
 
 * EV_SND:
+
   - Used to output sound to devices.
 
 * EV_REP:
+
   - Used for autorepeating devices.
 
 * EV_FF:
+
   - Used to send force feedback commands to an input device.
 
 * EV_PWR:
+
   - A special type for power button and switch input.
 
 * EV_FF_STATUS:
+
   - Used to receive force feedback device status.
 
-Event codes:
+Event codes
 ===
+
 Event codes define the precise type of event.
 
-EV_SYN:
---
+EV_SYN
+--
+
 EV_SYN event values are undefined. Their usage is defined only by when they are
 sent in the evdev event stream.
 
 * SYN_REPORT:
+
   - Used to synchronize and separate events into packets of input data changes
 occurring at the same moment in time. For example, motion of a mouse may 
set
 the REL_X and REL_Y values for one motion, then emit a SYN_REPORT. The next
 motion will emit more REL_X and REL_Y values and send another SYN_REPORT.
 
 * SYN_CONFIG:
+
   - TBD
 
 * SYN_MT_REPORT:
+
   - Used to synchronize and separate touch events. See the
 multi-touch-protocol.txt document for more information.
 
 * SYN_DROPPED:
+
   - Used to indicate buffer overrun in the evdev client's event queue.
 Client should ignore all events up to and including next SYN_REPORT
 event and query the device (using EVIOCG* ioctls) to obtain its
 current state.
 
-EV_KEY:
---
+EV_KEY
+--
+
 EV_KEY events take the form KEY_ or BTN_. For example, KEY_A is 
used
 to represent the 'A' key on a keyboard. When a key is depressed, an event with
 the key's code is emitted with value 1. When the key is released, an event is
@@ -103,6 +128,7 @@ BTN_ is used for other types of momentary switch 
events.
 A few EV_KEY codes have special meanings:
 
 * BTN_TOOL_:
+
   - These codes are used in conjunction with input trackpads, tablets, and
 touchscreens. These devices may be used with fingers, pens, or other tools.
 When an event occurs and a tool is used, the corresponding BTN_TOOL_
@@ -112,6 +138,7 @@ A few EV_KEY codes have special meanings:
 code when events are generated.
 
 * BTN_TOUCH:
+
 BTN_TOUCH is used for touch contact. While an input tool is determined to 
be
 within meaningful physical contact, the value of this property must be set
 to 1. Meaningful physical contact may mean any contact, or it may mean
@@ -132,6 +159,7 @@ future, this distinction will be deprecated and the device 
properties ioctl
 EVIOCGPROP, defined in linux/input.h, will be used to convey the device type.
 
 * BTN_TOOL_FINGER, BTN_TOOL_DOUBLETAP, BTN_TOOL_TRIPLETAP, BTN_TOOL_QUADTAP:
+
   - These codes denote one, two, three, and four finger interaction on a
 trackpad or touchscreen. For example, if the user uses two fingers and 
moves
 them on the touchpad in an effort to scroll content on screen,
@@ -147,8 +175,9 @@ a value of 1 in the same synchronization frame. This usage 
is deprecated.
 Note: In multitouch drivers, the input_mt_report_finger_count() 

[PATCH v2 30/33] docs-rst: create a book with Linux Input documentation

[Mauro Carvalho Chehab]

Now that all files under Documentation/input follows the
ReST markup language, rename them to *.rst and create a
book for the Linux Input subsystem.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/conf.py  |  2 +
 Documentation/input/{alps.txt => alps.rst} |  0
 Documentation/input/{amijoy.txt => amijoy.rst} |  0
 .../input/{appletouch.txt => appletouch.rst}   |  0
 Documentation/input/{atarikbd.txt => atarikbd.rst} |  0
 Documentation/input/{bcm5974.txt => bcm5974.rst}   |  0
 Documentation/input/{cd32.txt => cd32.rst} |  0
 .../input/{cma3000_d0x.txt => cma3000_d0x.rst} |  0
 Documentation/input/conf.py| 10 +++
 Documentation/input/{cs461x.txt => cs461x.rst} |  0
 .../input/{edt-ft5x06.txt => edt-ft5x06.rst}   |  0
 Documentation/input/{elantech.txt => elantech.rst} |  0
 .../input/{event-codes.txt => event-codes.rst} |  0
 Documentation/input/{ff.txt => ff.rst} |  0
 Documentation/input/{gamepad.txt => gamepad.rst}   |  0
 ...rt-programming.txt => gameport-programming.rst} |  0
 .../input/{gpio-tilt.txt => gpio-tilt.rst} |  0
 .../{iforce-protocol.txt => iforce-protocol.rst}   |  0
 Documentation/input/index.rst  | 77 ++
 ...input-programming.txt => input-programming.rst} |  0
 Documentation/input/{input.txt => input.rst}   | 20 --
 .../input/{joystick-api.txt => joystick-api.rst}   |  0
 .../{joystick-parport.txt => joystick-parport.rst} |  0
 Documentation/input/{joystick.txt => joystick.rst} |  0
 ...touch-protocol.txt => multi-touch-protocol.rst} |  0
 Documentation/input/{notifier.txt => notifier.rst} |  0
 Documentation/input/{ntrig.txt => ntrig.rst}   |  0
 .../{rotary-encoder.txt => rotary-encoder.rst} |  0
 Documentation/input/{sentelic.txt => sentelic.rst} |  0
 Documentation/input/{userio.txt => userio.rst} |  0
 .../input/{walkera0701.txt => walkera0701.rst} |  0
 Documentation/input/{xpad.txt => xpad.rst} |  0
 Documentation/input/{yealink.txt => yealink.rst}   |  0
 33 files changed, 89 insertions(+), 20 deletions(-)
 rename Documentation/input/{alps.txt => alps.rst} (100%)
 rename Documentation/input/{amijoy.txt => amijoy.rst} (100%)
 rename Documentation/input/{appletouch.txt => appletouch.rst} (100%)
 rename Documentation/input/{atarikbd.txt => atarikbd.rst} (100%)
 rename Documentation/input/{bcm5974.txt => bcm5974.rst} (100%)
 rename Documentation/input/{cd32.txt => cd32.rst} (100%)
 rename Documentation/input/{cma3000_d0x.txt => cma3000_d0x.rst} (100%)
 create mode 100644 Documentation/input/conf.py
 rename Documentation/input/{cs461x.txt => cs461x.rst} (100%)
 rename Documentation/input/{edt-ft5x06.txt => edt-ft5x06.rst} (100%)
 rename Documentation/input/{elantech.txt => elantech.rst} (100%)
 rename Documentation/input/{event-codes.txt => event-codes.rst} (100%)
 rename Documentation/input/{ff.txt => ff.rst} (100%)
 rename Documentation/input/{gamepad.txt => gamepad.rst} (100%)
 rename Documentation/input/{gameport-programming.txt => 
gameport-programming.rst} (100%)
 rename Documentation/input/{gpio-tilt.txt => gpio-tilt.rst} (100%)
 rename Documentation/input/{iforce-protocol.txt => iforce-protocol.rst} (100%)
 create mode 100644 Documentation/input/index.rst
 rename Documentation/input/{input-programming.txt => input-programming.rst} 
(100%)
 rename Documentation/input/{input.txt => input.rst} (92%)
 rename Documentation/input/{joystick-api.txt => joystick-api.rst} (100%)
 rename Documentation/input/{joystick-parport.txt => joystick-parport.rst} 
(100%)
 rename Documentation/input/{joystick.txt => joystick.rst} (100%)
 rename Documentation/input/{multi-touch-protocol.txt => 
multi-touch-protocol.rst} (100%)
 rename Documentation/input/{notifier.txt => notifier.rst} (100%)
 rename Documentation/input/{ntrig.txt => ntrig.rst} (100%)
 rename Documentation/input/{rotary-encoder.txt => rotary-encoder.rst} (100%)
 rename Documentation/input/{sentelic.txt => sentelic.rst} (100%)
 rename Documentation/input/{userio.txt => userio.rst} (100%)
 rename Documentation/input/{walkera0701.txt => walkera0701.rst} (100%)
 rename Documentation/input/{xpad.txt => xpad.rst} (100%)
 rename Documentation/input/{yealink.txt => yealink.rst} (100%)

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 7fadb3b83293..fef209edb4d7 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -348,6 +348,8 @@ latex_documents = [
  'The kernel development community', 'manual'),
 ('driver-api/index', 'driver-api.tex', 'The kernel driver API manual',
  'The kernel development community', 'manual'),
+('input/index', 'linux-input.tex', 'The Linux input driver subsystem',
+ 'The kernel development community', 'manual'),
 ('kernel-documentation', 'kernel-documentation.tex', 'The Linux Kernel 
Documentation',
  'The kernel development community', 

[PATCH v2 01/33] docs: Documentation/input/input: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST.

Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/input.txt | 240 +++---
 1 file changed, 131 insertions(+), 109 deletions(-)

diff --git a/Documentation/input/input.txt b/Documentation/input/input.txt
index 7ebce100fe90..fda995e0ceb0 100644
--- a/Documentation/input/input.txt
+++ b/Documentation/input/input.txt
@@ -1,59 +1,67 @@
- Linux Input drivers v1.0
-  (c) 1999-2001 Vojtech Pavlik 
-Sponsored by SuSE
-
-
-0. Disclaimer
-~
-  This program is free software; you can redistribute it and/or modify it
+.. include:: 
+
+===
+Linux Input drivers
+===
+
+:Copyright: |copy| 1999-2001 Vojtech Pavlik  - Sponsored by 
SuSE
+
+Disclaimer
+==
+
+This program is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the Free
 Software Foundation; either version 2 of the License, or (at your option)
 any later version.
 
-  This program is distributed in the hope that it will be useful, but
+This program is distributed in the hope that it will be useful, but
 WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
 or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 more details.
 
-  You should have received a copy of the GNU General Public License along
+You should have received a copy of the GNU General Public License along
 with this program; if not, write to the Free Software Foundation, Inc., 59
 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 
-  Should you need to contact me, the author, you can do so either by e-mail
+Should you need to contact me, the author, you can do so either by e-mail
 - mail your message to , or by paper mail: Vojtech Pavlik,
 Simunkova 1594, Prague 8, 182 00 Czech Republic
 
-  For your convenience, the GNU General Public License version 2 is included
+For your convenience, the GNU General Public License version 2 is included
 in the package: See the file COPYING.
 
-1. Introduction
-~~~
-  This is a collection of drivers that is designed to support all input
+Introduction
+
+
+This is a collection of drivers that is designed to support all input
 devices under Linux. While it is currently used only on for USB input
 devices, future use (say 2.5/2.6) is expected to expand to replace
 most of the existing input system, which is why it lives in
 drivers/input/ instead of drivers/usb/.
 
-  The centre of the input drivers is the input module, which must be
+The centre of the input drivers is the input module, which must be
 loaded before any other of the input modules - it serves as a way of
 communication between two groups of modules:
 
-1.1 Device drivers
-~~
-  These modules talk to the hardware (for example via USB), and provide
+Device drivers
+--
+
+These modules talk to the hardware (for example via USB), and provide
 events (keystrokes, mouse movements) to the input module.
 
-1.2 Event handlers
-~~
-  These modules get events from input and pass them where needed via
+Event handlers
+--
+
+These modules get events from input and pass them where needed via
 various interfaces - keystrokes to the kernel, mouse movements via a
 simulated PS/2 interface to GPM and X and so on.
 
-2. Simple Usage
-~~~
-  For the most usual configuration, with one USB mouse and one USB keyboard,
+Simple Usage
+
+
+For the most usual configuration, with one USB mouse and one USB keyboard,
 you'll have to load the following modules (or have them built in to the
-kernel):
+kernel)::
 
input
mousedev
@@ -62,24 +70,25 @@ kernel):
uhci_hcd or ohci_hcd or ehci_hcd
usbhid
 
-  After this, the USB keyboard will work straight away, and the USB mouse
-will be available as a character device on major 13, minor 63:
+After this, the USB keyboard will work straight away, and the USB mouse
+will be available as a character device on major 13, minor 63::
 
crw-r--r--   1 root root  13,  63 Mar 28 22:45 mice
 
-  This device has to be created.
-  The commands to create it by hand are:
+This device has to be created.
+
+The commands to create it by hand are::
 
cd /dev
mkdir input
mknod input/mice c 13 63
 
-  After that you have to point GPM (the textmode mouse cut tool) and
-XFree to this device to use it - GPM should be called like:
+After that you have to point GPM (the textmode mouse cut tool) and
+XFree to this device to use it - GPM should be called like::
 
gpm -t ps2 -m /dev/input/mice
 
-  

[PATCH v2 20/33] docs: input/joystick-parport: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/joystick-parport.txt | 708 ---
 1 file changed, 370 insertions(+), 338 deletions(-)

diff --git a/Documentation/input/joystick-parport.txt 
b/Documentation/input/joystick-parport.txt
index 56870c70a796..0aa0fb17bf48 100644
--- a/Documentation/input/joystick-parport.txt
+++ b/Documentation/input/joystick-parport.txt
@@ -1,333 +1,349 @@
-   Linux Joystick parport drivers v2.0
-  (c) 1998-2000 Vojtech Pavlik 
-  (c) 1998 Andree Borrmann 
-Sponsored by SuSE
-
-
-0. Disclaimer
-~
-  Any information in this file is provided as-is, without any guarantee that
+.. include:: 
+
+.. _joystick-parport:
+
+===
+Linux Joystick parport drivers v2.0
+===
+
+:Copyright: |copy| 1998-2000 Vojtech Pavlik 
+:Copyright: |copy| 1998 Andree Borrmann 
+
+
+Sponsored by SuSE
+
+Disclaimer
+==
+
+Any information in this file is provided as-is, without any guarantee that
 it will be true. So, use it at your own risk. The possible damages that can
 happen include burning your parallel port, and/or the sticks and joystick
 and maybe even more. Like when a lightning kills you it is not our problem.
 
-1. Intro
-
-  The joystick parport drivers are used for joysticks and gamepads not
+Intro
+=
+
+The joystick parport drivers are used for joysticks and gamepads not
 originally designed for PCs and other computers Linux runs on. Because of
 that, PCs usually lack the right ports to connect these devices to. Parallel
 port, because of its ability to change single bits at will, and providing
 both output and input bits is the most suitable port on the PC for
 connecting such devices.
 
-2. Devices supported
-
-  Many console and 8-bit computer gamepads and joysticks are supported. The
+Devices supported
+=
+
+Many console and 8-bit computer gamepads and joysticks are supported. The
 following subsections discuss usage of each.
 
-2.1 NES and SNES
-
-  The Nintendo Entertainment System and Super Nintendo Entertainment System
+NES and SNES
+
+
+The Nintendo Entertainment System and Super Nintendo Entertainment System
 gamepads are widely available, and easy to get. Also, they are quite easy to
 connect to a PC, and don't need much processing speed (108 us for NES and
 165 us for SNES, compared to about 1000 us for PC gamepads) to communicate
 with them.
 
-  All NES and SNES use the same synchronous serial protocol, clocked from
+All NES and SNES use the same synchronous serial protocol, clocked from
 the computer's side (and thus timing insensitive). To allow up to 5 NES
 and/or SNES gamepads and/or SNES mice connected to the parallel port at once,
 the output lines of the parallel port are shared, while one of 5 available
 input lines is assigned to each gamepad.
 
-  This protocol is handled by the gamecon.c driver, so that's the one
+This protocol is handled by the gamecon.c driver, so that's the one
 you'll use for NES, SNES gamepads and SNES mice.
 
-  The main problem with PC parallel ports is that they don't have +5V power
+The main problem with PC parallel ports is that they don't have +5V power
 source on any of their pins. So, if you want a reliable source of power
 for your pads, use either keyboard or joystick port, and make a pass-through
 cable. You can also pull the power directly from the power supply (the red
 wire is +5V).
 
-  If you want to use the parallel port only, you can take the power is from
+If you want to use the parallel port only, you can take the power is from
 some data pin. For most gamepad and parport implementations only one pin is
 needed, and I'd recommend pin 9 for that, the highest data bit. On the other
 hand, if you are not planning to use anything else than NES / SNES on the
-port, anything between and including pin 4 and pin 9 will work.
+port, anything between and including pin 4 and pin 9 will work::
 
-(pin 9) -> Power
+(pin 9) -> Power
 
-  Unfortunately, there are pads that need a lot more of power, and parallel
+Unfortunately, there are pads that need a lot more of power, and parallel
 ports that can't give much current through the data pins. If this is your
 case, you'll need to use diodes (as a prevention of destroying your parallel
-port), and combine the currents of two or more data bits together.
+port), and combine the currents of two or more data bits together::
 
-  Diodes
-(pin 9) |>|---+--> Power
- |
-(pin 8) |>|---+
-   

[PATCH v2 27/33] docs: input/walkera0701: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/walkera0701.txt | 53 +
 1 file changed, 36 insertions(+), 17 deletions(-)

diff --git a/Documentation/input/walkera0701.txt 
b/Documentation/input/walkera0701.txt
index 49e3ac60dcef..2adda99ca717 100644
--- a/Documentation/input/walkera0701.txt
+++ b/Documentation/input/walkera0701.txt
@@ -1,3 +1,6 @@
+===
+Walkera WK-0701 transmitter
+===
 
 Walkera WK-0701 transmitter is supplied with a ready to fly Walkera
 helicopters such as HM36, HM37, HM60. The walkera0701 module enables to use
@@ -10,7 +13,8 @@ or use cogito:
 cg-clone http://zub.fei.tuke.sk/GIT/walkera0701-joystick
 
 
-Connecting to PC:
+Connecting to PC
+
 
 At back side of transmitter S-video connector can be found. Modulation
 pulses from processor to HF part can be found at pin 2 of this connector,
@@ -19,7 +23,8 @@ modulation pulses to PC, signal pulses must be amplified.
 
 Cable: (walkera TX to parport)
 
-Walkera WK-0701 TX S-VIDEO connector:
+Walkera WK-0701 TX S-VIDEO connector::
+
  (back side of TX)
  __   __  S-video:  canon25
 /  |_|  \ pin 2 (signal)  NPN   parport
@@ -30,10 +35,10 @@ Walkera WK-0701 TX S-VIDEO connector:
  ---3 __| 25 
GND
   E
 
-
 I use green LED and BC109 NPN transistor.
 
-Software:
+Software
+
 
 Build kernel with walkera0701 module. Module walkera0701 need exclusive
 access to parport, modules like lp must be unloaded before loading
@@ -44,7 +49,8 @@ be changed by TX "joystick", check output from 
/proc/interrupts. Value for
 
 
 
-Technical details:
+Technical details
+=
 
 Driver use interrupt from parport ACK input bit to measure pulse length
 using hrtimers.
@@ -53,17 +59,29 @@ Frame format:
 Based on walkera WK-0701 PCM Format description by Shaul Eizikovich.
 (downloaded from http://www.smartpropoplus.com/Docs/Walkera_Wk-0701_PCM.pdf)
 
-Signal pulses:
-   (ANALOG)
-SYNC  BIN   OCT
-  +-+  +--+
-  | |  |  |
---+ +--+  +---
-
-Frame:
+Signal pulses
+-
+
+::
+
+ (ANALOG)
+  SYNC  BIN   OCT
++-+  +--+
+| |  |  |
+  --+ +--+  +---
+
+Frame
+-
+
+::
+
  SYNC , BIN1, OCT1, BIN2, OCT2 ... BIN24, OCT24, BIN25, next frame SYNC ..
 
-pulse length:
+pulse length
+
+
+::
+
Binary values:  Analog octal values:
 
288 uS Binary 0 318 uS   000
@@ -80,7 +98,8 @@ pulse length:
 (Warning, pulses on ACK are inverted by transistor, irq is raised up on sync
 to bin change or octal value to bin change).
 
-Binary data representations:
+Binary data representations
+---
 
 One binary and octal value can be grouped to nibble. 24 nibbles + one binary
 values can be sampled between sync pulses.
@@ -100,10 +119,10 @@ binary value can be sampled. This bit and magic number is 
not used in
 software driver. Some details about this magic numbers can be found in
 Walkera_Wk-0701_PCM.pdf.
 
-Checksum calculation:
+Checksum calculation
+
 
 Summary of octal values in nibbles must be same as octal value in checksum
 nibble (only first 3 bits are used). Binary value for checksum nibble is
 calculated by sum of binary values in checked nibbles + sum of octal values
 in checked nibbles divided by 8. Only bit 0 of this sum is used.
-
-- 
2.9.3


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 12/33] docs: input/ff: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/ff.txt | 188 +++--
 1 file changed, 112 insertions(+), 76 deletions(-)

diff --git a/Documentation/input/ff.txt b/Documentation/input/ff.txt
index b3867bf49f8f..6d6688a63dd8 100644
--- a/Documentation/input/ff.txt
+++ b/Documentation/input/ff.txt
@@ -1,12 +1,16 @@
-Force feedback for Linux.
-By Johann Deneux  on 2001/04/22.
-Updated by Anssi Hannula  on 2006/04/09.
+
+Force feedback for Linux
+
+
+:Author: Johann Deneux  on 2001/04/22.
+:Updated: Anssi Hannula  on 2006/04/09.
+
 You may redistribute this file. Please remember to include shape.fig and
 interactive.fig as well.
-
 
-1. Introduction
-~~~
+Introduction
+
+
 This document describes how to use force feedback devices under Linux. The
 goal is not to support these devices as if they were simple input-only devices
 (as it is already the case), but to really enable the rendering of force
@@ -15,8 +19,9 @@ This document only describes the force feedback part of the 
Linux input
 interface. Please read joystick.txt and input.txt before reading further this
 document.
 
-2. Instructions to the user
-~~~
+Instructions to the user
+
+
 To enable force feedback, you have to:
 
 1. have your kernel configured with evdev and a driver that supports your
@@ -33,39 +38,48 @@ something goes wrong.
 If you have a serial iforce device, you need to start inputattach. See
 joystick.txt for details.
 
-2.1 Does it work ?
-~~
-There is an utility called fftest that will allow you to test the driver.
-% fftest /dev/input/eventXX
+Does it work ?
+--
+
+There is an utility called fftest that will allow you to test the driver::
+
+% fftest /dev/input/eventXX
+
+Instructions to the developer
+~
 
-3. Instructions to the developer
-~
 All interactions are done using the event API. That is, you can use ioctl()
 and write() on /dev/input/eventXX.
 This information is subject to change.
 
-3.1 Querying device capabilities
-
-#include 
-#include 
+Querying device capabilities
+
 
-#define BITS_TO_LONGS(x) \
-   (((x) + 8 * sizeof (unsigned long) - 1) / (8 * sizeof (unsigned long)))
-unsigned long features[BITS_TO_LONGS(FF_CNT)];
-int ioctl(int file_descriptor, int request, unsigned long *features);
+::
+
+#include 
+#include 
+
+#define BITS_TO_LONGS(x) \
+   (((x) + 8 * sizeof (unsigned long) - 1) / (8 * sizeof (unsigned 
long)))
+unsigned long features[BITS_TO_LONGS(FF_CNT)];
+int ioctl(int file_descriptor, int request, unsigned long *features);
 
 "request" must be EVIOCGBIT(EV_FF, size of features array in bytes )
 
 Returns the features supported by the device. features is a bitfield with the
 following bits:
+
 - FF_CONSTANT  can render constant force effects
 - FF_PERIODIC  can render periodic effects with the following waveforms:
+
   - FF_SQUAREsquare waveform
   - FF_TRIANGLE  triangle waveform
   - FF_SINE  sine waveform
   - FF_SAW_UPsawtooth up waveform
   - FF_SAW_DOWN  sawtooth down waveform
   - FF_CUSTOMcustom waveform
+
 - FF_RAMP   can render ramp effects
 - FF_SPRINGcan simulate the presence of a spring
 - FF_FRICTION  can simulate friction
@@ -75,24 +89,30 @@ following bits:
 - FF_GAIN  gain is adjustable
 - FF_AUTOCENTERautocenter is adjustable
 
-Note: In most cases you should use FF_PERIODIC instead of FF_RUMBLE. All
+.. note::
+
+- In most cases you should use FF_PERIODIC instead of FF_RUMBLE. All
   devices that support FF_RUMBLE support FF_PERIODIC (square, triangle,
   sine) and the other way around.
 
-Note: The exact syntax FF_CUSTOM is undefined for the time being as no driver
+- The exact syntax FF_CUSTOM is undefined for the time being as no driver
   supports it yet.
 
+::
 
-int ioctl(int fd, EVIOCGEFFECTS, int *n);
+int ioctl(int fd, EVIOCGEFFECTS, int *n);
 
 Returns the number of effects the device can keep in its memory.
 
-3.2 Uploading effects to the device
-~~~
-#include 
-#include 
+Uploading effects to the device
+---
 
-int ioctl(int file_descriptor, int request, struct ff_effect *effect);
+::
+
+#include 
+#include 
+
+int ioctl(int file_descriptor, int request, struct ff_effect *effect);
 
 "request" must be EVIOCSFF.
 
@@ -110,34 +130,41 @@ See  for a description of the 

[PATCH v2 32/33] docs: input/interactive: convert from xfig to svg

[Mauro Carvalho Chehab]

We're using svg as the standard format for vectorial images.

Convert it to .svg, in a way that it is easily editable.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/interactive.fig | 42 -
 Documentation/input/interactive.svg | 24 +
 2 files changed, 24 insertions(+), 42 deletions(-)
 delete mode 100644 Documentation/input/interactive.fig
 create mode 100644 Documentation/input/interactive.svg

diff --git a/Documentation/input/interactive.fig 
b/Documentation/input/interactive.fig
deleted file mode 100644
index 1e7de387723a..
--- a/Documentation/input/interactive.fig
+++ /dev/null
@@ -1,42 +0,0 @@
-#FIG 3.2
-Landscape
-Center
-Inches
-Letter  
-100.00
-Single
--2
-1200 2
-2 1 0 2 0 7 50 0 -1 6.000 0 0 -1 0 0 6
-1200 3600 1800 3600 2400 4800 3000 4800 4200 5700 4800 5700
-2 2 0 1 0 7 50 0 -1 4.000 0 0 -1 0 0 5
-1200 3150 4800 3150 4800 6300 1200 6300 1200 3150
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-1200 4800 4800 4800
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 4
-2400 4800 2400 6525 1950 7125 1950 7800
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 4
-3000 4800 3000 6525 3600 7125 3600 7800
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 1 3
-   0 0 1.00 60.00 120.00
-3825 5400 4125 5100 5400 5100
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 1 3
-   0 0 1.00 60.00 120.00
-2100 4200 2400 3900 5400 3900
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-4800 5700 5400 5700
-2 1 1 1 0 7 50 0 -1 4.000 0 0 -1 0 0 2
-1800 3600 5400 3600
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 0 1 3
-   0 0 1.00 60.00 120.00
-2700 4800 2700 4425 5400 4425
-2 1 0 1 0 7 50 0 -1 4.000 0 0 -1 1 1 2
-   0 0 1.00 60.00 120.00
-   0 0 1.00 60.00 120.00
-1950 7800 3600 7800
-4 1 0 50 0 0 12 0. 4 135 810 2775 7725 Dead band\001
-4 0 0 50 0 0 12 0. 4 180 1155 5400 5700 right saturation\001
-4 0 0 50 0 0 12 0. 4 135 1065 5400 3600 left saturation\001
-4 0 0 50 0 0 12 0. 4 180 2505 5400 3900 left coeff ( positive in that case 
)\001
-4 0 0 50 0 0 12 0. 4 180 2640 5475 5100 right coeff ( negative in that 
case )\001
-4 0 0 50 0 0 12 0. 4 105 480 5400 4425 center\001
diff --git a/Documentation/input/interactive.svg 
b/Documentation/input/interactive.svg
new file mode 100644
index ..a3513709a09b
--- /dev/null
+++ b/Documentation/input/interactive.svg
@@ -0,0 +1,24 @@
+http://www.w3.org/2000/svg;>
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ 
+ Dead band
+ right 
saturation
+ left 
saturation
+ left coeff ( 
positive in that case )
+ right coeff ( 
negative in that case )
+ center
+
-- 
2.9.3


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 19/33] docs: input/joystick: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/joystick.txt | 541 +--
 1 file changed, 293 insertions(+), 248 deletions(-)

diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt
index 8d027dc86c1f..202f5a090675 100644
--- a/Documentation/input/joystick.txt
+++ b/Documentation/input/joystick.txt
@@ -1,271 +1,291 @@
-  Linux Joystick driver v2.0.0
-  (c) 1996-2000 Vojtech Pavlik 
-Sponsored by SuSE
-
-
-0. Disclaimer
-~
-  This program is free software; you can redistribute it and/or modify it
+.. include:: 
+
+
+Linux Joystick driver v2.0.0
+
+
+:Copyright: |copy| 1996-2000 Vojtech Pavlik  - Sponsored by 
SuSE
+
+
+Disclaimer
+==
+
+This program is free software; you can redistribute it and/or modify it
 under the terms of the GNU General Public License as published by the Free
 Software Foundation; either version 2 of the License, or (at your option)
 any later version.
 
-  This program is distributed in the hope that it will be useful, but
+This program is distributed in the hope that it will be useful, but
 WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
 or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 more details.
 
-  You should have received a copy of the GNU General Public License along
+You should have received a copy of the GNU General Public License along
 with this program; if not, write to the Free Software Foundation, Inc., 59
 Temple Place, Suite 330, Boston, MA 02111-1307 USA
 
-  Should you need to contact me, the author, you can do so either by e-mail
+Should you need to contact me, the author, you can do so either by e-mail
 - mail your message to , or by paper mail: Vojtech Pavlik,
 Simunkova 1594, Prague 8, 182 00 Czech Republic
 
-  For your convenience, the GNU General Public License version 2 is included
+For your convenience, the GNU General Public License version 2 is included
 in the package: See the file COPYING.
 
-1. Intro
-
-  The joystick driver for Linux provides support for a variety of joysticks
+Intro
+=
+
+The joystick driver for Linux provides support for a variety of joysticks
 and similar devices. It is based on a larger project aiming to support all
 input devices in Linux.
 
-  Should you encounter any problems while using the driver, or joysticks
+Should you encounter any problems while using the driver, or joysticks
 this driver can't make complete use of, I'm very interested in hearing about
 them. Bug reports and success stories are also welcome.
 
-  The input project website is at:
+The input project website is at:
 
http://atrey.karlin.mff.cuni.cz/~vojtech/input/
 
-  There is also a mailing list for the driver at:
+There is also a mailing list for the driver at:
 
listp...@atrey.karlin.mff.cuni.cz
 
 send "subscribe linux-joystick Your Name" to subscribe to it.
 
-2. Usage
-
-  For basic usage you just choose the right options in kernel config and
+Usage
+=
+
+For basic usage you just choose the right options in kernel config and
 you should be set.
 
-2.1 inpututils
-~~
+inpututils
+--
+
 For testing and other purposes (for example serial devices), a set of
 utilities is available at the abovementioned website. I suggest you download
 and install it before going on.
 
-2.2 Device nodes
-
+Device nodes
+
+
 For applications to be able to use the joysticks,
-you'll have to manually create these nodes in /dev:
+you'll have to manually create these nodes in /dev::
 
-cd /dev
-rm js*
-mkdir input
-mknod input/js0 c 13 0
-mknod input/js1 c 13 1
-mknod input/js2 c 13 2
-mknod input/js3 c 13 3
-ln -s input/js0 js0
-ln -s input/js1 js1
-ln -s input/js2 js2
-ln -s input/js3 js3
+cd /dev
+rm js*
+mkdir input
+mknod input/js0 c 13 0
+mknod input/js1 c 13 1
+mknod input/js2 c 13 2
+mknod input/js3 c 13 3
+ln -s input/js0 js0
+ln -s input/js1 js1
+ln -s input/js2 js2
+ln -s input/js3 js3
 
-For testing with inpututils it's also convenient to create these:
+For testing with inpututils it's also convenient to create these::
 
-mknod input/event0 c 13 64
-mknod input/event1 c 13 65
-mknod input/event2 c 13 66
-mknod input/event3 c 13 67
+mknod input/event0 c 13 64
+mknod input/event1 c 13 65
+mknod input/event2 c 13 66
+mknod input/event3 c 13 67
 
-2.4 Modules needed 
-~~
-  For all joystick drivers to function, you'll need the userland interface
-module in kernel, either loaded or 

[PATCH v2 22/33] docs: input/notifier: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/notifier.txt | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/Documentation/input/notifier.txt b/Documentation/input/notifier.txt
index 95172ca6f3d2..161350cb865e 100644
--- a/Documentation/input/notifier.txt
+++ b/Documentation/input/notifier.txt
@@ -1,4 +1,6 @@
+=
 Keyboard notifier
+=
 
 One can use register_keyboard_notifier to get called back on keyboard
 events (see kbd_keycode() function for details).  The passed structure is
@@ -23,9 +25,9 @@ For each kind of event but the last, the callback may return 
NOTIFY_STOP in
 order to "eat" the event: the notify loop is stopped and the keyboard event is
 dropped.
 
-In a rough C snippet, we have:
+In a rough C snippet, we have::
 
-kbd_keycode(keycode) {
+kbd_keycode(keycode) {
...
params.value = keycode;
if (notifier_call_chain(KBD_KEYCODE,) == NOTIFY_STOP)
@@ -47,6 +49,6 @@ kbd_keycode(keycode) {
return;
apply keysym;
notifier_call_chain(KBD_POST_KEYSYM,);
-}
+}
 
-NOTE: This notifier is usually called from interrupt context.
+.. note:: This notifier is usually called from interrupt context.
-- 
2.9.3


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 00/33] Convert input documentation to ReST

[Mauro Carvalho Chehab]

As I'm needing to touch some Input documentation, I took the time
to also convert the existing documents to ReST markup, building them
with Sphinx. The end result can be seen at:

   http://www.infradead.org/~mchehab/kernel_docs/input/

Instead of placing the documentation under Documentation/driver-api, I opted
to keep them at Documentation/input. The rationale is that the documentation
there doesn't have only driver-api bits, but other things too.

Those patches are based on the linux-input tree, on its next branch:
   git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next

Please notice that I converted the two existing XFIG files there to SVG. As the
Documentation/sphinx/kfigure.py doesn't exist at the input tree, I opted
to use the ".. figure" tag to include the SVG files. This should be changed to
use the right extension, after merging upstream, but this should be a two line
patch that can be applied afterwards.

PS.: I didn't try to update the contents of the documentation int his series.

v2:
   - Rebased on current upstream, fixing a conflict at input.txt;
   - Added Peter Hutterer ack to event-codes.txt

Mauro Carvalho Chehab (33):
  docs: Documentation/input/input: convert it to ReST format
  docs: input/alps: convert it to ReST format
  docs: input/amijoy: convert it to ReST format
  docs: input/appletouch: convert it to ReST format
  docs: input/atarikbd: convert it to ReST format
  docs: input/bcm5974: convert it to ReST format
  docs: input/cd32: convert it to ReST format
  docs: input/cma3000_d0x: convert it to ReST format
  docs: input/cs461x: convert it to ReST format
  docs: input/elantech: convert it to ReST format
  docs: input/event-codes: convert it to ReST format
  docs: input/ff: convert it to ReST format
  docs: input/gamepad: convert it to ReST format
  docs: input/gameport-programming: convert it to ReST format
  docs: input/gpio-tilt: convert it to ReST format
  docs: input/iforce-protocol: convert it to ReST format
  docs: input/input-programming: convert it to ReST format
  docs: input/joystick-api: convert it to ReST format
  docs: input/joystick: convert it to ReST format
  docs: input/joystick-parport: convert it to ReST format
  docs: input/multi-touch-protocol: convert it to ReST format
  docs: input/notifier: convert it to ReST format
  docs: input/ntrig: convert it to ReST format
  docs: input/rotary-encoder: convert it to ReST format
  docs: input/sentelic: convert it to ReST format
  docs: input/userio: convert it to ReST format
  docs: input/walkera0701: convert it to ReST format
  docs: input/xpad: convert it to ReST format
  docs: input/yealink: convert it to ReST format
  docs-rst: create a book with Linux Input documentation
  docs: input/shape: convert it from xfig to svg
  docs: input/interactive: convert from xfig to svg
  docs: ff.rst: use svg files instead of xfig

 Documentation/conf.py  |   2 +
 Documentation/input/{alps.txt => alps.rst} |  43 +-
 Documentation/input/{amijoy.txt => amijoy.rst} | 165 ++--
 .../input/{appletouch.txt => appletouch.rst}   |  33 +-
 Documentation/input/{atarikbd.txt => atarikbd.rst} | 214 +++--
 Documentation/input/{bcm5974.txt => bcm5974.rst}   |  43 +-
 Documentation/input/cd32.rst   |  23 +
 Documentation/input/cd32.txt   |  19 -
 .../input/{cma3000_d0x.txt => cma3000_d0x.rst} |  72 +-
 Documentation/input/conf.py|  10 +
 Documentation/input/{cs461x.txt => cs461x.rst} |  28 +-
 .../input/{edt-ft5x06.txt => edt-ft5x06.rst}   |   0
 Documentation/input/{elantech.txt => elantech.rst} | 306 +++
 .../input/{event-codes.txt => event-codes.rst} | 132 ++-
 Documentation/input/{ff.txt => ff.rst} | 205 +++--
 Documentation/input/{gamepad.txt => gamepad.rst}   |  43 +-
 ...rt-programming.txt => gameport-programming.rst} |  83 +-
 Documentation/input/gpio-tilt.rst  | 103 +++
 Documentation/input/gpio-tilt.txt  | 103 ---
 Documentation/input/iforce-protocol.rst| 381 +
 Documentation/input/iforce-protocol.txt| 258 --
 Documentation/input/index.rst  |  77 ++
 ...input-programming.txt => input-programming.rst} | 253 +++---
 Documentation/input/{input.txt => input.rst}   | 238 +++---
 Documentation/input/interactive.fig|  42 -
 Documentation/input/interactive.svg|  24 +
 .../input/{joystick-api.txt => joystick-api.rst}   | 138 ++--
 Documentation/input/joystick-parport.rst   | 574 +
 Documentation/input/joystick-parport.txt   | 542 -
 Documentation/input/{joystick.txt => joystick.rst} | 541 +++--
 ...touch-protocol.txt => multi-touch-protocol.rst} | 196 +++--
 Documentation/input/{notifier.txt => notifier.rst} |  10 +-
 Documentation/input/{ntrig.txt => ntrig.rst}   |  49 +-
 .../{rotary-encoder.txt => 

[PATCH v2 06/33] docs: input/bcm5974: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/bcm5974.txt | 43 +++--
 1 file changed, 24 insertions(+), 19 deletions(-)

diff --git a/Documentation/input/bcm5974.txt b/Documentation/input/bcm5974.txt
index 74d3876d6f34..4aca199b0aa6 100644
--- a/Documentation/input/bcm5974.txt
+++ b/Documentation/input/bcm5974.txt
@@ -1,19 +1,25 @@
+.. include:: 
+
+
 BCM5974 Driver (bcm5974)
 
-   Copyright (C) 2008-2009 Henrik Rydberg 
+
+:Copyright: |copy| 2008-2009   Henrik Rydberg 
 
 The USB initialization and package decoding was made by Scott Shawcroft as
 part of the touchd user-space driver project:
-   Copyright (C) 2008  Scott Shawcroft (scott.shawcr...@gmail.com)
+
+:Copyright: |copy| 2008Scott Shawcroft (scott.shawcr...@gmail.com)
 
 The BCM5974 driver is based on the appletouch driver:
-   Copyright (C) 2001-2004 Greg Kroah-Hartman (g...@kroah.com)
-   Copyright (C) 2005  Johannes Berg (johan...@sipsolutions.net)
-   Copyright (C) 2005  Stelian Pop (stel...@popies.net)
-   Copyright (C) 2005  Frank Arnold (fr...@scirocco-5v-turbo.de)
-   Copyright (C) 2005  Peter Osterlund (pete...@telia.com)
-   Copyright (C) 2005  Michael Hanselmann (linux-ker...@hansmi.ch)
-   Copyright (C) 2006  Nicolas Boichat (nico...@boichat.ch)
+
+:Copyright: |copy| 2001-2004   Greg Kroah-Hartman (g...@kroah.com)
+:Copyright: |copy| 2005Johannes Berg 
(johan...@sipsolutions.net)
+:Copyright: |copy| 2005Stelian Pop (stel...@popies.net)
+:Copyright: |copy| 2005Frank Arnold 
(fr...@scirocco-5v-turbo.de)
+:Copyright: |copy| 2005Peter Osterlund (pete...@telia.com)
+:Copyright: |copy| 2005Michael Hanselmann 
(linux-ker...@hansmi.ch)
+:Copyright: |copy| 2006Nicolas Boichat (nico...@boichat.ch)
 
 This driver adds support for the multi-touch trackpad on the new Apple
 Macbook Air and Macbook Pro laptops. It replaces the appletouch driver on
@@ -44,22 +50,21 @@ Debug output
 
 To ease the development for new hardware version, verbose packet output can
 be switched on with the debug kernel module parameter. The range [1-9]
-yields different levels of verbosity. Example (as root):
+yields different levels of verbosity. Example (as root)::
 
-echo -n 9 > /sys/module/bcm5974/parameters/debug
+echo -n 9 > /sys/module/bcm5974/parameters/debug
 
-tail -f /var/log/debug
+tail -f /var/log/debug
 
-echo -n 0 > /sys/module/bcm5974/parameters/debug
+echo -n 0 > /sys/module/bcm5974/parameters/debug
 
 Trivia
 --
 
-The driver was developed at the ubuntu forums in June 2008 [1], and now has
-a more permanent home at bitmath.org [2].
+The driver was developed at the ubuntu forums in June 2008 [#f1]_, and now has
+a more permanent home at bitmath.org [#f2]_.
 
-Links
--
+.. Links
 
-[1] http://ubuntuforums.org/showthread.php?t=840040
-[2] http://bitmath.org/code/
+.. [#f1] http://ubuntuforums.org/showthread.php?t=840040
+.. [#f2] http://bitmath.org/code/
-- 
2.9.3


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 25/33] docs: input/sentelic: convert it to ReST format

[Mauro Carvalho Chehab]

This file has its own particular format that doesn't match any
markup one.

Manually change it to get something that would be readable
using ReST markup language.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/sentelic.txt | 1000 --
 1 file changed, 514 insertions(+), 486 deletions(-)

diff --git a/Documentation/input/sentelic.txt b/Documentation/input/sentelic.txt
index 89251e2a3eba..d1a476f973b1 100644
--- a/Documentation/input/sentelic.txt
+++ b/Documentation/input/sentelic.txt
@@ -1,411 +1,437 @@
-Copyright (C) 2002-2011 Sentelic Corporation.
-Last update: Dec-07-2011
+.. include:: 
+
+===
+Sentelic Driver
+===
+
+
+:Copyright: |copy| 2002-2011 Sentelic Corporation.
+
+:Last update: Dec-07-2011
+
+Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons)
+==
 
-==
-* Finger Sensing Pad Intellimouse Mode(scrolling wheel, 4th and 5th buttons)
-==
 A) MSID 4: Scrolling wheel mode plus Forward page(4th button) and Backward
page (5th button)
-@1. Set sample rate to 200;
-@2. Set sample rate to 200;
-@3. Set sample rate to 80;
-@4. Issuing the "Get device ID" command (0xF2) and waits for the response;
-@5. FSP will respond 0x04.
-
-Packet 1
-   Bit 7 6 5 4 3 2 1 0   7 6 5 4 3 2 1 0  7 6 5 4 3 2 1 0  7 6 5 4 
3 2 1 0
-BYTE  |---|BYTE 
|---|BYTE|---|BYTE|---|
-  1   |Y|X|y|x|1|M|R|L|  2  |X|X|X|X|X|X|X|X|  3 |Y|Y|Y|Y|Y|Y|Y|Y|  4 | | 
|B|F|W|W|W|W|
-  |---| |---||---|
|---|
-
-Byte 1: Bit7 => Y overflow
-Bit6 => X overflow
-Bit5 => Y sign bit
-Bit4 => X sign bit
-Bit3 => 1
-Bit2 => Middle Button, 1 is pressed, 0 is not pressed.
-Bit1 => Right Button, 1 is pressed, 0 is not pressed.
-Bit0 => Left Button, 1 is pressed, 0 is not pressed.
-Byte 2: X Movement(9-bit 2's complement integers)
-Byte 3: Y Movement(9-bit 2's complement integers)
-Byte 4: Bit3~Bit0 => the scrolling wheel's movement since the last data report.
- valid values, -8 ~ +7
-Bit4 => 1 = 4th mouse button is pressed, Forward one page.
-0 = 4th mouse button is not pressed.
-Bit5 => 1 = 5th mouse button is pressed, Backward one page.
-0 = 5th mouse button is not pressed.
-
-B) MSID 6: Horizontal and Vertical scrolling.
-@ Set bit 1 in register 0x40 to 1
-
-# FSP replaces scrolling wheel's movement as 4 bits to show horizontal and
-  vertical scrolling.
-
-Packet 1
-   Bit 7 6 5 4 3 2 1 0   7 6 5 4 3 2 1 0  7 6 5 4 3 2 1 0  7 6 5 4 
3 2 1 0
-BYTE  |---|BYTE 
|---|BYTE|---|BYTE|---|
-  1   |Y|X|y|x|1|M|R|L|  2  |X|X|X|X|X|X|X|X|  3 |Y|Y|Y|Y|Y|Y|Y|Y|  4 | | 
|B|F|r|l|u|d|
-  |---| |---||---|
|---|
-
-Byte 1: Bit7 => Y overflow
-Bit6 => X overflow
-Bit5 => Y sign bit
-Bit4 => X sign bit
-Bit3 => 1
-Bit2 => Middle Button, 1 is pressed, 0 is not pressed.
-Bit1 => Right Button, 1 is pressed, 0 is not pressed.
-Bit0 => Left Button, 1 is pressed, 0 is not pressed.
-Byte 2: X Movement(9-bit 2's complement integers)
-Byte 3: Y Movement(9-bit 2's complement integers)
-Byte 4: Bit0 => the Vertical scrolling movement downward.
-   Bit1 => the Vertical scrolling movement upward.
-   Bit2 => the Horizontal scrolling movement leftward.
-   Bit3 => the Horizontal scrolling movement rightward.
-Bit4 => 1 = 4th mouse button is pressed, Forward one page.
-0 = 4th mouse button is not pressed.
-Bit5 => 1 = 5th mouse button is pressed, Backward one page.
-0 = 5th mouse button is not pressed.
-
-C) MSID 7:
-# FSP uses 2 packets (8 Bytes) to represent Absolute Position.
-  so we have PACKET NUMBER to identify packets.
+
+1. Set sample rate to 200;
+2. Set sample rate to 200;
+3. Set sample rate to 80;
+4. Issuing the "Get device ID" command (0xF2) and waits for the response;
+5. FSP will respond 0x04.
+
+::
+
+Packet 1
+Bit 7 6 5 4 3 2 1 0   7 6 5 4 3 2 1 0  7 6 5 4 3 2 1 0  7 6 5 
4 3 2 1 0
+BYTE  |---|BYTE 
|---|BYTE|---|BYTE|---|
+  1   |Y|X|y|x|1|M|R|L|  2  |X|X|X|X|X|X|X|X|  3 |Y|Y|Y|Y|Y|Y|Y|Y|  4 | | 
|B|F|W|W|W|W|
+ |---| |---||---|
|---|
+
+Byte 1: Bit7 => Y overflow
+   Bit6 => X overflow
+   Bit5 => Y sign bit
+   Bit4 => X sign bit
+   Bit3 => 1
+   Bit2 => 

[PATCH v2 17/33] docs: input/input-programming: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/input-programming.txt | 253 +++---
 1 file changed, 128 insertions(+), 125 deletions(-)

diff --git a/Documentation/input/input-programming.txt 
b/Documentation/input/input-programming.txt
index 7f8b9d97bc47..4d3b2e93 100644
--- a/Documentation/input/input-programming.txt
+++ b/Documentation/input/input-programming.txt
@@ -1,77 +1,78 @@
+~
 Programming input drivers
 ~
 
-1. Creating an input device driver
-~~
+Creating an input device driver
+===
 
-1.0 The simplest example
-
+The simplest example
+
 
 Here comes a very simple example of an input device driver. The device has
 just one button and the button is accessible at i/o port BUTTON_PORT. When
-pressed or released a BUTTON_IRQ happens. The driver could look like:
-
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-static struct input_dev *button_dev;
-
-static irqreturn_t button_interrupt(int irq, void *dummy)
-{
-   input_report_key(button_dev, BTN_0, inb(BUTTON_PORT) & 1);
-   input_sync(button_dev);
-   return IRQ_HANDLED;
-}
-
-static int __init button_init(void)
-{
-   int error;
-
-   if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
-printk(KERN_ERR "button.c: Can't allocate irq %d\n", 
button_irq);
-return -EBUSY;
-}
-
-   button_dev = input_allocate_device();
-   if (!button_dev) {
-   printk(KERN_ERR "button.c: Not enough memory\n");
-   error = -ENOMEM;
-   goto err_free_irq;
-   }
-
-   button_dev->evbit[0] = BIT_MASK(EV_KEY);
-   button_dev->keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0);
-
-   error = input_register_device(button_dev);
-   if (error) {
-   printk(KERN_ERR "button.c: Failed to register device\n");
-   goto err_free_dev;
-   }
-
-   return 0;
-
- err_free_dev:
-   input_free_device(button_dev);
- err_free_irq:
-   free_irq(BUTTON_IRQ, button_interrupt);
-   return error;
-}
-
-static void __exit button_exit(void)
-{
-input_unregister_device(button_dev);
-   free_irq(BUTTON_IRQ, button_interrupt);
-}
-
-module_init(button_init);
-module_exit(button_exit);
-
-1.1 What the example does
-~
+pressed or released a BUTTON_IRQ happens. The driver could look like::
+
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct input_dev *button_dev;
+
+static irqreturn_t button_interrupt(int irq, void *dummy)
+{
+   input_report_key(button_dev, BTN_0, inb(BUTTON_PORT) & 1);
+   input_sync(button_dev);
+   return IRQ_HANDLED;
+}
+
+static int __init button_init(void)
+{
+   int error;
+
+   if (request_irq(BUTTON_IRQ, button_interrupt, 0, "button", NULL)) {
+   printk(KERN_ERR "button.c: Can't allocate irq %d\n", 
button_irq);
+   return -EBUSY;
+   }
+
+   button_dev = input_allocate_device();
+   if (!button_dev) {
+   printk(KERN_ERR "button.c: Not enough memory\n");
+   error = -ENOMEM;
+   goto err_free_irq;
+   }
+
+   button_dev->evbit[0] = BIT_MASK(EV_KEY);
+   button_dev->keybit[BIT_WORD(BTN_0)] = BIT_MASK(BTN_0);
+
+   error = input_register_device(button_dev);
+   if (error) {
+   printk(KERN_ERR "button.c: Failed to register device\n");
+   goto err_free_dev;
+   }
+
+   return 0;
+
+err_free_dev:
+   input_free_device(button_dev);
+err_free_irq:
+   free_irq(BUTTON_IRQ, button_interrupt);
+   return error;
+}
+
+static void __exit button_exit(void)
+{
+   input_unregister_device(button_dev);
+   free_irq(BUTTON_IRQ, button_interrupt);
+}
+
+module_init(button_init);
+module_exit(button_exit);
+
+What the example does
+~
 
 First it has to include the  file, which interfaces to the
 input subsystem. This provides all the definitions needed.
@@ -85,7 +86,7 @@ and sets up input bitfields. This way the device driver tells 
the other
 parts of the input systems what it is - what events can be generated or
 accepted by this input device. Our example device can only generate EV_KEY
 type events, and from those only BTN_0 event code. Thus we only set these
-two bits. We could have used
+two bits. We could have used::
 
set_bit(EV_KEY, button_dev.evbit);
set_bit(BTN_0, button_dev.keybit);
@@ -93,7 +94,7 @@ two bits. We could have used
 

[PATCH v2 15/33] docs: input/gpio-tilt: convert it to ReST format

[Mauro Carvalho Chehab]

This file require minimum adjustments to be a valid ReST file.
Do it, in order to be able to parse it with Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/gpio-tilt.txt | 124 +++---
 1 file changed, 62 insertions(+), 62 deletions(-)

diff --git a/Documentation/input/gpio-tilt.txt 
b/Documentation/input/gpio-tilt.txt
index 2cdfd9bcb1af..23de9eff6a34 100644
--- a/Documentation/input/gpio-tilt.txt
+++ b/Documentation/input/gpio-tilt.txt
@@ -28,76 +28,76 @@ Example:
 
 
 Example configuration for a single TS1003 tilt switch that rotates around
-one axis in 4 steps and emits the current tilt via two GPIOs.
+one axis in 4 steps and emits the current tilt via two GPIOs::
 
-static int sg060_tilt_enable(struct device *dev) {
-   /* code to enable the sensors */
-};
+static int sg060_tilt_enable(struct device *dev) {
+   /* code to enable the sensors */
+};
 
-static void sg060_tilt_disable(struct device *dev) {
-   /* code to disable the sensors */
-};
+static void sg060_tilt_disable(struct device *dev) {
+   /* code to disable the sensors */
+};
 
-static struct gpio sg060_tilt_gpios[] = {
-   { SG060_TILT_GPIO_SENSOR1, GPIOF_IN, "tilt_sensor1" },
-   { SG060_TILT_GPIO_SENSOR2, GPIOF_IN, "tilt_sensor2" },
-};
+static struct gpio sg060_tilt_gpios[] = {
+   { SG060_TILT_GPIO_SENSOR1, GPIOF_IN, "tilt_sensor1" },
+   { SG060_TILT_GPIO_SENSOR2, GPIOF_IN, "tilt_sensor2" },
+};
 
-static struct gpio_tilt_state sg060_tilt_states[] = {
-   {
-   .gpios = (0 << 1) | (0 << 0),
-   .axes = (int[]) {
-   0,
-   },
-   }, {
-   .gpios = (0 << 1) | (1 << 0),
-   .axes = (int[]) {
-   1, /* 90 degrees */
-   },
-   }, {
-   .gpios = (1 << 1) | (1 << 0),
-   .axes = (int[]) {
-   2, /* 180 degrees */
-   },
-   }, {
-   .gpios = (1 << 1) | (0 << 0),
-   .axes = (int[]) {
-   3, /* 270 degrees */
-   },
-   },
-};
+static struct gpio_tilt_state sg060_tilt_states[] = {
+   {
+   .gpios = (0 << 1) | (0 << 0),
+   .axes = (int[]) {
+   0,
+   },
+   }, {
+   .gpios = (0 << 1) | (1 << 0),
+   .axes = (int[]) {
+   1, /* 90 degrees */
+   },
+   }, {
+   .gpios = (1 << 1) | (1 << 0),
+   .axes = (int[]) {
+   2, /* 180 degrees */
+   },
+   }, {
+   .gpios = (1 << 1) | (0 << 0),
+   .axes = (int[]) {
+   3, /* 270 degrees */
+   },
+   },
+};
 
-static struct gpio_tilt_axis sg060_tilt_axes[] = {
-   {
-   .axis = ABS_RY,
-   .min = 0,
-   .max = 3,
-   .fuzz = 0,
-   .flat = 0,
-   },
-};
+static struct gpio_tilt_axis sg060_tilt_axes[] = {
+   {
+   .axis = ABS_RY,
+   .min = 0,
+   .max = 3,
+   .fuzz = 0,
+   .flat = 0,
+   },
+};
 
-static struct gpio_tilt_platform_data sg060_tilt_pdata= {
-   .gpios = sg060_tilt_gpios,
-   .nr_gpios = ARRAY_SIZE(sg060_tilt_gpios),
+static struct gpio_tilt_platform_data sg060_tilt_pdata= {
+   .gpios = sg060_tilt_gpios,
+   .nr_gpios = ARRAY_SIZE(sg060_tilt_gpios),
 
-   .axes = sg060_tilt_axes,
-   .nr_axes = ARRAY_SIZE(sg060_tilt_axes),
+   .axes = sg060_tilt_axes,
+   .nr_axes = ARRAY_SIZE(sg060_tilt_axes),
 
-   .states = sg060_tilt_states,
-   .nr_states = ARRAY_SIZE(sg060_tilt_states),
+   .states = sg060_tilt_states,
+   .nr_states = ARRAY_SIZE(sg060_tilt_states),
 
-   .debounce_interval = 100,
+   .debounce_interval = 100,
 
-   .poll_interval = 1000,
-   .enable = sg060_tilt_enable,
-   .disable = sg060_tilt_disable,
-};
+   .poll_interval = 1000,
+   .enable = sg060_tilt_enable,
+   .disable = sg060_tilt_disable,
+};
 
-static struct platform_device sg060_device_tilt = {
-   .name = "gpio-tilt-polled",
-   .id = -1,
-   .dev = {
-   .platform_data = _tilt_pdata,
-   },
-};
+static struct platform_device sg060_device_tilt = {
+   .name = "gpio-tilt-polled",
+   .id = -1,
+   .dev = {
+   .platform_data = _tilt_pdata,
+   },
+};
-- 
2.9.3


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info 

[PATCH v2 07/33] docs: input/cd32: convert it to ReST format

[Mauro Carvalho Chehab]

Currently, it misses a title, and the table is not valid for
ReST.

Adjust them, in order for it to be able to parse on Sphinx.

Signed-off-by: Mauro Carvalho Chehab 
---
 Documentation/input/cd32.txt | 28 
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/Documentation/input/cd32.txt b/Documentation/input/cd32.txt
index a003d9b41eca..2bffe0f33e5e 100644
--- a/Documentation/input/cd32.txt
+++ b/Documentation/input/cd32.txt
@@ -1,3 +1,7 @@
+==
+Amiga CD32
+==
+
 I have written a small patch that let's me use my Amiga CD32
 joypad connected to the parallel port. Thought I'd share it with you so
 you can add it to the list of supported joysticks (hopefully someone will
@@ -5,15 +9,15 @@ find it useful).
 
 It needs the following wiring:
 
-CD32 pad   |   Parallel port
-
-1 (Up) |2 (D0)
-2 (Down)   |3 (D1)
-3 (Left)   |4 (D2)
-4 (Right)  |5 (D3)
-5 (Fire3)  |   14 (AUTOFD)
-6 (Fire1)  |   17 (SELIN)
-7 (+5V)|1 (STROBE)
-8 (Gnd)|   18 (Gnd)
-9 (Fire2)  |7 (D5)
-
+====
+CD32 pad   Parallel port
+1 (Up)  2 (D0)
+2 (Down)3 (D1)
+3 (Left)4 (D2)
+4 (Right)   5 (D3)
+5 (Fire3)  14 (AUTOFD)
+6 (Fire1)  17 (SELIN)
+7 (+5V) 1 (STROBE)
+8 (Gnd)18 (Gnd)
+9 (Fire2)   7 (D5)
+====
-- 
2.9.3


--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] tracing/kprobes: expose maxactive for kretprobe in kprobe_events

[Masami Hiramatsu]

On Mon,  3 Apr 2017 12:36:22 +0200
Alban Crequy  wrote:

> From: Alban Crequy 
> 
> When a kretprobe is installed on a kernel function, there is a maximum
> limit of how many calls in parallel it can catch (aka "maxactive"). A
> kernel module could call register_kretprobe() and initialize maxactive
> (see example in samples/kprobes/kretprobe_example.c).
> 
> But that is not exposed to userspace and it is currently not possible to
> choose maxactive when writing to /sys/kernel/debug/tracing/kprobe_events
> 
> The default maxactive can be as low as 1 on single-core with a
> non-preemptive kernel. This is too low and we need to increase it not
> only for recursive functions, but for functions that sleep or resched.
> 
> This patch updates the format of the command that can be written to
> kprobe_events so that maxactive can be optionally specified.
> 
> I need this for a bpf program attached to the kretprobe of
> inet_csk_accept, which can sleep for a long time.
> 
> This patch includes a basic selftest:
> 
> > # ./ftracetest -v  test.d/kprobe/
> > === Ftrace unit tests ===
> > [1] Kprobe dynamic event - adding and removing  [PASS]
> > [2] Kprobe dynamic event - busy event check [PASS]
> > [3] Kprobe dynamic event with arguments [PASS]
> > [4] Kprobes event arguments with types  [PASS]
> > [5] Kprobe dynamic event with function tracer   [PASS]
> > [6] Kretprobe dynamic event with arguments  [PASS]
> > [7] Kretprobe dynamic event with maxactive  [PASS]
> >
> > # of passed:  7
> > # of failed:  0
> > # of unresolved:  0
> > # of untested:  0
> > # of unsupported:  0
> > # of xfailed:  0
> > # of undefined(test bug):  0
> 
> BugLink: https://github.com/iovisor/bcc/issues/1072
> Signed-off-by: Alban Crequy 

Looks good to me.

Acked-by: Masami Hiramatsu 

Thanks!

> 
> ---
> 
> Changes since v2:
> - Explain the default maxactive value in the documentation.
>   (Review from Steven Rostedt)
> 
> Changes since v1:
> - Remove "(*)" from documentation. (Review from Masami Hiramatsu)
> - Fix support for "r100" without the event name (Review from Masami Hiramatsu)
> - Get rid of magic numbers within the code.  (Review from Steven Rostedt)
>   Note that I didn't use KRETPROBE_MAXACTIVE_ALLOC since that patch is not
>   merged.
> - Return -E2BIG when maxactive is too big.
> - Add basic selftest
> ---
>  Documentation/trace/kprobetrace.txt|  5 ++-
>  kernel/trace/trace_kprobe.c| 39 
> ++
>  .../ftrace/test.d/kprobe/kretprobe_maxactive.tc| 39 
> ++
>  3 files changed, 76 insertions(+), 7 deletions(-)
>  create mode 100644 
> tools/testing/selftests/ftrace/test.d/kprobe/kretprobe_maxactive.tc
> 
> diff --git a/Documentation/trace/kprobetrace.txt 
> b/Documentation/trace/kprobetrace.txt
> index 41ef9d8..25f3960 100644
> --- a/Documentation/trace/kprobetrace.txt
> +++ b/Documentation/trace/kprobetrace.txt
> @@ -23,7 +23,7 @@ current_tracer. Instead of that, add probe points via
>  Synopsis of kprobe_events
>  -
>p[:[GRP/]EVENT] [MOD:]SYM[+offs]|MEMADDR [FETCHARGS]   : Set a probe
> -  r[:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS]  : Set a return probe
> +  r[MAXACTIVE][:[GRP/]EVENT] [MOD:]SYM[+0] [FETCHARGS]   : Set a return 
> probe
>-:[GRP/]EVENT  : Clear a probe
>  
>   GRP : Group name. If omitted, use "kprobes" for it.
> @@ -32,6 +32,9 @@ Synopsis of kprobe_events
>   MOD : Module name which has given SYM.
>   SYM[+offs]  : Symbol+offset where the probe is inserted.
>   MEMADDR : Address where the probe is inserted.
> + MAXACTIVE   : Maximum number of instances of the specified function that
> +   can be probed simultaneously, or 0 for the default value
> +   as defined in Documentation/kprobes.txt section 1.3.1.
>  
>   FETCHARGS   : Arguments. Each probe can have up to 128 args.
>%REG   : Fetch register REG
> diff --git a/kernel/trace/trace_kprobe.c b/kernel/trace/trace_kprobe.c
> index c5089c7..ae81f3c 100644
> --- a/kernel/trace/trace_kprobe.c
> +++ b/kernel/trace/trace_kprobe.c
> @@ -25,6 +25,7 @@
>  #include "trace_probe.h"
>  
>  #define KPROBE_EVENT_SYSTEM "kprobes"
> +#define KRETPROBE_MAXACTIVE_MAX 4096
>  
>  /**
>   * Kprobe event core functions
> @@ -282,6 +283,7 @@ static struct trace_kprobe *alloc_trace_kprobe(const char 
> *group,
>void *addr,
>const char *symbol,
>unsigned long offs,
> +  int maxactive,
>int nargs, bool is_return)
>  {
>   struct trace_kprobe *tk;
> @@ -309,6 +311,8 @@ static struct trace_kprobe *alloc_trace_kprobe(const char 
> *group,
>   else

[PATCH v7 4/9] Documentation: perf: hisi: Documentation for HiP05/06/07 PMU event counting.

[Anurup M]

Documentation for perf usage and Hisilicon SoC PMU uncore events.
The Hisilicon SOC has event counters for hardware modules like
L3 cache, Miscellaneous node etc. These events are all uncore.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
---
 Documentation/perf/hisi-pmu.txt | 75 +
 1 file changed, 75 insertions(+)
 create mode 100644 Documentation/perf/hisi-pmu.txt

diff --git a/Documentation/perf/hisi-pmu.txt b/Documentation/perf/hisi-pmu.txt
new file mode 100644
index 000..a21571d
--- /dev/null
+++ b/Documentation/perf/hisi-pmu.txt
@@ -0,0 +1,75 @@
+Hisilicon SoC PMU (Performance Monitoring Unit)
+
+The Hisilicon SoC HiP05/06/07 chips consist of various independent system
+device PMU's such as L3 cache(L3C) and Miscellaneous Nodes(MN).
+These PMU devices are independent and have hardware logic to gather
+statistics and performance information.
+
+HiP0x chips are encapsulated by multiple CPU and IO dies. The CPU die is
+called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
+is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
+Each SCCL has 1 L3 cache and 1 MN units.
+
+The L3 cache is shared by all CPU cores in a CPU die. The L3C has four banks
+(or instances). Each bank or instance of L3C has Eight 32-bit counter
+registers and also event control registers. The HiP05/06 chip L3 cache has
+22 statistics events. The HiP07 chip has 66 statistics events. These events
+are very useful for debugging.
+
+The MN module is also shared by all CPU cores in a CPU die. It receives
+barriers and DVM(Distributed Virtual Memory) messages from cpu or smmu, and
+perform the required actions and return response messages. These events are
+very useful for debugging. The MN has total 9 statistics events and support
+four 32-bit counter registers in HiP05/06/07 chips.
+
+There is no memory mapping for L3 cache and MN registers. It can be accessed
+by using the Hisilicon djtag interface. The Djtag in a SCCL is an independent
+module which connects with some modules in the SoC by Debug Bus.
+
+Hisilicon SoC (HiP05/06/07) PMU driver
+--
+The HiP0x PMU driver shall register perf PMU drivers like L3 cache, MN etc.
+The available events and configuration options shall be described in the sysfs.
+The "perf list" shall list the available events from sysfs.
+
+The L3 cache in a SCCL is divided as 4 banks. Each L3 cache bank have separate
+PMU registers for event counting and control. The L3 cache banks also do not
+have any CPU affinity. So each L3 cache banks are registered with perf as a
+separate PMU.
+The PMU name will appear in event listing as hisi_l3c_.
+where "bank-id" is the bank index (0 to 3) and "scl-id" is the SCCL identifier
+e.g. hisi_l3c0_2/read_hit is READ_HIT event of L3 cache bank #0 SCCL ID #2.
+
+The MN in a SCCL is registered as a separate PMU with perf.
+The PMU name will appear in event listing as hisi_mn_.
+e.g. hisi_mn_2/read_req. READ_REQUEST event of MN of Super CPU cluster #2.
+
+The event code is represented by 8 bits.
+   i) event 0-7
+   The event code will be represented using the LSB 8 bits.
+
+The driver also provides a "cpumask" sysfs attribute, which shows the CPU core
+ID used to count the uncore PMU event.
+
+Example usage of perf:
+$# perf list
+hisi_l3c0_2/read_hit/ [kernel PMU event]
+--
+hisi_l3c1_2/write_hit/ [kernel PMU event]
+--
+hisi_l3c0_1/read_hit/ [kernel PMU event]
+--
+hisi_l3c0_1/write_hit/ [kernel PMU event]
+--
+hisi_mn_2/read_req/ [kernel PMU event]
+hisi_mn_2/write_req/ [kernel PMU event]
+--
+
+$# perf stat -a -e "hisi_l3c0_2/read_allocate/" sleep 5
+$# perf stat -A -C 0 -e "hisi_l3c0_2/read_allocate/" sleep 5
+
+The current driver does not support sampling. So "perf record" is unsupported.
+Also attach to a task is unsupported as the events are all uncore.
+
+Note: Please contact the maintainer for a complete list of events supported for
+the PMU devices in the SoC and its information if needed.
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 5/6] drm: bridge: dw-hdmi: Add Documentation on supported input formats

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Monday 03 Apr 2017 16:42:37 Neil Armstrong wrote:
> This patch adds a new DRM documentation entry and links to the input
> format table added in the dw_hdmi header.
> 
> Reviewed-by: Archit Taneja 
> Signed-off-by: Neil Armstrong 

Acked-by: Laurent Pinchart 

> ---
>  Documentation/gpu/bridge/dw-hdmi.rst | 15 +++
>  Documentation/gpu/index.rst  |  1 +
>  2 files changed, 16 insertions(+)
>  create mode 100644 Documentation/gpu/bridge/dw-hdmi.rst
> 
> diff --git a/Documentation/gpu/bridge/dw-hdmi.rst
> b/Documentation/gpu/bridge/dw-hdmi.rst new file mode 100644
> index 000..486faad
> --- /dev/null
> +++ b/Documentation/gpu/bridge/dw-hdmi.rst
> @@ -0,0 +1,15 @@
> +===
> + drm/bridge/dw-hdmi Synopsys DesignWare HDMI Controller
> +===
> +
> +Synopsys DesignWare HDMI Controller
> +===
> +
> +This section covers everything related to the Synopsys DesignWare HDMI
> +Controller implemented as a DRM bridge.
> +
> +Supported Input Formats and Encodings
> +-
> +
> +.. kernel-doc:: include/drm/bridge/dw_hdmi.h
> +   :doc: Supported input formats and encodings
> diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst
> index e998ee0..d81c6ff 100644
> --- a/Documentation/gpu/index.rst
> +++ b/Documentation/gpu/index.rst
> @@ -15,6 +15,7 @@ Linux GPU Driver Developer's Guide
> vc4
> vga-switcheroo
> vgaarbiter
> +   bridge/dw-hdmi
> todo
> 
>  .. only::  subproject and html

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Monday 03 Apr 2017 16:42:36 Neil Armstrong wrote:
> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
> Controller, this patch takes the pixel format from the plat_data if
> provided.

The commit message doesn't seem to match the subject line.

> Reviewed-by: Jose Abreu 
> Reviewed-by: Archit Taneja 
> Signed-off-by: Neil Armstrong 
> ---
>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 326 +++
>  include/drm/bridge/dw_hdmi.h  |  63 ++
>  2 files changed, 294 insertions(+), 95 deletions(-)

[snip]

> diff --git a/include/drm/bridge/dw_hdmi.h b/include/drm/bridge/dw_hdmi.h
> index bcceee8..45c2c15 100644
> --- a/include/drm/bridge/dw_hdmi.h
> +++ b/include/drm/bridge/dw_hdmi.h
> @@ -14,6 +14,67 @@
>  
>  struct dw_hdmi;
>  
> +/**
> + * DOC: Supported input formats and encodings
> + *
> + * Depending on the Hardware configuration of the Controller IP, it
> supports
> + * a subset of the following input formats and encodings on it's internal
> + * 48bit bus.
> + *

s/it's/its/

[snip]

Apart from that,

Reviewed-by: Laurent Pinchart 

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v6 3/6] documentation: media: Add documentation for new RGB and YUV bus formats

[Laurent Pinchart]

Hi Neil,

Thank you for the patch.

On Monday 03 Apr 2017 16:42:35 Neil Armstrong wrote:
> Add documentation for added Bus Formats to describe RGB and YUV formats used
> as input to the Synopsys DesignWare HDMI TX Controller.
> 
> Acked-by: Hans Verkuil 
> Reviewed-by: Archit Taneja 
> Acked-by: Mauro Carvalho Chehab 
> Signed-off-by: Neil Armstrong 
> ---
>  Documentation/media/uapi/v4l/subdev-formats.rst | 960 -
>  1 file changed, 959 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/media/uapi/v4l/subdev-formats.rst
> b/Documentation/media/uapi/v4l/subdev-formats.rst index d6152c9..4032d97
> 100644
> --- a/Documentation/media/uapi/v4l/subdev-formats.rst
> +++ b/Documentation/media/uapi/v4l/subdev-formats.rst
> @@ -1258,6 +1258,319 @@ The following tables list existing packed RGB
> formats. - b\ :sub:`2`
>- b\ :sub:`1`
>- b\ :sub:`0`
> +* .. _MEDIA-BUS-FMT-RGB101010-1X30:
> +
> +  - MEDIA_BUS_FMT_RGB101010_1X30
> +  - 0x1018
> +  -
> +  - 0
> +  - 0
> +  - r\ :sub:`9`
> +  - r\ :sub:`8`
> +  - r\ :sub:`7`
> +  - r\ :sub:`6`
> +  - r\ :sub:`5`
> +  - r\ :sub:`4`
> +  - r\ :sub:`3`
> +  - r\ :sub:`2`
> +  - r\ :sub:`1`
> +  - r\ :sub:`0`
> +  - g\ :sub:`9`
> +  - g\ :sub:`8`
> +  - g\ :sub:`7`
> +  - g\ :sub:`6`
> +  - g\ :sub:`5`
> +  - g\ :sub:`4`
> +  - g\ :sub:`3`
> +  - g\ :sub:`2`
> +  - g\ :sub:`1`
> +  - g\ :sub:`0`
> +  - b\ :sub:`9`
> +  - b\ :sub:`8`
> +  - b\ :sub:`7`
> +  - b\ :sub:`6`
> +  - b\ :sub:`5`
> +  - b\ :sub:`4`
> +  - b\ :sub:`3`
> +  - b\ :sub:`2`
> +  - b\ :sub:`1`
> +  - b\ :sub:`0`
> +
> +.. raw:: latex
> +
> +\endgroup
> +
> +
> +The following table list existing packed 36bit wide RGB formats.

s/list/lists/

Same comment for the other tables. Apart from that,

Reviewed-by: Laurent Pinchart 

[snip]

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] Documentation/sphinx: kerneldoc: add "unused-functions"

[Jani Nikula]

On Mon, 03 Apr 2017, Johannes Berg  wrote:
> On Fri, 2017-03-31 at 15:54 +0300, Jani Nikula wrote:
>> 
>> I'm sure the parameter name could be improved to capture what you
>> mean better; alas I don't have a suggestion.
>
> Yes, that's a fair point - perhaps "functions-not-linked" or something
> like that.
>
>> > Internally this works by collecting (per-file) those functions
>> > (and enums, structs, doc sections...) that are explicitly used,
>> > and invoking the kernel-doc script with "-nofunction" later.
>> 
>> A quick thought that I don't have the time to check now, but should
>> be checked before merging: Is the order of directive extension
>> execution deterministic if the Sphinx run is parallelized (sphinx-
>> build -j)? Is it deterministic within an rst file? Surely it's not
>> deterministic when called from several rst files? The latter is,
>> perhaps, acceptable, but the former not.
>
> Interesting, TBH I never even considered this. How would I even run it
> that way? Presumably "make htmldocs" doesn't do this?

Try 'make SPHINXOPTS=-j8 htmldocs'.

>
> Sphinx documentation (http://www.sphinx-doc.org/en/stable/extdev/) says
> this:
>
> The setup() function can return a dictionary. This is treated by
> Sphinx as metadata of the extension. Metadata keys currently
> recognized are:
> [...]
> 'parallel_read_safe': a boolean that specifies if parallel reading
> of source files can be used when the extension is loaded. It
> defaults to False, i.e. you have to explicitly specify your
> extension to be parallel-read-safe after checking that it is.
>
> We do set this right now, so I guess it'd only be guaranteed to work
> right within a single rst file, and then I should perhaps consider not
> making this state global but somehow linking it to the rst file being
> processed?

Perhaps, but does that defeat the purpose then?

BR,
Jani.

>
> johannes
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html