hollalinux
/
linux-sg2042
mirror of https://github.com/sophgo/linux-riscv.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
linux-sg2042/drivers/hid/hid-wiimote.h

377 lines
9.3 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>
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
#include <linux/timer.h>
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 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: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
#define WIIPROTO_FLAG_EXT_USED 0x0200
#define WIIPROTO_FLAG_EXT_ACTIVE 0x0400
#define WIIPROTO_FLAG_MP_PLUGGED 0x0800
#define WIIPROTO_FLAG_MP_USED 0x1000
#define WIIPROTO_FLAG_MP_ACTIVE 0x2000
#define WIIPROTO_FLAG_EXITING 0x4000
HID: wiimote: lock DRM mode during debugfs overwrite If we write a DRM mode via debugfs, we shouldn't allow normal operations to overwrite this DRM mode. This is important if we want to debug 3rd-party devices and we want to see what data is sent on each mode. If we write NULL/0 as DRM, the lock is removed again so the best matching DRM is chosen by wiimote core. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:13:03 +08:00
#define WIIPROTO_FLAG_DRM_LOCKED 0x8000
HID: wiimote: add MP quirks Devices which have built-in motion plus ports don't need MP detection logic. The new WIIMOD_BUILTIN_MP modules sets the WIIPROTO_FLAG_BUILTIN_MP flag which disables polling for MP. Some other devices erroneously report that they support motion-plus. For these devices and all devices without extension ports, we load WIIMOD_NO_MP which sets WIIPROTO_FLAG_NO_MP. This effectively disables all MP detection logic. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:13:07 +08:00
#define WIIPROTO_FLAG_BUILTIN_MP 0x010000
#define WIIPROTO_FLAG_NO_MP 0x020000
HID: wiimote: add pro-controller analog stick calibration The analog sticks of the pro-controller might report slightly off values. To guarantee a uniform setup, we now calibrate analog-stick values during pro-controller setup. Unfortunately, the pro-controller fails during normal EEPROM reads and I couldn't figure out whether there are any calibration values stored on the device. Therefore, we now use the first values reported by the device (iff they are not _way_ off, which would indicate movement) to initialize the calibration values. To allow users to change this calibration data, we provide a pro_calib sysfs attribute. We also change the "flat" values so user-space correctly smoothes our data. It makes slightly off zero-positions less visible while still guaranteeing highly precise movement reports. Note that the pro controller reports zero-positions in a quite huge range (at least: -100 to +100). Reported-by: Rafael Brune <mail@rbrune.de> Tested-by: Rafael Brune <mail@rbrune.de> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-29 00:49:20 +08:00
#define WIIPROTO_FLAG_PRO_CALIB_DONE 0x040000
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
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,
HID: wiimote: add Balance Board support This adds Nintendo Wii Balance Board support to the new HOTPLUG capable wiimote core. It is mostly copied from the old extension. This also adds Balance Board device detection. Whenever we find a device that supports the balance-board extension, we assume that it is a real balance board and disable unsupported hardward like accelerometer, IR, rumble and more. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:58 +08:00
WIIMOTE_DEV_BALANCE_BOARD,
HID: wiimote: support Nintendo Wii U Pro Controller The Wii U Pro Controller is a new Nintendo remote device that looks very similar to the XBox controller. It has nearly the same features and uses the same protocol as the Wii Remote. We add a new wiimote extension device so the Pro Controller is properly detected and supported. The device reports MP support, which is odd and I couldn't get it working, yet. Hence, we disable MP registers for now. Further investigation is needed to see what extra capabilities are provided. There are some other unknown bits in the extension reports that I couldn't figure out what they do. You can use hidraw to access these if you're interested. We might want to hook up the "charging" and "USB" bits to the battery device so user-space can query whether it is currently charged via USB. Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-15 21:32:45 +08:00
WIIMOTE_DEV_PRO_CONTROLLER,
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
WIIMOTE_DEV_NUM,
};
enum wiimote_exttype {
WIIMOTE_EXT_NONE,
WIIMOTE_EXT_UNKNOWN,
HID: wiimote: add Nunchuk support This moves the nunchuk parser over to an extension module. This allows to make use of hotplugged Nunchuks instead of the old static parser. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:59 +08:00
WIIMOTE_EXT_NUNCHUK,
HID: wiimote: add Classic Controller extension Add a new extension module for the classic controller so we get hotplug support for this device. It is mostly the same as the old static classic controller parser. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:13:00 +08:00
WIIMOTE_EXT_CLASSIC_CONTROLLER,
HID: wiimote: add Balance Board support This adds Nintendo Wii Balance Board support to the new HOTPLUG capable wiimote core. It is mostly copied from the old extension. This also adds Balance Board device detection. Whenever we find a device that supports the balance-board extension, we assume that it is a real balance board and disable unsupported hardward like accelerometer, IR, rumble and more. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:58 +08:00
WIIMOTE_EXT_BALANCE_BOARD,
HID: wiimote: support Nintendo Wii U Pro Controller The Wii U Pro Controller is a new Nintendo remote device that looks very similar to the XBox controller. It has nearly the same features and uses the same protocol as the Wii Remote. We add a new wiimote extension device so the Pro Controller is properly detected and supported. The device reports MP support, which is odd and I couldn't get it working, yet. Hence, we disable MP registers for now. Further investigation is needed to see what extra capabilities are provided. There are some other unknown bits in the extension reports that I couldn't figure out what they do. You can use hidraw to access these if you're interested. We might want to hook up the "charging" and "USB" bits to the battery device so user-space can query whether it is currently charged via USB. Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-06-15 21:32:45 +08:00
WIIMOTE_EXT_PRO_CONTROLLER,
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
WIIMOTE_EXT_NUM,
};
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
enum wiimote_mptype {
WIIMOTE_MP_NONE,
WIIMOTE_MP_UNKNOWN,
WIIMOTE_MP_SINGLE,
WIIMOTE_MP_PASSTHROUGH_NUNCHUK,
WIIMOTE_MP_PASSTHROUGH_CLASSIC,
};
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: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
__u8 exttype;
__u8 mp;
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: add Balance Board support This adds Nintendo Wii Balance Board support to the new HOTPLUG capable wiimote core. It is mostly copied from the old extension. This also adds Balance Board device detection. Whenever we find a device that supports the balance-board extension, we assume that it is a real balance board and disable unsupported hardward like accelerometer, IR, rumble and more. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:58 +08:00
HID: wiimote: fix FF deadlock The input core has an internal spinlock that is acquired during event injection via input_event() and friends but also held during FF callbacks. That means, there is no way to share a lock between event-injection and FF handling. Unfortunately, this is what is required for wiimote state tracking and what we do with state.lock and input->lock. This deadlock can be triggered when using continuous data reporting and FF on a wiimote device at the same time. I takes me at least 30m of stress-testing to trigger it but users reported considerably shorter times (http://bpaste.net/show/132504/) when using some gaming-console emulators. The real problem is that we have two copies of internal state, one in the wiimote objects and the other in the input device. As the input-lock is not supposed to be accessed from outside of input-core, we have no other chance than offloading FF handling into a worker. This actually works pretty nice and also allows to implictly merge fast rumble changes into a single request. Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF responsiveness. Initial tests were fine so lets fix the race first and if it turns out to be too slow we can always handle FF out-of-band and skip the queue-worker. Cc: <stable@vger.kernel.org> # 3.11+ Reported-by: Thomas Schneider Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-02 19:47:28 +08:00
/* calibration/cache data */
HID: wiimote: add Balance Board support This adds Nintendo Wii Balance Board support to the new HOTPLUG capable wiimote core. It is mostly copied from the old extension. This also adds Balance Board device detection. Whenever we find a device that supports the balance-board extension, we assume that it is a real balance board and disable unsupported hardward like accelerometer, IR, rumble and more. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:58 +08:00
__u16 calib_bboard[4][3];
HID: wiimote: add pro-controller analog stick calibration The analog sticks of the pro-controller might report slightly off values. To guarantee a uniform setup, we now calibrate analog-stick values during pro-controller setup. Unfortunately, the pro-controller fails during normal EEPROM reads and I couldn't figure out whether there are any calibration values stored on the device. Therefore, we now use the first values reported by the device (iff they are not _way_ off, which would indicate movement) to initialize the calibration values. To allow users to change this calibration data, we provide a pro_calib sysfs attribute. We also change the "flat" values so user-space correctly smoothes our data. It makes slightly off zero-positions less visible while still guaranteeing highly precise movement reports. Note that the pro controller reports zero-positions in a quite huge range (at least: -100 to +100). Reported-by: Rafael Brune <mail@rbrune.de> Tested-by: Rafael Brune <mail@rbrune.de> Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-29 00:49:20 +08:00
__s16 calib_pro_sticks[4];
HID: wiimote: fix FF deadlock The input core has an internal spinlock that is acquired during event injection via input_event() and friends but also held during FF callbacks. That means, there is no way to share a lock between event-injection and FF handling. Unfortunately, this is what is required for wiimote state tracking and what we do with state.lock and input->lock. This deadlock can be triggered when using continuous data reporting and FF on a wiimote device at the same time. I takes me at least 30m of stress-testing to trigger it but users reported considerably shorter times (http://bpaste.net/show/132504/) when using some gaming-console emulators. The real problem is that we have two copies of internal state, one in the wiimote objects and the other in the input device. As the input-lock is not supposed to be accessed from outside of input-core, we have no other chance than offloading FF handling into a worker. This actually works pretty nice and also allows to implictly merge fast rumble changes into a single request. Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF responsiveness. Initial tests were fine so lets fix the race first and if it turns out to be too slow we can always handle FF out-of-band and skip the queue-worker. Cc: <stable@vger.kernel.org> # 3.11+ Reported-by: Thomas Schneider Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-02 19:47:28 +08:00
__u8 cache_rumble;
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;
HID: wiimote: fix FF deadlock The input core has an internal spinlock that is acquired during event injection via input_event() and friends but also held during FF callbacks. That means, there is no way to share a lock between event-injection and FF handling. Unfortunately, this is what is required for wiimote state tracking and what we do with state.lock and input->lock. This deadlock can be triggered when using continuous data reporting and FF on a wiimote device at the same time. I takes me at least 30m of stress-testing to trigger it but users reported considerably shorter times (http://bpaste.net/show/132504/) when using some gaming-console emulators. The real problem is that we have two copies of internal state, one in the wiimote objects and the other in the input device. As the input-lock is not supposed to be accessed from outside of input-core, we have no other chance than offloading FF handling into a worker. This actually works pretty nice and also allows to implictly merge fast rumble changes into a single request. Due to the 3-layered workers (rumble+queue+l2cap) this might reduce FF responsiveness. Initial tests were fine so lets fix the race first and if it turns out to be too slow we can always handle FF out-of-band and skip the queue-worker. Cc: <stable@vger.kernel.org> # 3.11+ Reported-by: Thomas Schneider Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-10-02 19:47:28 +08:00
struct work_struct rumble_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
struct led_classdev *leds[4];
struct input_dev *accel;
struct input_dev *ir;
power_supply: Change ownership from driver to core Change the ownership of power_supply structure from each driver implementing the class to the power supply core. The patch changes power_supply_register() function thus all drivers implementing power supply class are adjusted. Each driver provides the implementation of power supply. However it should not be the owner of power supply class instance because it is exposed by core to other subsystems with power_supply_get_by_name(). These other subsystems have no knowledge when the driver will unregister the power supply. This leads to several issues when driver is unbound - mostly because user of power supply accesses freed memory. Instead let the core own the instance of struct 'power_supply'. Other users of this power supply will still access valid memory because it will be freed when device reference count reaches 0. Currently this means "it will leak" but power_supply_put() call in next patches will solve it. This solves invalid memory references in following race condition scenario: Thread 1: charger manager Thread 2: power supply driver, used by charger manager THREAD 1 (charger manager) THREAD 2 (power supply driver) ========================== ============================== psy = power_supply_get_by_name() Driver unbind, .remove power_supply_unregister() Device fully removed psy->get_property() The 'get_property' call is executed in invalid context because the driver was unbound and struct 'power_supply' memory was freed. This could be observed easily with charger manager driver (here compiled with max17040 fuel gauge): $ cat /sys/devices/virtual/power_supply/cm-battery/capacity & $ echo "1-0036" > /sys/bus/i2c/drivers/max17040/unbind [ 55.725123] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 55.732584] pgd = d98d4000 [ 55.734060] [00000000] *pgd=5afa2831, *pte=00000000, *ppte=00000000 [ 55.740318] Internal error: Oops: 80000007 [#1] PREEMPT SMP ARM [ 55.746210] Modules linked in: [ 55.749259] CPU: 1 PID: 2936 Comm: cat Tainted: G W 3.19.0-rc1-next-20141226-00048-gf79f475f3c44-dirty #1496 [ 55.760190] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [ 55.766270] task: d9b76f00 ti: daf54000 task.ti: daf54000 [ 55.771647] PC is at 0x0 [ 55.774182] LR is at charger_get_property+0x2f4/0x36c [ 55.779201] pc : [<00000000>] lr : [<c034b0b4>] psr: 60000013 [ 55.779201] sp : daf55e90 ip : 00000003 fp : 00000000 [ 55.790657] r10: 00000000 r9 : c06e2878 r8 : d9b26c68 [ 55.795865] r7 : dad81610 r6 : daec7410 r5 : daf55ebc r4 : 00000000 [ 55.802367] r3 : 00000000 r2 : daf55ebc r1 : 0000002a r0 : d9b26c68 [ 55.808879] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 55.815994] Control: 10c5387d Table: 598d406a DAC: 00000015 [ 55.821723] Process cat (pid: 2936, stack limit = 0xdaf54210) [ 55.827451] Stack: (0xdaf55e90 to 0xdaf56000) [ 55.831795] 5e80: 60000013 c01459c4 0000002a c06f8ef8 [ 55.839956] 5ea0: db651000 c06f8ef8 daebac00 c04cb668 daebac08 c0346864 00000000 c01459c4 [ 55.848115] 5ec0: d99eaa80 c06f8ef8 00000fff 00001000 db651000 c027f25c c027f240 d99eaa80 [ 55.856274] 5ee0: d9a06c00 c0146218 daf55f18 00001000 d99eaa80 db4c18c0 00000001 00000001 [ 55.864468] 5f00: daf55f80 c0144c78 c0144c54 c0107f90 00015000 d99eaab0 00000000 00000000 [ 55.872603] 5f20: 000051c7 00000000 db4c18c0 c04a9370 00015000 00001000 daf55f80 00001000 [ 55.880763] 5f40: daf54000 00015000 00000000 c00e53dc db4c18c0 c00e548c 0000000d 00008124 [ 55.888937] 5f60: 00000001 00000000 00000000 db4c18c0 db4c18c0 00001000 00015000 c00e5550 [ 55.897099] 5f80: 00000000 00000000 00001000 00001000 00015000 00000003 00000003 c000f364 [ 55.905239] 5fa0: 00000000 c000f1a0 00001000 00015000 00000003 00015000 00001000 0001333c [ 55.913399] 5fc0: 00001000 00015000 00000003 00000003 00000002 00000000 00000000 00000000 [ 55.921560] 5fe0: 7fffe000 be999850 0000a225 b6f3c19c 60000010 00000003 00000000 00000000 [ 55.929744] [<c034b0b4>] (charger_get_property) from [<c0346864>] (power_supply_show_property+0x48/0x20c) [ 55.939286] [<c0346864>] (power_supply_show_property) from [<c027f25c>] (dev_attr_show+0x1c/0x48) [ 55.948130] [<c027f25c>] (dev_attr_show) from [<c0146218>] (sysfs_kf_seq_show+0x84/0x104) [ 55.956298] [<c0146218>] (sysfs_kf_seq_show) from [<c0144c78>] (kernfs_seq_show+0x24/0x28) [ 55.964536] [<c0144c78>] (kernfs_seq_show) from [<c0107f90>] (seq_read+0x1b0/0x484) [ 55.972172] [<c0107f90>] (seq_read) from [<c00e53dc>] (__vfs_read+0x18/0x4c) [ 55.979188] [<c00e53dc>] (__vfs_read) from [<c00e548c>] (vfs_read+0x7c/0x100) [ 55.986304] [<c00e548c>] (vfs_read) from [<c00e5550>] (SyS_read+0x40/0x8c) [ 55.993164] [<c00e5550>] (SyS_read) from [<c000f1a0>] (ret_fast_syscall+0x0/0x48) [ 56.000626] Code: bad PC value [ 56.011652] ---[ end trace 7b64343fbdae8ef1 ]--- Signed-off-by: Krzysztof Kozlowski <k.kozlowski@samsung.com> Reviewed-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> [for the nvec part] Reviewed-by: Marc Dietrich <marvin24@gmx.de> [for compal-laptop.c] Acked-by: Darren Hart <dvhart@linux.intel.com> [for the mfd part] Acked-by: Lee Jones <lee.jones@linaro.org> [for the hid part] Acked-by: Jiri Kosina <jkosina@suse.cz> [for the acpi part] Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sebastian Reichel <sre@kernel.org>
2015-03-12 15:44:11 +08:00
struct power_supply *battery;
struct power_supply_desc battery_desc;
HID: wiimote: add Motion Plus extension module Add parsers for motion plus data so we can hotplug motion plus extensions and make use of them. This is mostly the same as the old static motion plus parser. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:13:01 +08:00
struct input_dev *mp;
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
struct timer_list timer;
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: add Balance Board support This adds Nintendo Wii Balance Board support to the new HOTPLUG capable wiimote core. It is mostly copied from the old extension. This also adds Balance Board device detection. Whenever we find a device that supports the balance-board extension, we assume that it is a real balance board and disable unsupported hardward like accelerometer, IR, rumble and more. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:58 +08:00
union {
struct input_dev *input;
} extension;
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 MP quirks Devices which have built-in motion plus ports don't need MP detection logic. The new WIIMOD_BUILTIN_MP modules sets the WIIPROTO_FLAG_BUILTIN_MP flag which disables polling for MP. Some other devices erroneously report that they support motion-plus. For these devices and all devices without extension ports, we load WIIMOD_NO_MP which sets WIIPROTO_FLAG_NO_MP. This effectively disables all MP detection logic. Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:13:07 +08:00
WIIMOD_BUILTIN_MP,
WIIMOD_NO_MP,
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
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
#define WIIMOD_FLAG_EXT8 0x0002
#define WIIMOD_FLAG_EXT16 0x0004
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
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);
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
void (*in_mp) (struct wiimote_data *wdata, const __u8 *mp);
void (*in_ext) (struct wiimote_data *wdata, const __u8 *ext);
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
};
extern const struct wiimod_ops *wiimod_table[WIIMOD_NUM];
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
extern const struct wiimod_ops *wiimod_ext_table[WIIMOTE_EXT_NUM];
extern const struct wiimod_ops wiimod_mp;
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 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,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_K: BB*2 */
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
WIIPROTO_REQ_DRM_K = 0x30,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_KA: BB*2 AA*3 */
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
WIIPROTO_REQ_DRM_KA = 0x31,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_KE: BB*2 EE*8 */
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
WIIPROTO_REQ_DRM_KE = 0x32,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_KAI: BB*2 AA*3 II*12 */
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
WIIPROTO_REQ_DRM_KAI = 0x33,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_KEE: BB*2 EE*19 */
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
WIIPROTO_REQ_DRM_KEE = 0x34,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_KAE: BB*2 AA*3 EE*16 */
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
WIIPROTO_REQ_DRM_KAE = 0x35,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_KIE: BB*2 II*10 EE*9 */
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
WIIPROTO_REQ_DRM_KIE = 0x36,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_KAIE: BB*2 AA*3 II*10 EE*6 */
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
WIIPROTO_REQ_DRM_KAIE = 0x37,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_E: EE*21 */
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
WIIPROTO_REQ_DRM_E = 0x3d,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_SKAI1: BB*2 AA*1 II*18 */
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
WIIPROTO_REQ_DRM_SKAI1 = 0x3e,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
/* DRM_SKAI2: BB*2 AA*1 II*18 */
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
WIIPROTO_REQ_DRM_SKAI2 = 0x3f,
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
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))
HID: wiimote: add extension hotplug support The Wii Remote has several extension ports. The first port (EXT) provides hotplug events whenever an extension is plugged. The second port (MP) does not provide hotplug events by default. Instead, we have to map MP into EXT to get events for it. This patch introduces hotplug support for extensions. It is fairly complicated to get this right because the Wii Remote sends a lot of noise-hotplug events while activating extension ports. We need to filter the events and only handle the events that are real hotplug events. Mapping MP into EXT is easy. But if we want both, MP _and_ EXT at the same time, we need to map MP into EXT and enable a passthrough-mode. This will then send real EXT events through the mapped MP interleaved with real MP events. But once MP is mapped, we no longer have access to the real EXT registers so we need to perform setup _before_ mapping MP. Furthermore, we no longer can read EXT IDs so we cannot verify if EXT is still the same extension that we expect it to be. We deal with this by unmapping MP whenever we got into a situation where EXT might have changed. We then re-read EXT and MP and remap everything. The real Wii Console takes a fairly easy approach: It simply reconnects to the device on hotplug events that it didn't expect. So if a program wants MP events, but MP is disconnected, it fails and reconnects so it can wait for MP hotplug events again. This simplifies hotplugging a lot because we just react on PLUG events and ignore UNPLUG events. The more sophisticated Wii applications avoid reconnection (well, they still reconnect during many weird events, but at least not during UNPLUG) but they start polling the device. This allows them to disable the device, poll for the extension ports to settle and then initialize them again. Unfortunately, this approach fails whenever an extension is replugged while it is initialized. We would loose UNPLUG events and polling the device later will give unreliable results because the extension port might be in some weird state, even though it's actually unplugged. Our approach is a real HOTPLUG approch. We keep track of the EXT and mapped MP hotplug events whenever they occur. We then re-evaluate the device state and initialize any possible new extension or deinitialize any gone extension. Only during initialization, we set an extension port ACTIVE. However, during an unplug event we mark them as INACTIVE. This guarantess that a fast UNPLUG -> PLUG event sequence doesn't keep them marked as PLUGGED+ACTIVE but only PLUGGED. To deal with annoying noise-hotplug events during extension mapping, we simply rescan the device before performing any mapping. This allows us to ignore all the noise events as long as the device is in the correct state. Long story short: EXT and MP registers are sparsely known and we need to jump through hoops to get reliable HOTPLUG working. But while Nintendo needs *FOUR* Bluetooth reconnections for the shortest imaginable boot->menu->game->menu->shutdown sequence, we now need *ZERO*. As always, 3rd party devices tend to break whenever we behave differently than the original Wii. So there are also devices which _expect_ a disconnect after UNPLUG. Obviously, these devices won't benefit from this patch. But all official devices were tested extensively and work great during any hotplug sequence. Yay! Signed-off-by: David Herrmann <dh.herrmann@gmail.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
2013-05-06 05:12:57 +08:00
void __wiimote_schedule(struct wiimote_data *wdata);
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 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 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)
{
tree-wide: use reinit_completion instead of INIT_COMPLETION Use this new function to make code more comprehensible, since we are reinitialzing the completion, not initializing. [akpm@linux-foundation.org: linux-next resyncs] Signed-off-by: Wolfram Sang <wsa@the-dreams.de> Acked-by: Linus Walleij <linus.walleij@linaro.org> (personally at LCE13) Cc: Ingo Molnar <mingo@kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-11-15 06:32:02 +08:00
reinit_completion(&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
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