Re: [PATCH] PCAP touchscreen driver (for 2.6.32)
Hi Daniel,
On Sat, Jun 27, 2009 at 02:02:18PM -0300, Daniel Ribeiro wrote:
Touchscreen driver for PCAP2 PMIC.
Signed-off-by: Daniel Ribeiro drw...@gmail.com
---
drivers/input/touchscreen/Kconfig |9 ++
drivers/input/touchscreen/Makefile |1 +
drivers/input/touchscreen/pcap_ts.c | 235
+++
3 files changed, 245 insertions(+), 0 deletions(-)
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 72e2712..8e6fa8b 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -498,4 +498,13 @@ config TOUCHSCREEN_W90X900
To compile this driver as a module, choose M here: the
module will be called w90p910_ts.
+config TOUCHSCREEN_PCAP
+ tristate Motorola PCAP touchscreen
+ depends on EZX_PCAP
+ help
+ Say Y here if you have a Motorola EZX telephone and
+ want to support the built-in touchscreen.
+
+ If unsure, say N.
+
endif
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index 3e1c5e0..4599bf7 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -40,3 +40,4 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX_ATMEL) +=
atmel-wm97xx.o
obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE) += mainstone-wm97xx.o
obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE)+= zylonite-wm97xx.o
obj-$(CONFIG_TOUCHSCREEN_W90X900)+= w90p910_ts.o
+obj-$(CONFIG_TOUCHSCREEN_PCAP) += pcap_ts.o
diff --git a/drivers/input/touchscreen/pcap_ts.c
b/drivers/input/touchscreen/pcap_ts.c
new file mode 100644
index 000..7877fdf
--- /dev/null
+++ b/drivers/input/touchscreen/pcap_ts.c
@@ -0,0 +1,235 @@
+/*
+ * Driver for Motorola PCAP2 touchscreen as found in the EZX phone platform.
+ *
+ * Copyright (C) 2006 Harald Welte lafo...@openezx.org
+ * Copyright (C) 2009 Daniel Ribeiro drw...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include linux/module.h
+#include linux/init.h
+#include linux/fs.h
+#include linux/string.h
+#include linux/pm.h
+#include linux/timer.h
+#include linux/interrupt.h
+#include linux/platform_device.h
+#include linux/input.h
+#include linux/mfd/ezx-pcap.h
+
+struct pcap_ts {
+ struct pcap_chip *pcap;
+ struct input_dev *input;
+ struct delayed_work work;
+ u16 x, y;
+ u16 pressure;
+ u8 read_state;
+};
+
+#define SAMPLE_DELAY 20 /* msecs */
+
+#define X_AXIS_MIN 0
+#define X_AXIS_MAX 1023
+#define Y_AXIS_MAX X_AXIS_MAX
+#define Y_AXIS_MIN X_AXIS_MIN
+#define PRESSURE_MAX X_AXIS_MAX
+#define PRESSURE_MIN X_AXIS_MIN
+
+static void pcap_ts_read_xy(void *data, u16 res[2])
+{
+ struct pcap_ts *pcap_ts = data;
+
+ switch (pcap_ts-read_state) {
+ case PCAP_ADC_TS_M_PRESSURE:
+ /* pressure reading is unreliable */
+ if (res[0] PRESSURE_MIN res[0] PRESSURE_MAX)
+ pcap_ts-pressure = res[0];
+ pcap_ts-read_state = PCAP_ADC_TS_M_XY;
+ schedule_delayed_work(pcap_ts-work, 0);
+ break;
+ case PCAP_ADC_TS_M_XY:
+ pcap_ts-y = res[0];
+ pcap_ts-x = res[1];
+ if (pcap_ts-x = X_AXIS_MIN || pcap_ts-x = X_AXIS_MAX ||
+ pcap_ts-y = Y_AXIS_MIN || pcap_ts-y = Y_AXIS_MAX) {
+ /* pen has been released */
+ input_report_abs(pcap_ts-input, ABS_PRESSURE, 0);
+ input_report_key(pcap_ts-input, BTN_TOUCH, 0);
+
+ pcap_ts-read_state = PCAP_ADC_TS_M_STANDBY;
+ schedule_delayed_work(pcap_ts-work, 0);
It looks like the only thing the work will do is:
+ pcap_set_ts_bits(pcap_ts-pcap,
+ pcap_ts-read_state PCAP_ADC_TS_M_SHIFT);
So why not do that directly here instead of scheduling work again?
+ } else {
+ /* pen is touching the screen*/
+ input_report_abs(pcap_ts-input, ABS_X, pcap_ts-x);
+ input_report_abs(pcap_ts-input, ABS_Y, pcap_ts-y);
+ input_report_key(pcap_ts-input, BTN_TOUCH, 1);
+ input_report_abs(pcap_ts-input, ABS_PRESSURE,
+ pcap_ts-pressure);
+
+ /* switch back to pressure read mode */
+ pcap_ts-read_state = PCAP_ADC_TS_M_PRESSURE;
+ schedule_delayed_work(pcap_ts-work,
+ msecs_to_jiffies(SAMPLE_DELAY));
+ }
+ input_sync(pcap_ts-input);
+ break;
+ default:
Maybe add some angry words here?
+ break;
+ }
Re: [PATCH 1/2] MMC/pxamci: workaround regulator framework bugs
On Mon, Jun 29, 2009 at 11:00:38AM +0800, Eric Miao wrote: This looks to be running into the same issue as clocks - where for power savings the clocks are assumed to be off as many as possible, leaving only those essential ones enabled, yet the assumption of the boot loader does this correctly is always a big problem, putting this into the kernel, however, is ugly. At the minute the regulator API actually copes pretty well with this - the only problem I'm aware of is with drivers like the MMC driver which require exclusive control of the regulator. With other drivers the core API can clean up after startup and the drivers never need to worry about fixing things up.
Re: [PATCH] PCAP misc input driver (for 2.6.32)
On Sat, Jun 27, 2009 at 02:09:52PM -0300, Daniel Ribeiro wrote: This is a driver for misc input events for the PCAP2 PMIC, it handles the power button, headphone insertion/removal and the headphone button. Depending on the power management capabilities of the CODEC it may be better to support at laest the headphone insert/removal via the audio driver as a jack to allow automatic management of the power for the relevant paths within the CODEC.
Re: [PATCH] PCAP misc input driver (for 2.6.32)
2009/6/29 Mark Brown broo...@opensource.wolfsonmicro.com: Depending on the power management capabilities of the CODEC it may be better to support at laest the headphone insert/removal via the audio driver as a jack to allow automatic management of the power for the relevant paths within the CODEC. we need to control this manually from userspace - for example, even with headphone plugged in ringtone should be played via speaker. -- wbr, Ilya ICQ: none, Jabber: ilya.muro...@jabber.ru
Re: [PATCH] PCAP misc input driver (for 2.6.32)
On Mon, Jun 29, 2009 at 07:27:24PM +0300, Ilya Petrov wrote: 2009/6/29 Mark Brown broo...@opensource.wolfsonmicro.com: Depending on the power management capabilities of the CODEC it may be better to support at laest the headphone insert/removal via the audio driver as a jack to allow automatic management of the power for the relevant paths within the CODEC. we need to control this manually from userspace - for example, even with headphone plugged in ringtone should be played via speaker. ALSA jacks are still visible to user space as input devices. The difference it will make here is that the kernel can autonomously control power for paths where that makes sense.
Re: [PATCH] PCAP misc input driver (for 2.6.32)
Em Dom, 2009-06-28 às 23:14 -0700, Dmitry Torokhov escreveu: drivers/input/keyboard/Kconfig |7 ++ drivers/input/keyboard/Makefile|1 + drivers/input/keyboard/pcap_keys.c | 152 3 files changed, 160 insertions(+), 0 deletions(-) First of all I think the driver should live in misc, not in keyboard, since it is not a full-fledged keyboard. Ok. + Say Y here if you want to use power key and jack events + on Motorola EZX 2nd generation phones + To compile this driver as a module... Ok. + case PCAP_IRQ_MIC: + input_report_key(pcap_keys-input, KEY_HP, !pstat); Why not SW_MICROPHONE_INSERT? Its actually a button. The device has a single jack for headphone and microphone. And the headset that we connect to it has a button that you use to answer calls, or dial. +static int __init pcap_keys_probe(struct platform_device *pdev) __devinit, not __init should be used on driver's probe() methods. Ok. + pcap_keys-input-name = pdev-name; + pcap_keys-input-phys = pcap-keys/input0; + pcap_keys-input-dev.parent = pdev-dev; I do like a temp for input_dev, it usually makes code a bit smaller. Also it would be nice to have but type set (BUS_HOST I think). Ok. + set_bit(KEY_HP, pcap_keys-input-keybit); __set_bit() please, like Trolok said. Ok. +static int pcap_keys_remove(struct platform_device *pdev) __devexit here. Ok. + .remove = pcap_keys_remove, __devexit_p() Ok. +MODULE_DESCRIPTION(Motorola PCAP2 input events driver); +MODULE_AUTHOR(Ilya Petrov ilya.muro...@gmail.com); +MODULE_LICENSE(GPL); Do we need MODULE_ALIAS() here? Do we? I think we don't, but well... It costs nothing. ;) -- Daniel Ribeiro signature.asc Description: Esta é uma parte de mensagem assinada digitalmente
