AcoSail/kernel_optimize_test
8
0
Fork 0
forked from luck/tmp_suning_uos_patched
Code Pull Requests Activity
3b5f03c4e3
kernel_optimize_test/drivers/hid/hid-wiimote.h

323 lines
8.2 KiB
C
Raw Normal View History

HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
#ifndef __HID_WIIMOTE_H
#define __HID_WIIMOTE_H
/*
HID: wiimote: extend driver description The hid-wiimote driver supports more than the Wii Remote. Nintendo produced many devices based on the Wii Remote, which have extension devices built-in. It is not clear to many users, that these devices have anything in common with the Wii Remote, so fix the driver description. This also updates the copyright information for the coming hotplugging rework. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:45 +08:00
* HID driver for Nintendo Wii / Wii U peripherals
* Copyright (c) 2011-2013 David Herrmann <dh.herrmann@gmail.com>
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
*/
/*
* 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.
*/
#include <linux/completion.h>
#include <linux/device.h>
#include <linux/hid.h>
#include <linux/input.h>
#include <linux/leds.h>
#include <linux/module.h>
#include <linux/mutex.h>
#include <linux/power_supply.h>
#include <linux/spinlock.h>
#define WIIMOTE_NAME "Nintendo Wii Remote"
#define WIIMOTE_BUFSIZE 32
#define WIIPROTO_FLAG_LED1 0x01
#define WIIPROTO_FLAG_LED2 0x02
#define WIIPROTO_FLAG_LED3 0x04
#define WIIPROTO_FLAG_LED4 0x08
#define WIIPROTO_FLAG_RUMBLE 0x10
#define WIIPROTO_FLAG_ACCEL 0x20
#define WIIPROTO_FLAG_IR_BASIC 0x40
#define WIIPROTO_FLAG_IR_EXT 0x80
#define WIIPROTO_FLAG_IR_FULL 0xc0 /* IR_BASIC | IR_EXT */
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
#define WIIPROTO_FLAG_EXT_PLUGGED 0x0100
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
#define WIIPROTO_FLAGS_LEDS (WIIPROTO_FLAG_LED1 | WIIPROTO_FLAG_LED2 | \
WIIPROTO_FLAG_LED3 | WIIPROTO_FLAG_LED4)
#define WIIPROTO_FLAGS_IR (WIIPROTO_FLAG_IR_BASIC | WIIPROTO_FLAG_IR_EXT | \
WIIPROTO_FLAG_IR_FULL)
/* return flag for led \num */
#define WIIPROTO_FLAG_LED(num) (WIIPROTO_FLAG_LED1 << (num - 1))
HID: wiimote: convert KEYS and RUMBLE to modules This introduces the first sub-device modules by converting the KEYS and RUMBLE sub-devices into wiimote modules. Both must be converted at once because they depend on the built-in shared input device. This mostly moves code from wiimote-core to wiimote-modules and doesn't change any semantics or ABI. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:52 +08:00
enum wiiproto_keys {
WIIPROTO_KEY_LEFT,
WIIPROTO_KEY_RIGHT,
WIIPROTO_KEY_UP,
WIIPROTO_KEY_DOWN,
WIIPROTO_KEY_PLUS,
WIIPROTO_KEY_MINUS,
WIIPROTO_KEY_ONE,
WIIPROTO_KEY_TWO,
WIIPROTO_KEY_A,
WIIPROTO_KEY_B,
WIIPROTO_KEY_HOME,
WIIPROTO_KEY_COUNT
};
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
enum wiimote_devtype {
WIIMOTE_DEV_PENDING,
WIIMOTE_DEV_UNKNOWN,
WIIMOTE_DEV_GENERIC,
WIIMOTE_DEV_GEN10,
WIIMOTE_DEV_GEN20,
WIIMOTE_DEV_NUM,
};
enum wiimote_exttype {
WIIMOTE_EXT_NONE,
WIIMOTE_EXT_UNKNOWN,
WIIMOTE_EXT_NUM,
};
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
struct wiimote_buf {
__u8 data[HID_MAX_BUFFER_SIZE];
size_t size;
};
HID: wiimote: move queue handling into separate struct The output queue is independent of the other wiimote modules and can run on its own. Therefore, move its members into a separate struct so we don't run into name collisions with other modules. This is only a syntactic change that renames all queue members to queue.*. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:46 +08:00
struct wiimote_queue {
spinlock_t lock;
struct work_struct worker;
__u8 head;
__u8 tail;
struct wiimote_buf outq[WIIMOTE_BUFSIZE];
};
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
struct wiimote_state {
spinlock_t lock;
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
__u32 flags;
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
__u8 accel_split[2];
HID: wiimote: Allow direct DRM debug access Keep track of current drm and add new debugfs file which reads or writes the current DRM. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:12 +08:00
__u8 drm;
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
__u8 devtype;
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
/* synchronous cmd requests */
struct mutex sync;
struct completion ready;
int cmd;
__u32 opt;
/* results of synchronous requests */
__u8 cmd_battery;
__u8 cmd_err;
HID: wiimote: Add read-mem helpers Add helper functions similar to the write-mem helpers but for reading wiimote memory and eeprom. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:00 +08:00
__u8 *cmd_read_buf;
__u8 cmd_read_size;
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
};
struct wiimote_data {
struct hid_device *hdev;
struct input_dev *input;
struct led_classdev *leds[4];
struct input_dev *accel;
struct input_dev *ir;
struct power_supply battery;
HID: wiimote: Add extension support stub The wiimote supports several extensions. This adds a separate source file which handles all extensions and can be disabled at compile-time. The driver reacts on "plug"-events on the extension port and starts a worker which initializes or deinitializes the extensions. Currently, the initialization logic is not fully understood and we can only detect and enable all extensions when all extensions are deactivated. Therefore, we need to disable all extensions, then detect and activate them again to react on "plug"-events. However, deactivating extensions will generate a new "plug"-event and we will never leave that loop. Hence, we only support extensions if they are plugged before the wiimote is connected (or before the ext-input device is opened). In the future we may support full extension hotplug support, but reverse-engineering this may take a while. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:01 +08:00
struct wiimote_ext *ext;
HID: wiimote: Add debugfs support stubs Add initializer and deinitializer for debugfs support. This will later allow raw eeprom access and direct DRM modifications to debug wiimote behaviour and further protocol reverse-engineerings. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:10 +08:00
struct wiimote_debug *debug;
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
HID: wiimote: move queue handling into separate struct The output queue is independent of the other wiimote modules and can run on its own. Therefore, move its members into a separate struct so we don't run into name collisions with other modules. This is only a syntactic change that renames all queue members to queue.*. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:46 +08:00
struct wiimote_queue queue;
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
struct wiimote_state state;
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
struct work_struct init_worker;
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
};
HID: wiimote: add sub-device module infrastructure To avoid loading all sub-device drivers for every Wii Remote, even though the required hardware might not be available, we introduce a module layer. The module layer specifies which sub-devices are available on each device-type. After device detection, we only load the modules for the detected device. If module loading fails, we unload everything and mark the device as WIIMOTE_DEV_UNKNOWN. As long as a device is marked as "unknown", no sub-devices will be used and the device is considered unsupported. All the different sub-devices, including KEYS, RUMBLE, BATTERY, LEDS, ACCELEROMETER, IR and more will be ported in follow-up patches to the new module layer. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:51 +08:00
/* wiimote modules */
enum wiimod_module {
HID: wiimote: convert KEYS and RUMBLE to modules This introduces the first sub-device modules by converting the KEYS and RUMBLE sub-devices into wiimote modules. Both must be converted at once because they depend on the built-in shared input device. This mostly moves code from wiimote-core to wiimote-modules and doesn't change any semantics or ABI. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:52 +08:00
WIIMOD_KEYS,
WIIMOD_RUMBLE,
HID: wiimote: convert BATTERY to module This introduces a new sub-device module for the BATTERY handlers. It moves the whole power_supply battery handling over to wiimote-modules. This doesn't change any semantics or ABI but only converts the battery handling into a sub-device module. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:53 +08:00
WIIMOD_BATTERY,
HID: wiimote: convert LEDS to modules Each of the 4 LEDs may be supported individually by devices. Therefore, we need one module for each device. To avoid code-duplication, we simply pass the LED ID as "arg" argument to the module loading code. This just moves the code over to wiimote-module. The semantics stay the same as before. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:54 +08:00
WIIMOD_LED1,
WIIMOD_LED2,
WIIMOD_LED3,
WIIMOD_LED4,
HID: wiimote: convert ACCEL to module Accelerometer data is very similar to KEYS handling. Therefore, convert all ACCEL related handling into a sub-device module similar to KEYS. This doesn't change any semantics but only moves code over to wiimote-modules. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:55 +08:00
WIIMOD_ACCEL,
HID: wiimote: convert IR to module IR is the last piece that still is handled natively. This patch converts it into a sub-device module like all other sub-devices. It mainly moves code and doesn't change semantics. We also implicitly sync IR data on ir_to_input3 now so the explicit input_sync() calls are no longer needed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:56 +08:00
WIIMOD_IR,
HID: wiimote: add sub-device module infrastructure To avoid loading all sub-device drivers for every Wii Remote, even though the required hardware might not be available, we introduce a module layer. The module layer specifies which sub-devices are available on each device-type. After device detection, we only load the modules for the detected device. If module loading fails, we unload everything and mark the device as WIIMOTE_DEV_UNKNOWN. As long as a device is marked as "unknown", no sub-devices will be used and the device is considered unsupported. All the different sub-devices, including KEYS, RUMBLE, BATTERY, LEDS, ACCELEROMETER, IR and more will be ported in follow-up patches to the new module layer. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:51 +08:00
WIIMOD_NUM,
WIIMOD_NULL = WIIMOD_NUM,
};
#define WIIMOD_FLAG_INPUT 0x0001
struct wiimod_ops {
__u16 flags;
unsigned long arg;
int (*probe) (const struct wiimod_ops *ops,
struct wiimote_data *wdata);
void (*remove) (const struct wiimod_ops *ops,
struct wiimote_data *wdata);
void (*in_keys) (struct wiimote_data *wdata, const __u8 *keys);
void (*in_accel) (struct wiimote_data *wdata, const __u8 *accel);
void (*in_ir) (struct wiimote_data *wdata, const __u8 *ir, bool packed,
unsigned int id);
};
extern const struct wiimod_ops *wiimod_table[WIIMOD_NUM];
/* wiimote requests */
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
enum wiiproto_reqs {
WIIPROTO_REQ_NULL = 0x0,
WIIPROTO_REQ_RUMBLE = 0x10,
WIIPROTO_REQ_LED = 0x11,
WIIPROTO_REQ_DRM = 0x12,
WIIPROTO_REQ_IR1 = 0x13,
WIIPROTO_REQ_SREQ = 0x15,
WIIPROTO_REQ_WMEM = 0x16,
WIIPROTO_REQ_RMEM = 0x17,
WIIPROTO_REQ_IR2 = 0x1a,
WIIPROTO_REQ_STATUS = 0x20,
WIIPROTO_REQ_DATA = 0x21,
WIIPROTO_REQ_RETURN = 0x22,
WIIPROTO_REQ_DRM_K = 0x30,
WIIPROTO_REQ_DRM_KA = 0x31,
WIIPROTO_REQ_DRM_KE = 0x32,
WIIPROTO_REQ_DRM_KAI = 0x33,
WIIPROTO_REQ_DRM_KEE = 0x34,
WIIPROTO_REQ_DRM_KAE = 0x35,
WIIPROTO_REQ_DRM_KIE = 0x36,
WIIPROTO_REQ_DRM_KAIE = 0x37,
WIIPROTO_REQ_DRM_E = 0x3d,
WIIPROTO_REQ_DRM_SKAI1 = 0x3e,
WIIPROTO_REQ_DRM_SKAI2 = 0x3f,
HID: wiimote: Allow direct DRM debug access Keep track of current drm and add new debugfs file which reads or writes the current DRM. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:12 +08:00
WIIPROTO_REQ_MAX
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
};
#define dev_to_wii(pdev) hid_get_drvdata(container_of(pdev, struct hid_device, \
dev))
extern void wiiproto_req_drm(struct wiimote_data *wdata, __u8 drm);
HID: wiimote: convert KEYS and RUMBLE to modules This introduces the first sub-device modules by converting the KEYS and RUMBLE sub-devices into wiimote modules. Both must be converted at once because they depend on the built-in shared input device. This mostly moves code from wiimote-core to wiimote-modules and doesn't change any semantics or ABI. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:52 +08:00
extern void wiiproto_req_rumble(struct wiimote_data *wdata, __u8 rumble);
HID: wiimote: convert LEDS to modules Each of the 4 LEDs may be supported individually by devices. Therefore, we need one module for each device. To avoid code-duplication, we simply pass the LED ID as "arg" argument to the module loading code. This just moves the code over to wiimote-module. The semantics stay the same as before. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:54 +08:00
extern void wiiproto_req_leds(struct wiimote_data *wdata, int leds);
HID: wiimote: convert BATTERY to module This introduces a new sub-device module for the BATTERY handlers. It moves the whole power_supply battery handling over to wiimote-modules. This doesn't change any semantics or ABI but only converts the battery handling into a sub-device module. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:53 +08:00
extern void wiiproto_req_status(struct wiimote_data *wdata);
HID: wiimote: convert ACCEL to module Accelerometer data is very similar to KEYS handling. Therefore, convert all ACCEL related handling into a sub-device module similar to KEYS. This doesn't change any semantics but only moves code over to wiimote-modules. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:55 +08:00
extern void wiiproto_req_accel(struct wiimote_data *wdata, __u8 accel);
HID: wiimote: convert IR to module IR is the last piece that still is handled natively. This patch converts it into a sub-device module like all other sub-devices. It mainly moves code and doesn't change semantics. We also implicitly sync IR data on ir_to_input3 now so the explicit input_sync() calls are no longer needed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:56 +08:00
extern void wiiproto_req_ir1(struct wiimote_data *wdata, __u8 flags);
extern void wiiproto_req_ir2(struct wiimote_data *wdata, __u8 flags);
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
extern int wiimote_cmd_write(struct wiimote_data *wdata, __u32 offset,
const __u8 *wmem, __u8 size);
HID: wiimote: Add read-mem helpers Add helper functions similar to the write-mem helpers but for reading wiimote memory and eeprom. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:00 +08:00
extern ssize_t wiimote_cmd_read(struct wiimote_data *wdata, __u32 offset,
__u8 *rmem, __u8 size);
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
HID: wiimote: Allow direct eeprom access The wiimote provides direct access to parts of its eeprom. This implements read support for small chunks of the eeprom. This isn't very fast but prevents the reader from blocking the wiimote stream for too long. Write support is not yet supported as the wiimote breaks if we overwrite its memory. Use hidraw to reverse-engineer the eeprom before implementing write support here. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:11 +08:00
#define wiiproto_req_rreg(wdata, os, sz) \
wiiproto_req_rmem((wdata), false, (os), (sz))
#define wiiproto_req_reeprom(wdata, os, sz) \
wiiproto_req_rmem((wdata), true, (os), (sz))
extern void wiiproto_req_rmem(struct wiimote_data *wdata, bool eeprom,
__u32 offset, __u16 size);
HID: wiimote: Add extension support stub The wiimote supports several extensions. This adds a separate source file which handles all extensions and can be disabled at compile-time. The driver reacts on "plug"-events on the extension port and starts a worker which initializes or deinitializes the extensions. Currently, the initialization logic is not fully understood and we can only detect and enable all extensions when all extensions are deactivated. Therefore, we need to disable all extensions, then detect and activate them again to react on "plug"-events. However, deactivating extensions will generate a new "plug"-event and we will never leave that loop. Hence, we only support extensions if they are plugged before the wiimote is connected (or before the ext-input device is opened). In the future we may support full extension hotplug support, but reverse-engineering this may take a while. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:01 +08:00
#ifdef CONFIG_HID_WIIMOTE_EXT
extern int wiiext_init(struct wiimote_data *wdata);
extern void wiiext_deinit(struct wiimote_data *wdata);
extern void wiiext_event(struct wiimote_data *wdata, bool plugged);
extern bool wiiext_active(struct wiimote_data *wdata);
HID: wiimote: Add extension handler stubs All supported extensions report data as 6 byte block. All DRMs with extension data provide at least 6 extension bytes. Hence a generic handler for all extension bytes is sufficient and can be called on all DRMs. The handler distinguishes the input and passes it to the right handler. Motion+ passes data interleaved so we can have Motion+ and a regular extension enabled simultaneously. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:06 +08:00
extern void wiiext_handle(struct wiimote_data *wdata, const __u8 *payload);
HID: wiimote: Add extension support stub The wiimote supports several extensions. This adds a separate source file which handles all extensions and can be disabled at compile-time. The driver reacts on "plug"-events on the extension port and starts a worker which initializes or deinitializes the extensions. Currently, the initialization logic is not fully understood and we can only detect and enable all extensions when all extensions are deactivated. Therefore, we need to disable all extensions, then detect and activate them again to react on "plug"-events. However, deactivating extensions will generate a new "plug"-event and we will never leave that loop. Hence, we only support extensions if they are plugged before the wiimote is connected (or before the ext-input device is opened). In the future we may support full extension hotplug support, but reverse-engineering this may take a while. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:01 +08:00
#else
static inline int wiiext_init(void *u) { return 0; }
static inline void wiiext_deinit(void *u) { }
static inline void wiiext_event(void *u, bool p) { }
static inline bool wiiext_active(void *u) { return false; }
HID: wiimote: Add extension handler stubs All supported extensions report data as 6 byte block. All DRMs with extension data provide at least 6 extension bytes. Hence a generic handler for all extension bytes is sufficient and can be called on all DRMs. The handler distinguishes the input and passes it to the right handler. Motion+ passes data interleaved so we can have Motion+ and a regular extension enabled simultaneously. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:06 +08:00
static inline void wiiext_handle(void *u, const __u8 *p) { }
HID: wiimote: Add extension support stub The wiimote supports several extensions. This adds a separate source file which handles all extensions and can be disabled at compile-time. The driver reacts on "plug"-events on the extension port and starts a worker which initializes or deinitializes the extensions. Currently, the initialization logic is not fully understood and we can only detect and enable all extensions when all extensions are deactivated. Therefore, we need to disable all extensions, then detect and activate them again to react on "plug"-events. However, deactivating extensions will generate a new "plug"-event and we will never leave that loop. Hence, we only support extensions if they are plugged before the wiimote is connected (or before the ext-input device is opened). In the future we may support full extension hotplug support, but reverse-engineering this may take a while. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:01 +08:00
#endif
HID: wiimote: Add debugfs support stubs Add initializer and deinitializer for debugfs support. This will later allow raw eeprom access and direct DRM modifications to debug wiimote behaviour and further protocol reverse-engineerings. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:12:10 +08:00
#ifdef CONFIG_DEBUG_FS
extern int wiidebug_init(struct wiimote_data *wdata);
extern void wiidebug_deinit(struct wiimote_data *wdata);
#else
static inline int wiidebug_init(void *u) { return 0; }
static inline void wiidebug_deinit(void *u) { }
#endif
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
/* requires the state.lock spinlock to be held */
static inline bool wiimote_cmd_pending(struct wiimote_data *wdata, int cmd,
__u32 opt)
{
return wdata->state.cmd == cmd && wdata->state.opt == opt;
}
/* requires the state.lock spinlock to be held */
static inline void wiimote_cmd_complete(struct wiimote_data *wdata)
{
wdata->state.cmd = WIIPROTO_REQ_NULL;
complete(&wdata->state.ready);
}
HID: wiimote: wake up if output queue failed Our output queue is asynchronous but synchronous reports may wait for a response to their request. Therefore, wake them up unconditionally if an output report couldn't be sent. But keep the report ID intact so we don't incorrectly assume our request succeeded. Note that the underlying connection is required to be reliable and does retransmission itself. So it is safe to assume that if the transmission fails, the device is in inconsistent state. Hence, we abort every request if any output report fails. No need to verify which report failed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:50 +08:00
/* requires the state.lock spinlock to be held */
static inline void wiimote_cmd_abort(struct wiimote_data *wdata)
{
/* Abort synchronous request by waking up the sleeping caller. But
* reset the state.cmd field to an invalid value so no further event
* handlers will work with it. */
wdata->state.cmd = WIIPROTO_REQ_MAX;
complete(&wdata->state.ready);
}
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
static inline int wiimote_cmd_acquire(struct wiimote_data *wdata)
{
return mutex_lock_interruptible(&wdata->state.sync) ? -ERESTARTSYS : 0;
}
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
static inline void wiimote_cmd_acquire_noint(struct wiimote_data *wdata)
{
mutex_lock(&wdata->state.sync);
}
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
/* requires the state.lock spinlock to be held */
static inline void wiimote_cmd_set(struct wiimote_data *wdata, int cmd,
__u32 opt)
{
INIT_COMPLETION(wdata->state.ready);
wdata->state.cmd = cmd;
wdata->state.opt = opt;
}
static inline void wiimote_cmd_release(struct wiimote_data *wdata)
{
mutex_unlock(&wdata->state.sync);
}
static inline int wiimote_cmd_wait(struct wiimote_data *wdata)
{
int ret;
HID: wiimote: wake up if output queue failed Our output queue is asynchronous but synchronous reports may wait for a response to their request. Therefore, wake them up unconditionally if an output report couldn't be sent. But keep the report ID intact so we don't incorrectly assume our request succeeded. Note that the underlying connection is required to be reliable and does retransmission itself. So it is safe to assume that if the transmission fails, the device is in inconsistent state. Hence, we abort every request if any output report fails. No need to verify which report failed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:50 +08:00
/* The completion acts as implicit memory barrier so we can safely
* assume that state.cmd is set on success/failure and isn't accessed
* by any other thread, anymore. */
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
ret = wait_for_completion_interruptible_timeout(&wdata->state.ready, HZ);
if (ret < 0)
return -ERESTARTSYS;
else if (ret == 0)
return -EIO;
HID: wiimote: wake up if output queue failed Our output queue is asynchronous but synchronous reports may wait for a response to their request. Therefore, wake them up unconditionally if an output report couldn't be sent. But keep the report ID intact so we don't incorrectly assume our request succeeded. Note that the underlying connection is required to be reliable and does retransmission itself. So it is safe to assume that if the transmission fails, the device is in inconsistent state. Hence, we abort every request if any output report fails. No need to verify which report failed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:50 +08:00
else if (wdata->state.cmd != WIIPROTO_REQ_NULL)
return -EIO;
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
else
return 0;
}
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
static inline int wiimote_cmd_wait_noint(struct wiimote_data *wdata)
{
unsigned long ret;
HID: wiimote: wake up if output queue failed Our output queue is asynchronous but synchronous reports may wait for a response to their request. Therefore, wake them up unconditionally if an output report couldn't be sent. But keep the report ID intact so we don't incorrectly assume our request succeeded. Note that the underlying connection is required to be reliable and does retransmission itself. So it is safe to assume that if the transmission fails, the device is in inconsistent state. Hence, we abort every request if any output report fails. No need to verify which report failed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:50 +08:00
/* no locking needed; see wiimote_cmd_wait() */
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
ret = wait_for_completion_timeout(&wdata->state.ready, HZ);
if (!ret)
return -EIO;
HID: wiimote: wake up if output queue failed Our output queue is asynchronous but synchronous reports may wait for a response to their request. Therefore, wake them up unconditionally if an output report couldn't be sent. But keep the report ID intact so we don't incorrectly assume our request succeeded. Note that the underlying connection is required to be reliable and does retransmission itself. So it is safe to assume that if the transmission fails, the device is in inconsistent state. Hence, we abort every request if any output report fails. No need to verify which report failed. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:50 +08:00
else if (wdata->state.cmd != WIIPROTO_REQ_NULL)
return -EIO;
HID: wiimote: add device detection Nintendo produced many different devices that are internally based on the Wii Remote protocol but provide different peripherals. To support these devices, we need to schedule a device detection during initialization. Device detection includes requesting a status report, reading extension information and then evaluating which device we may be dealing with. We currently detect gen1 and gen2 Wii Remote devices. All other devices are marked as generic devices. More detections will be added later. In followup patches we will be using these device IDs to control which peripherals to initialize. For instance if a device is known to have no IR camera, there is no need to provide the IR input device nor trying to access IR registers. In fact, there are 3rd party devices that break if we try things like this (hurray!). The init_worker will be scheduled whenever we get hotplug events. This isn't implemented, yet and will be added later. However, we need to make sure that this worker can be called multiple times. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:48 +08:00
else
return 0;
}
HID: wiimote: Move common symbols into header Wiimote extension and sound support need access to several symbols so move them into a new header. Signed-off-by: David Herrmann <dh.herrmann@googlemail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2011-11-17 21:11:59 +08:00
#endif
Copy Permalink