Vibrator Driver for Intel MID Platforms
PATCH 1/1 Vibrator Driver for Intel MID Platforms
From: Kalhan Trisal <[email protected]>
This patch provides support for the MID vibrator can be switched on/off using sysfs interfaces.
---
drivers/platform/x86/Kconfig | 9 +++ drivers/platform/x86/Makefile | 1 drivers/platform/x86/intel_mid_vibrator.c | 88 +++++++++++++++++++++++++++++ 3 files changed, 98 insertions(+), 0 deletions(-) create mode 100644 drivers/platform/x86/intel_mid_vibrator.c
drivers/platform/x86/Kconfig +9 -0
@@ -537,4 +537,13 @@ config INTEL_SCU_IPC some embedded Intel x86 platforms. This is not needed for PC-type machines. +config INTEL_MID_VIB + tristate "Vibrator driver for Intel MID platforms" + depends on INTEL_SCU_IPC + help + This driver provides a sys interface to the vibrator device + on the Intel MID platforms. + + If unsure, say N. + endif # X86_PLATFORM_DEVICES
drivers/platform/x86/Makefile +1 -0
@@ -26,3 +26,4 @@ obj-$(CONFIG_TOPSTAR_LAPTOP) += topstar-laptop.o obj-$(CONFIG_ACPI_TOSHIBA) += toshiba_acpi.o obj-$(CONFIG_TOSHIBA_BT_RFKILL) += toshiba_bluetooth.o obj-$(CONFIG_INTEL_SCU_IPC) += intel_scu_ipc.o +obj-$(CONFIG_INTEL_MID_VIB) += intel_mid_vibrator.o
drivers/platform/x86/intel_mid_vibrator.c new file +88 -0
88 lines not on this page · raw message
Quoted 4 lines · Alan Cox
From: Kalhan Trisal <[email protected]>
This patch provides support for the MID vibrator can be switched on/off using sysfs interfaces.
Looking through the kernel, it seems that we've got there main approaches to vibrator control - sysfs with a "speed" attribute, an input device using the force feedback ioctls or something that's plumbed through the sound codec. While the absence of any consistency here is obviously a problem, I'd prefer not to add a fourth - can you at least make the sysfs attribute "speed" (with it accepting only 0 and 1 if you don't have any way to control the hardware beyond on and off) so it's compatible with one of the existing implementations?
Quoted 3 lines
+/*
+ * If the PMIC hasn't been discovered or one is not found then
+ * the calls will error for us.
Can't you do this at probe time?
drivers/platform/x86/intel_mid_vibrator.c line 50
Quoted 5 lines
drivers/platform/x86/intel_mid_vibrator.c new file +5
-0+if (intel_scu_ipc_iowrite8 (0x49 ,0xAD )) +return -EINVAL ; + }else { +if (intel_scu_ipc_iowrite8 (0x49 ,0x14 )) +return -EINVAL ;
Is there any significance to 0xAD and 0x14? Is this register specific to the vibrator?
Otherwise, looks good.
Signature · 1 line
Matthew Garrett | [email protected]
Quoted 4 lines
approaches to vibrator control - sysfs with a "speed" attribute, an input device using the force feedback ioctls or something that's plumbed through the sound codec. While the absence of any consistency here is obviously a problem, I'd prefer not to add a fourth - can you
I'll have a look - I hadn't seen one using the force feedback but that makes an awful lot of sense.
Quoted 5 lines
Quoted 3 lines
+ * If the PMIC hasn't been discovered or one is not found
then
+ * the calls will error for us.Can't you do this at probe time?
We have to check for errors anyway. We could also check at probe time but that would add ordering issues or mean we needed the scu_ipc driver to create the platform device for the vibrator - which given it's not current discoverable is a bit ugly.
Quoted 8 lines
drivers/platform/x86/intel_mid_vibrator.c line 50
Quoted 5 lines
drivers/platform/x86/intel_mid_vibrator.c new file +5
-0+if (intel_scu_ipc_iowrite8 (0x49 ,0xAD )) +return -EINVAL ; + }else { +if (intel_scu_ipc_iowrite8 (0x49 ,0x14 )) +return -EINVAL ;Is there any significance to
0xADand0x14? Is this register specific to the vibrator?
As I understand it yes.
Quoted 10 lines · Alan Cox
Quoted 5 lines
Quoted 3 lines
+ * If the PMIC hasn't been discovered or one is not found
then
+ * the calls will error for us.Can't you do this at probe time?
We have to check for errors anyway. We could also check at probe time but that would add ordering issues or mean we needed the
scu_ipcdriver to create the platform device for the vibrator - which given it's not current discoverable is a bit ugly.
The ipc driver is presumably intended to probe first (and module dependencies will ensure that in the modular case). Once that probe has completed, isn't it expected that scu_ipc_ioread will error if there's no device?
Signature · 1 line
Matthew Garrett | [email protected]