Commit 1004689c authored by Greg Kroah-Hartman's avatar Greg Kroah-Hartman
Browse files

Merge tag 'iio-for-3.7c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into work-next 

Third set of IIO rework and new drivers for the 3.7 cycle.

This set includes:

1) HID sensor drivers. This includes a core elements in the
HID subsystem merged through the IIO tree because we have some
ABI changes outstanding (some in this set) which will effect them.
The HID sensors specification covers an extremely wide range of
sensors so we will probably be seeing lots more elements of this
as the hardware hits the market.

2) Some general abi cleanups to use the utility function
iio_push_to_buffer and to drop the used timestamp parameter
from the same call.  For a long time timestamps have taken
the same path as all other channel types into the buffers so
it is good to clean this out.

3) More ADC driver support for Analog Devices parts in the form
of one new driver and some additional supported parts via current
drivers.

4) An increase to the accuracy of the calibration scale for
the isl29018 driver.

So a mixed bag, but all good additions to IIO.
parents a7e46d8b 932323b7

Documentation/hid/hid-sensor.txt

0 → 100755
+140 −0
Original line number Diff line number Diff line 


HID Sensors Framework

======================

HID sensor framework provides necessary interfaces to implement sensor drivers,

which are connected to a sensor hub. The sensor hub is a HID device and it provides

a report descriptor conforming to HID 1.12 sensor usage tables.



Description from the HID 1.12 "HID Sensor Usages" specification:

"Standardization of HID usages for sensors would allow (but not require) sensor

hardware vendors to provide a consistent Plug And Play interface at the USB boundary,

thereby enabling some operating systems to incorporate common device drivers that

could be reused between vendors, alleviating any need for the vendors to provide

the drivers themselves."



This specification describes many usage IDs, which describe the type of sensor

and also the individual data fields. Each sensor can have variable number of

data fields. The length and order is specified in the report descriptor. For

example a part of report descriptor can look like:



   INPUT(1)[INPUT]

 ..

    Field(2)

      Physical(0020.0073)

      Usage(1)

        0020.045f

      Logical Minimum(-32767)

      Logical Maximum(32767)

      Report Size(8)

      Report Count(1)

      Report Offset(16)

      Flags(Variable Absolute)

..

..



The report is indicating "sensor page (0x20)" contains an accelerometer-3D (0x73).

This accelerometer-3D has some fields. Here for example field 2 is motion intensity

(0x045f) with a logical minimum value of -32767 and logical maximum of 32767. The

order of fields and length of each field is important as the input event raw

data will use this format.





Implementation

=================



This specification defines many different types of sensors with different sets of

data fields. It is difficult to have a common input event to user space applications,

for different sensors. For example an accelerometer can send X,Y and Z data, whereas

an ambient light sensor can send illumination data.

So the implementation has two parts:

- Core hid driver

- Individual sensor processing part (sensor drivers)



Core driver

-----------

The core driver registers (hid-sensor-hub) registers as a HID driver. It parses

report descriptors and identifies all the sensors present. It adds an MFD device

with name HID-SENSOR-xxxx (where xxxx is usage id from the specification).

For example

HID-SENSOR-200073 is registered for an Accelerometer 3D driver.

So if any driver with this name is inserted, then the probe routine for that

function will be called. So an accelerometer processing driver can register

with this name and will be probed if there is an accelerometer-3D detected.



The core driver provides a set of APIs which can be used by the processing

drivers to register and get events for that usage id. Also it provides parsing

functions, which get and set each input/feature/output report.



Individual sensor processing part (sensor drivers)

-----------

The processing driver will use an interface provided by the core driver to parse

the report and get the indexes of the fields and also can get events. This driver

can use IIO interface to use the standard ABI defined for a type of sensor.





Core driver Interface

=====================



Callback structure:

Each processing driver can use this structure to set some callbacks.

	int (*suspend)(..): Callback when HID suspend is received

	int (*resume)(..): Callback when HID resume is received

	int (*capture_sample)(..): Capture a sample for one of its data fields

	int (*send_event)(..): One complete event is received which can have

                               multiple data fields.



Registration functions:

int sensor_hub_register_callback(struct hid_sensor_hub_device *hsdev,

			u32 usage_id,

			struct hid_sensor_hub_callbacks *usage_callback):



Registers callbacks for an usage id. The callback functions are not allowed

to sleep.





int sensor_hub_remove_callback(struct hid_sensor_hub_device *hsdev,

			u32 usage_id):



Removes callbacks for an usage id.





Parsing function:

int sensor_hub_input_get_attribute_info(struct hid_sensor_hub_device *hsdev,

			u8 type,

			u32 usage_id, u32 attr_usage_id,

			struct hid_sensor_hub_attribute_info *info);



A processing driver can look for some field of interest and check if it exists

in a report descriptor. If it exists it will store necessary information

so that fields can be set or get individually.

These indexes avoid searching every time and getting field index to get or set.





Set Feature report

int sensor_hub_set_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,

			u32 field_index, s32 value);



This interface is used to set a value for a field in feature report. For example

if there is a field report_interval, which is parsed by a call to

sensor_hub_input_get_attribute_info before, then it can directly set that individual

field.





int sensor_hub_get_feature(struct hid_sensor_hub_device *hsdev, u32 report_id,

			u32 field_index, s32 *value);



This interface is used to get a value for a field in input report. For example

if there is a field report_interval, which is parsed by a call to

sensor_hub_input_get_attribute_info before, then it can directly get that individual

field value.





int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,

			u32 usage_id,

			u32 attr_usage_id, u32 report_id);



This is used to get a particular field value through input reports. For example

accelerometer wants to poll X axis value, then it can call this function with

the usage id of X axis. HID sensors can provide events, so this is not necessary

to poll for any field. If there is some new sample, the core driver will call

registered callback function to process the sample.

drivers/hid/Kconfig

+14 −0
Original line number Diff line number Diff line
@@ -690,6 +690,20 @@ config HID_ZYDACRON 
	---help---

	Support for Zydacron remote control.



config HID_SENSOR_HUB

	tristate "HID Sensors framework support"

	depends on USB_HID

	select MFD_CORE

	default n

	-- help---

	  Support for HID Sensor framework. This creates a MFD instance

	  for a sensor hub and identifies all the sensors connected to it.

	  Each sensor is registered as a MFD cell, so that sensor specific

	  processing can be done in a separate driver. Each sensor

	  drivers can use the service provided by this driver to register

	  for events and handle data streams. Each sensor driver can format

	  data and present to user mode using input or IIO interface.



endmenu



endif # HID

drivers/hid/Makefile

+1 −0
Original line number Diff line number Diff line
@@ -91,6 +91,7 @@ obj-$(CONFIG_HID_ZYDACRON) += hid-zydacron.o 
obj-$(CONFIG_HID_WACOM)		+= hid-wacom.o

obj-$(CONFIG_HID_WALTOP)	+= hid-waltop.o

obj-$(CONFIG_HID_WIIMOTE)	+= hid-wiimote.o

obj-$(CONFIG_HID_SENSOR_HUB)	+= hid-sensor-hub.o



obj-$(CONFIG_USB_HID)		+= usbhid/

obj-$(CONFIG_USB_MOUSE)		+= usbhid/

drivers/hid/hid-core.c

+5 −0
Original line number Diff line number Diff line
@@ -1550,6 +1550,10 @@ static const struct hid_device_id hid_have_special_driver[] = { 
	{ HID_USB_DEVICE(USB_VENDOR_ID_GYRATION, USB_DEVICE_ID_GYRATION_REMOTE_3) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK, USB_DEVICE_ID_HOLTEK_ON_LINE_GRIP) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_HOLTEK_ALT, USB_DEVICE_ID_HOLTEK_ALT_KEYBOARD) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8086, USB_DEVICE_ID_SENSOR_HUB_1020) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8086, USB_DEVICE_ID_SENSOR_HUB_09FA) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8087, USB_DEVICE_ID_SENSOR_HUB_1020) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_INTEL_8087, USB_DEVICE_ID_SENSOR_HUB_09FA) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_KEYTOUCH, USB_DEVICE_ID_KEYTOUCH_IEC) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
@@ -1642,6 +1646,7 @@ static const struct hid_device_id hid_have_special_driver[] = { 
	{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_PS3_CONTROLLER) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_SONY, USB_DEVICE_ID_SONY_VAIO_VGX_MOUSE) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_SUNPLUS, USB_DEVICE_ID_SUNPLUS_WDESKTOP) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_STANTUM_STM, USB_DEVICE_ID_SENSOR_HUB_7014) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb300) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb304) },

	{ HID_USB_DEVICE(USB_VENDOR_ID_THRUSTMASTER, 0xb323) },

drivers/hid/hid-ids.h

+6 −0
Original line number Diff line number Diff line
@@ -419,6 +419,11 @@ 
#define USB_VENDOR_ID_IMATION		0x0718

#define USB_DEVICE_ID_DISC_STAKKA	0xd000



#define USB_VENDOR_ID_INTEL_8086	0x8086

#define USB_VENDOR_ID_INTEL_8087	0x8087

#define USB_DEVICE_ID_SENSOR_HUB_1020	0x1020

#define USB_DEVICE_ID_SENSOR_HUB_09FA	0x09FA



#define USB_VENDOR_ID_IRTOUCHSYSTEMS	0x6615

#define USB_DEVICE_ID_IRTOUCH_INFRARED_USB	0x0070
@@ -695,6 +700,7 @@ 


#define USB_VENDOR_ID_STANTUM_STM		0x0483

#define USB_DEVICE_ID_MTP_STM		0x3261

#define USB_DEVICE_ID_SENSOR_HUB_7014	0x7014



#define USB_VENDOR_ID_STANTUM_SITRONIX		0x1403

#define USB_DEVICE_ID_MTP_SITRONIX		0x5001

CRA Git | Maintained and supported by SUSTech CRA and CCSE