* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Laurent Pinchart @ 2013-10-29 17:29 UTC (permalink / raw)
To: Mark Brown
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Linus Walleij,
Guennadi Liakhovetski, Thierry Reding,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart,
ed.com-i9wRM+HIrmnmtl4Z8vJ8Kg761KYD1DLY, Vinod Koul,
linux-sh-u79uwXL29TY76Z2rM5mHXA, Magnus Damm, Eduardo Valentin,
Tomi Valkeinen, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Ian Molton, Simon
In-Reply-To: <20131029172331.GA20251-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1752 bytes --]
Hi Mark,
On Tuesday 29 October 2013 10:23:31 Mark Brown wrote:
> On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote:
> > The first one is that I can't compile-test all those drivers on all
> > architectures. The spi-sh-msiof driver, for instance, uses
> > io(read|write)(16|
>
> Which architectures are these and is there not a symbol we can depend on
> for them?
arch/cris for instance. We can use readl/writel instead (maybe it would be
time to rationalize and document the I/O accessors across all architectures,
but that's another topic).
My point is that there might be other issues that I won't be able to easily
catch. This would break compilation for everybody for no reason, as the
drivers are useless on non-SuperH, non-ARM platforms. That's why I believe
COMPILE_TEST would be a better option as a first step.
> > 32) which are not available on all architectures. There might be other
> > similar problems that I can't catch, and I don't want to introduce build
> > breakages in the kernel.
>
> This is easy enough to handle if we do run into issues, it seems better to
> get things available than try to step through architecture by architecture.
>
> > The second reason is that, as the IP cores have never been used on
> > anything but SuperH and ARM, I don't like the idea of clobbering the
> > config process with drivers that are useless on the target architecture.
> > Now that we have a COMPILE_TEST Kconfig option, my preference would thus
> > go to SUPERH || ARM || COMPILE_TEST over no dependency at all.
>
> That's not what you did, though - you're not adding COMPILE_TEST.
No, but I can add it :-) If this gets agreed upon, I'll respin the series with
|| COMPILE_TEST.
--
Regards,
Laurent Pinchart
[-- Attachment #1.2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Mark Brown @ 2013-10-29 17:58 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Linus Walleij,
Guennadi Liakhovetski, Thierry Reding,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Laurent Pinchart, Vinod Koul,
linux-sh-u79uwXL29TY76Z2rM5mHXA, Magnus Damm, Eduardo Valentin,
Tomi Valkeinen, linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Ian Molton, Simon Horman,
linux-arm
In-Reply-To: <1422562.0L87CDt5Gd@avalon>
[-- Attachment #1.1: Type: text/plain, Size: 1213 bytes --]
On Tue, Oct 29, 2013 at 06:29:59PM +0100, Laurent Pinchart wrote:
> On Tuesday 29 October 2013 10:23:31 Mark Brown wrote:
> > On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote:
> > > The first one is that I can't compile-test all those drivers on all
> > > architectures. The spi-sh-msiof driver, for instance, uses
> > > io(read|write)(16|
> > Which architectures are these and is there not a symbol we can depend on
> > for them?
> arch/cris for instance. We can use readl/writel instead (maybe it would be
> time to rationalize and document the I/O accessors across all architectures,
> but that's another topic).
It'd certainly be sensible, or adding a config option to depend on if
you rely on these functions.
> My point is that there might be other issues that I won't be able to easily
> catch. This would break compilation for everybody for no reason, as the
> drivers are useless on non-SuperH, non-ARM platforms. That's why I believe
> COMPILE_TEST would be a better option as a first step.
Yes, it would - please do that. Note that it won't stop anyone running
into build issues on other architectures though, it's just about
stopping Kconfig noise.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* [PATCH v2 00/19] Enable various Renesas drivers on all ARM platforms
From: Laurent Pinchart @ 2013-10-29 22:37 UTC (permalink / raw)
To: linux-sh-u79uwXL29TY76Z2rM5mHXA
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA, Wolfram Sang, Linus Walleij,
Guennadi Liakhovetski, Thierry Reding,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-i2c-u79uwXL29TY76Z2rM5mHXA, Vinod Koul, Magnus Damm,
Eduardo Valentin, Tomi Valkeinen,
linux-serial-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-pwm-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz,
linux-pm-u79uwXL29TY76Z2rM5mHXA, Ian Molton, Mark Brown,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Sergei Shtylyov, Greg
Hello,
This patch series, based on v3.12-rc7, prepares various Renesas drivers
for migration to multiplatform kernels by enabling their compilation or
otherwise fixing them on all ARM platforms. The patches are pretty
straightforward and are described in their commit message.
Changes since v1:
- The drivers can also be selected when COMPILE_TEST is enabled, regardless of
the architecture. This should provide a good compromise between wide build
test coverage and not clobbering configuration with drivers useless on
non-SuperH, non-ARM platforms.
- DMA configuration is now unconditional in patch 08/19
I'd like to get all these patches merged in v3.14. As they will need to go
through their respective subsystems' trees, I would appreciate if all
maintainers involved could notify me when they merge patches from this series
in their tree to help me tracking the merge status. I don't plan to send pull
requests individually for these patches, and I will repost patches
individually if changes are requested during review.
If you believe the issue should be solved in a different way please reply to
the cover letter to let other maintainers chime in.
Cc: Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>
Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
Cc: David Woodhouse <dwmw2-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
Cc: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Eduardo Valentin <eduardo.valentin-l0cyMroinI0@public.gmane.org>
Cc: Greg Kroah-Hartman <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
Cc: Guennadi Liakhovetski <g.liakhovetski+renesas-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Ian Molton <ian-zdned+2MO1+9FHfhHBbuYA@public.gmane.org>
Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
Cc: Jean-Christophe Plagniol-Villard <plagnioj-sclMFOaUSTBWk0Htik3J/w@public.gmane.org>
Cc: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
Cc: Linus Walleij <linus.walleij-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: Magnus Damm <magnus.damm-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Mark Brown <broonie-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Mauro Carvalho Chehab <m.chehab-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org>
Cc: Samuel Ortiz <samuel-jcdQHdrhKHMdnm+yROfE0A@public.gmane.org>
Cc: Sergei Shtylyov <sergei.shtylyov-M4DtvfQ/ZS1MRgGoP+s0PdBPR1lH4CV8@public.gmane.org>
Cc: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: Tomi Valkeinen <tomi.valkeinen-l0cyMroinI0@public.gmane.org>
Cc: Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Wolfram Sang <wsa-z923LK4zBo2bacvFa/9K2g@public.gmane.org>
Cc: Zhang Rui <rui.zhang-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: dmaengine-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-fbdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-media-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Cc: linux-pm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-pwm-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-serial-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: linux-spi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Cc: netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Laurent Pinchart (19):
serial: sh-sci: Enable the driver on all ARM platforms
DMA: shdma: Enable the driver on all ARM platforms
i2c: sh_mobile: Enable the driver on all ARM platforms
input: sh_keysc: Enable the driver on all ARM platforms
iommu: shmobile: Enable the driver on all ARM platforms
i2c: rcar: Enable the driver on all ARM platforms
v4l: sh_vou: Enable the driver on all ARM platforms
mmc: sdhi: Enable the driver on all ARM platforms
mmc: sh_mmcif: Enable the driver on all ARM platforms
mtd: sh_flctl: Enable the driver on all ARM platforms
net: sh_eth: Set receive alignment correctly on all ARM platforms
irda: sh_irda: Enable the driver on all ARM platforms
pinctrl: sh-pfc: Enable the driver on all ARM platforms
pwm: pwm-renesas-tpu: Enable the driver on all ARM platforms
sh: intc: Enable the driver on all ARM platforms
spi: sh_msiof: Enable the driver on all ARM platforms
spi: sh_hspi: Enable the driver on all ARM platforms
thermal: rcar-thermal: Enable the driver on all ARM platforms
fbdev: sh-mobile-lcdcfb: Enable the driver on all ARM platforms
drivers/dma/sh/Kconfig | 2 +-
drivers/dma/sh/shdmac.c | 6 +++---
drivers/i2c/busses/Kconfig | 4 ++--
drivers/input/keyboard/Kconfig | 2 +-
drivers/iommu/Kconfig | 2 +-
drivers/media/platform/Kconfig | 2 +-
drivers/mmc/host/Kconfig | 4 ++--
drivers/mmc/host/tmio_mmc_dma.c | 4 +---
drivers/mtd/nand/Kconfig | 2 +-
drivers/net/ethernet/renesas/sh_eth.c | 2 +-
drivers/net/ethernet/renesas/sh_eth.h | 2 +-
drivers/net/irda/Kconfig | 2 +-
drivers/pinctrl/Makefile | 2 +-
drivers/pinctrl/sh-pfc/Kconfig | 2 +-
drivers/pwm/Kconfig | 2 +-
drivers/sh/intc/Kconfig | 2 +-
drivers/spi/Kconfig | 4 ++--
drivers/thermal/Kconfig | 2 +-
drivers/tty/serial/Kconfig | 2 +-
drivers/video/Kconfig | 6 +++---
20 files changed, 27 insertions(+), 29 deletions(-)
--
Regards,
Laurent Pinchart
^ permalink raw reply
* [PATCH v2 04/19] input: sh_keysc: Enable the driver on all ARM platforms
From: Laurent Pinchart @ 2013-10-29 22:37 UTC (permalink / raw)
To: linux-sh; +Cc: linux-arm-kernel, Dmitry Torokhov, linux-input
In-Reply-To: <1383086274-11049-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
Renesas ARM platforms are transitioning from single-platform to
multi-platform kernels using the new ARCH_SHMOBILE_MULTI. Make the
driver available on all ARM platforms to enable it on both ARCH_SHMOBILE
and ARCH_SHMOBILE_MULTI, and increase build testing coverage with
COMPILE_TEST.
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
---
drivers/input/keyboard/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index c1edd39..28d75c7 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -525,7 +525,7 @@ config KEYBOARD_SUNKBD
config KEYBOARD_SH_KEYSC
tristate "SuperH KEYSC keypad support"
- depends on SUPERH || ARCH_SHMOBILE
+ depends on SUPERH || ARM || COMPILE_TEST
help
Say Y here if you want to use a keypad attached to the KEYSC block
on SuperH processors such as sh7722 and sh7343.
--
1.8.1.5
^ permalink raw reply related
* Re: [PATCH] HID: wiimote: fix inverted pro-controller axes
From: Rafael Brune @ 2013-10-29 23:20 UTC (permalink / raw)
To: David Herrmann; +Cc: open list:HID CORE LAYER, Jiri Kosina, stable
In-Reply-To: <1382978873-802-1-git-send-email-dh.herrmann@gmail.com>
On Oct 28, 2013, at 5:47 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> The analog-stick vertical axes are inverted. Fix that! Otherwise, games
> and other gamepad applications need to carry their own fixups (which they
> thankfully haven't done, yet).
>
> Cc: <stable@vger.kernel.org> # 3.11+
> Reported-by: Rafael Brune <mail@rbrune.de>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Tested-by: Rafael Brune <mail@rbrune.de>
> ---
> drivers/hid/hid-wiimote-modules.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/hid/hid-wiimote-modules.c b/drivers/hid/hid-wiimote-modules.c
> index 71adf9e..e30567a 100644
> --- a/drivers/hid/hid-wiimote-modules.c
> +++ b/drivers/hid/hid-wiimote-modules.c
> @@ -1656,9 +1656,9 @@ static void wiimod_pro_in_ext(struct wiimote_data *wdata, const __u8 *ext)
> ry = (ext[6] & 0xff) | ((ext[7] & 0x0f) << 8);
>
> input_report_abs(wdata->extension.input, ABS_X, lx - 0x800);
> - input_report_abs(wdata->extension.input, ABS_Y, ly - 0x800);
> + input_report_abs(wdata->extension.input, ABS_Y, 0x800 - ly);
> input_report_abs(wdata->extension.input, ABS_RX, rx - 0x800);
> - input_report_abs(wdata->extension.input, ABS_RY, ry - 0x800);
> + input_report_abs(wdata->extension.input, ABS_RY, 0x800 - ry);
>
> input_report_key(wdata->extension.input,
> wiimod_pro_map[WIIMOD_PRO_KEY_RIGHT],
> --
> 1.8.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] HID: wiimote: add pro-controller analog stick calibration
From: Rafael Brune @ 2013-10-29 23:28 UTC (permalink / raw)
To: David Herrmann; +Cc: open list:HID CORE LAYER, Jiri Kosina
In-Reply-To: <1382978960-849-1-git-send-email-dh.herrmann@gmail.com>
On Oct 28, 2013, at 5:49 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
> 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>
> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
Tested-by: Rafael Brune <mail@rbrune.de>
> ---
> Hi Rafael
>
> Could you give this a try? It works for me quite well.
>
> Thanks
> David
Hi David,
also for me it works very well. As much as I don’t like the ‘initialize by first
observed values’ approach, with the capability to change the calibration
values from user-space it’s a simple and good solution.
Also I like the changes of the ‘flat’ values.
We should keep our eyes open if other pro- or third-party controllers
exceed the +/- 0x400 range of values more than our ones. But I think
Nintendo does the calibration very similar and therefore that should not
happen.
Great work!
Regards,
Rafael
>
> Documentation/ABI/testing/sysfs-driver-hid-wiimote | 18 ++++
> drivers/hid/hid-wiimote-modules.c | 117 +++++++++++++++++++--
> drivers/hid/hid-wiimote.h | 2 +
> 3 files changed, 128 insertions(+), 9 deletions(-)
>
> diff --git a/Documentation/ABI/testing/sysfs-driver-hid-wiimote b/Documentation/ABI/testing/sysfs-driver-hid-wiimote
> index ed5dd56..39dfa5c 100644
> --- a/Documentation/ABI/testing/sysfs-driver-hid-wiimote
> +++ b/Documentation/ABI/testing/sysfs-driver-hid-wiimote
> @@ -57,3 +57,21 @@ Description: This attribute is only provided if the device was detected as a
> Calibration data is already applied by the kernel to all input
> values but may be used by user-space to perform other
> transformations.
> +
> +What: /sys/bus/hid/drivers/wiimote/<dev>/pro_calib
> +Date: October 2013
> +KernelVersion: 3.13
> +Contact: David Herrmann <dh.herrmann@gmail.com>
> +Description: This attribute is only provided if the device was detected as a
> + pro-controller. It provides a single line with 4 calibration
> + values for all 4 analog sticks. Format is: "x1:y1 x2:y2". Data
> + is prefixed with a +/-. Each value is a signed 16bit number.
> + Data is encoded as decimal numbers and specifies the offsets of
> + the analog sticks of the pro-controller.
> + Calibration data is already applied by the kernel to all input
> + values but may be used by user-space to perform other
> + transformations.
> + Calibration data is detected by the kernel during device setup.
> + You can write "scan\n" into this file to re-trigger calibration.
> + You can also write data directly in the form "x1:y1 x2:y2" to
> + set the calibration values manually.
> diff --git a/drivers/hid/hid-wiimote-modules.c b/drivers/hid/hid-wiimote-modules.c
> index e30567a..6b61f01 100644
> --- a/drivers/hid/hid-wiimote-modules.c
> +++ b/drivers/hid/hid-wiimote-modules.c
> @@ -1655,10 +1655,39 @@ static void wiimod_pro_in_ext(struct wiimote_data *wdata, const __u8 *ext)
> ly = (ext[4] & 0xff) | ((ext[5] & 0x0f) << 8);
> ry = (ext[6] & 0xff) | ((ext[7] & 0x0f) << 8);
>
> - input_report_abs(wdata->extension.input, ABS_X, lx - 0x800);
> - input_report_abs(wdata->extension.input, ABS_Y, 0x800 - ly);
> - input_report_abs(wdata->extension.input, ABS_RX, rx - 0x800);
> - input_report_abs(wdata->extension.input, ABS_RY, 0x800 - ry);
> + /* zero-point offsets */
> + lx -= 0x800;
> + ly = 0x800 - ly;
> + rx -= 0x800;
> + ry = 0x800 - ry;
> +
> + /* Trivial automatic calibration. We don't know any calibration data
> + * in the EEPROM so we must use the first report to calibrate the
> + * null-position of the analog sticks. Users can retrigger calibration
> + * via sysfs, or set it explicitly. If data is off more than abs(500),
> + * we skip calibration as the sticks are likely to be moved already. */
> + if (!(wdata->state.flags & WIIPROTO_FLAG_PRO_CALIB_DONE)) {
> + wdata->state.flags |= WIIPROTO_FLAG_PRO_CALIB_DONE;
> + if (abs(lx) < 500)
> + wdata->state.calib_pro_sticks[0] = -lx;
> + if (abs(ly) < 500)
> + wdata->state.calib_pro_sticks[1] = -ly;
> + if (abs(rx) < 500)
> + wdata->state.calib_pro_sticks[2] = -rx;
> + if (abs(ry) < 500)
> + wdata->state.calib_pro_sticks[3] = -ry;
> + }
> +
> + /* apply calibration data */
> + lx += wdata->state.calib_pro_sticks[0];
> + ly += wdata->state.calib_pro_sticks[1];
> + rx += wdata->state.calib_pro_sticks[2];
> + ry += wdata->state.calib_pro_sticks[3];
> +
> + input_report_abs(wdata->extension.input, ABS_X, lx);
> + input_report_abs(wdata->extension.input, ABS_Y, ly);
> + input_report_abs(wdata->extension.input, ABS_RX, rx);
> + input_report_abs(wdata->extension.input, ABS_RY, ry);
>
> input_report_key(wdata->extension.input,
> wiimod_pro_map[WIIMOD_PRO_KEY_RIGHT],
> @@ -1766,12 +1795,70 @@ static int wiimod_pro_play(struct input_dev *dev, void *data,
> return 0;
> }
>
> +static ssize_t wiimod_pro_calib_show(struct device *dev,
> + struct device_attribute *attr,
> + char *out)
> +{
> + struct wiimote_data *wdata = dev_to_wii(dev);
> + int r;
> +
> + r = 0;
> + r += sprintf(&out[r], "%+06hd:", wdata->state.calib_pro_sticks[0]);
> + r += sprintf(&out[r], "%+06hd ", wdata->state.calib_pro_sticks[1]);
> + r += sprintf(&out[r], "%+06hd:", wdata->state.calib_pro_sticks[2]);
> + r += sprintf(&out[r], "%+06hd\n", wdata->state.calib_pro_sticks[3]);
> +
> + return r;
> +}
> +
> +static ssize_t wiimod_pro_calib_store(struct device *dev,
> + struct device_attribute *attr,
> + const char *buf, size_t count)
> +{
> + struct wiimote_data *wdata = dev_to_wii(dev);
> + int r;
> + s16 x1, y1, x2, y2;
> +
> + if (!strncmp(buf, "scan\n", 5)) {
> + spin_lock_irq(&wdata->state.lock);
> + wdata->state.flags &= ~WIIPROTO_FLAG_PRO_CALIB_DONE;
> + spin_unlock_irq(&wdata->state.lock);
> + } else {
> + r = sscanf(buf, "%hd:%hd %hd:%hd", &x1, &y1, &x2, &y2);
> + if (r != 4)
> + return -EINVAL;
> +
> + spin_lock_irq(&wdata->state.lock);
> + wdata->state.flags |= WIIPROTO_FLAG_PRO_CALIB_DONE;
> + spin_unlock_irq(&wdata->state.lock);
> +
> + wdata->state.calib_pro_sticks[0] = x1;
> + wdata->state.calib_pro_sticks[1] = y1;
> + wdata->state.calib_pro_sticks[2] = x2;
> + wdata->state.calib_pro_sticks[3] = y2;
> + }
> +
> + return strnlen(buf, PAGE_SIZE);
> +}
> +
> +static DEVICE_ATTR(pro_calib, S_IRUGO|S_IWUSR|S_IWGRP, wiimod_pro_calib_show,
> + wiimod_pro_calib_store);
> +
> static int wiimod_pro_probe(const struct wiimod_ops *ops,
> struct wiimote_data *wdata)
> {
> int ret, i;
> + unsigned long flags;
>
> INIT_WORK(&wdata->rumble_worker, wiimod_rumble_worker);
> + wdata->state.calib_pro_sticks[0] = 0;
> + wdata->state.calib_pro_sticks[1] = 0;
> + wdata->state.calib_pro_sticks[2] = 0;
> + wdata->state.calib_pro_sticks[3] = 0;
> +
> + spin_lock_irqsave(&wdata->state.lock, flags);
> + wdata->state.flags &= ~WIIPROTO_FLAG_PRO_CALIB_DONE;
> + spin_unlock_irqrestore(&wdata->state.lock, flags);
>
> wdata->extension.input = input_allocate_device();
> if (!wdata->extension.input)
> @@ -1786,6 +1873,13 @@ static int wiimod_pro_probe(const struct wiimod_ops *ops,
> goto err_free;
> }
>
> + ret = device_create_file(&wdata->hdev->dev,
> + &dev_attr_pro_calib);
> + if (ret) {
> + hid_err(wdata->hdev, "cannot create sysfs attribute\n");
> + goto err_free;
> + }
> +
> wdata->extension.input->open = wiimod_pro_open;
> wdata->extension.input->close = wiimod_pro_close;
> wdata->extension.input->dev.parent = &wdata->hdev->dev;
> @@ -1806,20 +1900,23 @@ static int wiimod_pro_probe(const struct wiimod_ops *ops,
> set_bit(ABS_RX, wdata->extension.input->absbit);
> set_bit(ABS_RY, wdata->extension.input->absbit);
> input_set_abs_params(wdata->extension.input,
> - ABS_X, -0x800, 0x800, 2, 4);
> + ABS_X, -0x400, 0x400, 4, 100);
> input_set_abs_params(wdata->extension.input,
> - ABS_Y, -0x800, 0x800, 2, 4);
> + ABS_Y, -0x400, 0x400, 4, 100);
> input_set_abs_params(wdata->extension.input,
> - ABS_RX, -0x800, 0x800, 2, 4);
> + ABS_RX, -0x400, 0x400, 4, 100);
> input_set_abs_params(wdata->extension.input,
> - ABS_RY, -0x800, 0x800, 2, 4);
> + ABS_RY, -0x400, 0x400, 4, 100);
>
> ret = input_register_device(wdata->extension.input);
> if (ret)
> - goto err_free;
> + goto err_file;
>
> return 0;
>
> +err_file:
> + device_remove_file(&wdata->hdev->dev,
> + &dev_attr_pro_calib);
> err_free:
> input_free_device(wdata->extension.input);
> wdata->extension.input = NULL;
> @@ -1837,6 +1934,8 @@ static void wiimod_pro_remove(const struct wiimod_ops *ops,
> input_unregister_device(wdata->extension.input);
> wdata->extension.input = NULL;
> cancel_work_sync(&wdata->rumble_worker);
> + device_remove_file(&wdata->hdev->dev,
> + &dev_attr_pro_calib);
>
> spin_lock_irqsave(&wdata->state.lock, flags);
> wiiproto_req_rumble(wdata, 0);
> diff --git a/drivers/hid/hid-wiimote.h b/drivers/hid/hid-wiimote.h
> index 75db0c4..03065f1 100644
> --- a/drivers/hid/hid-wiimote.h
> +++ b/drivers/hid/hid-wiimote.h
> @@ -46,6 +46,7 @@
> #define WIIPROTO_FLAG_DRM_LOCKED 0x8000
> #define WIIPROTO_FLAG_BUILTIN_MP 0x010000
> #define WIIPROTO_FLAG_NO_MP 0x020000
> +#define WIIPROTO_FLAG_PRO_CALIB_DONE 0x040000
>
> #define WIIPROTO_FLAGS_LEDS (WIIPROTO_FLAG_LED1 | WIIPROTO_FLAG_LED2 | \
> WIIPROTO_FLAG_LED3 | WIIPROTO_FLAG_LED4)
> @@ -135,6 +136,7 @@ struct wiimote_state {
>
> /* calibration/cache data */
> __u16 calib_bboard[4][3];
> + __s16 calib_pro_sticks[4];
> __u8 cache_rumble;
> };
>
> --
> 1.8.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-input" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Simon Horman @ 2013-10-30 0:05 UTC (permalink / raw)
To: Mark Brown
Cc: linux-fbdev, Wolfram Sang, Linus Walleij, Guennadi Liakhovetski,
Thierry Reding, linux-mtd, Laurent Pinchart, Laurent Pinchart,
Vinod Koul, Joerg Roedel, linux-sh, Magnus Damm, Eduardo Valentin,
Tomi Valkeinen, linux-serial, linux-input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media, linux-pwm,
Samuel Ortiz, linux-pm, Ian Molton
In-Reply-To: <20131029175834.GD20251@sirena.org.uk>
On Tue, Oct 29, 2013 at 10:58:34AM -0700, Mark Brown wrote:
> On Tue, Oct 29, 2013 at 06:29:59PM +0100, Laurent Pinchart wrote:
> > On Tuesday 29 October 2013 10:23:31 Mark Brown wrote:
> > > On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote:
> > > > The first one is that I can't compile-test all those drivers on all
> > > > architectures. The spi-sh-msiof driver, for instance, uses
> > > > io(read|write)(16|
>
> > > Which architectures are these and is there not a symbol we can depend on
> > > for them?
>
> > arch/cris for instance. We can use readl/writel instead (maybe it would be
> > time to rationalize and document the I/O accessors across all architectures,
> > but that's another topic).
>
> It'd certainly be sensible, or adding a config option to depend on if
> you rely on these functions.
>
> > My point is that there might be other issues that I won't be able to easily
> > catch. This would break compilation for everybody for no reason, as the
> > drivers are useless on non-SuperH, non-ARM platforms. That's why I believe
> > COMPILE_TEST would be a better option as a first step.
>
> Yes, it would - please do that. Note that it won't stop anyone running
> into build issues on other architectures though, it's just about
> stopping Kconfig noise.
FWIW, I am happy with using COMPILE_TEST for this series.
^ permalink raw reply
* Re: [PATCH V4 1/2] tps6507x-ts: Add DT support
From: Manish Badarkhe @ 2013-10-30 3:30 UTC (permalink / raw)
To: Mark Rutland
Cc: devicetree-discuss@lists.ozlabs.org, devicetree@vger.kernel.org,
linux-input@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com,
grant.likely@secretlab.ca, dmitry.torokhov@gmail.com,
rob.herring@calxeda.com, rob@landley.net
In-Reply-To: <20131024172734.GB2461@kartoffel>
Hi Mark,
Apologize for my late reply.
On Thu, Oct 24, 2013 at 10:57 PM, Mark Rutland <mark.rutland@arm.com> wrote:
>
> On Thu, Oct 24, 2013 at 06:05:53PM +0100, Manish Badarkhe wrote:
> > Hi Mark,
> >
> > Thank you for your reply.
> >
> > On Wed, Oct 23, 2013 at 10:15 PM, Mark Rutland <mark.rutland@arm.com> wrote:
> >
> > On Wed, Oct 23, 2013 at 05:28:52PM +0100, Manish Badarkhe wrote:
> > > Add device tree based support for TI's tps6507x touchscreen.
> > >
> > > Signed-off-by: Manish Badarkhe <badarkhe.manish@gmail.com>
> > > ---
> > > Changes since V3:
> > > - Rebased on top of Dmitry's changes
> > > - Removed error handling for optional DT properties
> > >
> > > Changes since V2:
> > > - Removed unnecessary code.
> > > - Updated Documentation to provide proper names of
> > > devicetree properties.
> > >
> > > Changes since V1:
> > > - Updated documentation to specify tps6507x as multifunctional
> > > device.
> > > - return proper error value in absence of platform and DT
> > > data for touchscreen.
> > > - Updated commit message.
> > >
> > > :100755 100755 8fffa3c... e1b9cfd... M Documentation/devicetree/
> > bindings/mfd/tps6507x.txt
> > > :100644 100644 db604e0... 0cf0eb1... M drivers/input/touchscreen/
> > tps6507x-ts.c
> > > Documentation/devicetree/bindings/mfd/tps6507x.txt | 24 ++++++-
> > > drivers/input/touchscreen/tps6507x-ts.c | 72
> > ++++++++++++--------
> > > 2 files changed, 67 insertions(+), 29 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/mfd/tps6507x.txt b/
> > Documentation/devicetree/bindings/mfd/tps6507x.txt
> > > index 8fffa3c..e1b9cfd 100755
> > > --- a/Documentation/devicetree/bindings/mfd/tps6507x.txt
> > > +++ b/Documentation/devicetree/bindings/mfd/tps6507x.txt
> > > @@ -1,4 +1,8 @@
> > > -TPS6507x Power Management Integrated Circuit
> > > +TPS6507x Multifunctional Device.
> > > +
> > > +Features provided by TPS6507x:
> > > + 1.Power Management Integrated Circuit.
> > > + 2.Touch-Screen.
> > >
> > > Required properties:
> > > - compatible: "ti,tps6507x"
> > > @@ -23,6 +27,9 @@ Required properties:
> > > vindcdc1_2-supply: VDCDC1 and VDCDC2 input.
> > > vindcdc3-supply : VDCDC3 input.
> > > vldo1_2-supply : VLDO1 and VLDO2 input.
> > > +- tsc: This node specifies touch screen data.
> >
> > This is a node, but is listed un "Required properties". That seems odd.
> >
> > When is it required?
> >
> > Why is the data under the tsc subnode? Why not directly under the main
> > node?
> >
> >
> > Yes, It seems odd to add a subnode properties here. I gone through other
> > documentation
> > for MFD devices and observed that separate documentation file is present for
> > sub node modules.
>
> I was trying to say that nodes != properties rather than that this should be
> split into separate files.
>
Ok, got it.I will modify documentation so that only properties comes
under "required
properties" section.
>
> >
> > TPS6507x is multifunctional device and having touch screen submodule. As it is
> > child node for
> > TPS6507x multifunctional device, I have created child node as "tsc".
> >
> >
> >
> > > + ti,poll-period : Time at which touch input is getting sampled in
> > ms.
> >
> > Is this for debounce? Other bindings have similar but differently named
> > properties.
> >
> >
> > This is not debounce time. This time is required for input poll devices.
> >
> >
> > Why is this necessary? Can the driver not choose a sane value?
> >
> >
> > poll-period is necessary to sample touch inputs. Driver will chose value
> > default poll
> > period if this value is not present. I was bit confused here, whether to add
> > this property
> > as optional or required. As with default period touch not achieve performance.
> > Can I make this property optional?
>
> Please elaborate. Why will the default period be sub-optimal? What's the
> tradeoff here?
Currently, default period and period passed from Device tree both
are same.I made an assumption here, if default period is less then
touch get sampled faster and report it to upper layer.As I am not I
will make this confirm with Texas instrument's engineers.
>
> >
> >
> > > + ti,min-pressure: Minimum pressure value to trigger touch.
> >
> > What type are these? Single (u32) cells?
> >
> > What units is ti,min-pressure in?
> >
> >
> > No, its a u16 cell. It is measured in ohm. Again default value for min-pressure
> > is available
> > in driver code. Can I make this property optional?
>
> Why is it a u16, it's very uncommon to have u16 properties.
>
> What _physical_ units is this in, and what order of magnitude? e.g. Pascals,
> millipascals.
>
I gone through data sheet but not able to find any units for this
pressure field.
As per data sheet, we read pressure values from two ADC result
registers and these two registers are 8 bit long and hence provide
totally 16 bit pressure value.
>
> >
> >
> > >
> > > Regulator Optional properties:
> > > - defdcdc_default: It's property of DCDC2 and DCDC3 regulators.
> > > @@ -30,6 +37,14 @@ Regulator Optional properties:
> > > 1: If defdcdc pin of DCDC2/DCDC3 is driven HIGH.
> > > If this property is not defined, it defaults to 0 (not enabled).
> > >
> > > +Touchscreen Optional properties:
> > > +- ti,vendor : Touchscreen vendor id to populate
> > > + in sysclass interface.
> > > +- ti,product: Touchscreen product id to populate
> > > + in sysclass interface.
> > > +- ti,version: Touchscreen version id to populate
> > > + in sysclass interface.
> >
> > Are these integers, strings, or something else?
> >
> >
> > These are unsigned short(u16) values.
>
> Why?
>
Not much sure why this field is u16. I just referred a platform
data which mentioned field as u16 and accordingly add a DT
property. I am not seeing any harm to make this property u32.
I will make this property as u32.
>
>
>
> >
> >
> > What values make sense?
> >
> >
> > These values are only to tell about chip details.
>
>
> That does not describe the set of valid values.
>
> Is ti,vendor = <4> valid? What does this mean?
>
> Is there some standard for assignment of vendor IDs that this follows?
>
As, these are numeric values, not sure about standard assignment
of these field. For DT properties, I used these field same as from
platform data of touch screen driver.
I will make sure about this Texas Instrument's engineers.
> >
> >
> > What's the sysclass interface? That sounds like a Linux detail. The
> > properties
> > might be fine but the description shouldn't need to refer to Linux
> > internals.
> >
> >
> > Okay, I will update description for these properties.
> >
> >
> > > +
> > > Example:
> > >
> > > pmu: tps6507x@48 {
> > > @@ -88,4 +103,11 @@ Example:
> > > };
> > > };
> > >
> > > + tsc {
> > > + ti,poll-period = <30>;
> > > + ti,min-pressure = <0x30>;
> > > + ti,vendor = <0>;
> > > + ti,product = <65070>;
> > > + ti,version = <0x100>;
> > > + };
> > > };
> > > diff --git a/drivers/input/touchscreen/tps6507x-ts.c b/drivers/input/
> > touchscreen/tps6507x-ts.c
> > > index db604e0..0cf0eb1 100644
> > > --- a/drivers/input/touchscreen/tps6507x-ts.c
> > > +++ b/drivers/input/touchscreen/tps6507x-ts.c
> > > @@ -22,6 +22,8 @@
> > > #include <linux/mfd/tps6507x.h>
> > > #include <linux/input/tps6507x-ts.h>
> > > #include <linux/delay.h>
> > > +#include <linux/of.h>
> > > +#include <linux/of_device.h>
> > >
> > > #define TSC_DEFAULT_POLL_PERIOD 30 /* ms */
> > > #define TPS_DEFAULT_MIN_PRESSURE 0x30
> > > @@ -206,33 +208,54 @@ done:
> > > tps6507x_adc_standby(tsc);
> > > }
> > >
> > > +static void tsc_init_data(struct tps6507x_ts *tsc,
> > > + struct input_dev *input_dev)
> > > +{
> > > + struct device_node *node = tsc->dev->of_node;
> > > + const struct tps6507x_board *tps_board =
> > > + dev_get_platdata(tsc->dev);
> > > + const struct touchscreen_init_data *init_data = NULL;
> > > +
> > > + if (node)
> > > + node = of_find_node_by_name(node, "tsc");
> >
> > As of_find_node_by_name traverses the list of all nodes (not just
> > children),
> > this may match nodes other than what you expect.
> >
> >
> > I think, It traverse nodes from parent node (i.e. tps6507x) and find child.
> > Please correct me if I am wrong?
>
> No. As I said, it traverses the list of all nodes. Is there is no matching
> child, it will go on and possibly match a node that is not a direct child (e.g.
> a child of another node).
>
> Perhaps of_get_child_by_name is what you want.
Got it, I will change this to "of_get_child_by_name".
>
> >
> >
> >
> > > + if (tps_board)
> > > + /*
> > > + * init_data points to array of touchscreen_init structure
> > > + * coming from the board-evm file.
> > > + */
> > > + init_data = tps_board->tps6507x_ts_init_data;
> > > +
> > > + if (node == NULL || init_data == NULL) {
> > > + tsc->poll_dev->poll_interval = TSC_DEFAULT_POLL_PERIOD;
> > > + tsc->min_pressure = TPS_DEFAULT_MIN_PRESSURE;
> > > + } else if (init_data) {
> > > + tsc->poll_dev->poll_interval = init_data->poll_period;
> > > + tsc->min_pressure = init_data->min_pressure;
> > > + input_dev->id.vendor = init_data->vendor;
> > > + input_dev->id.product = init_data->product;
> > > + input_dev->id.version = init_data->version;
> > > + } else if (node) {
> > > + of_property_read_u32(node, "ti,poll-period",
> > > + &tsc->poll_dev->poll_interval);
> > > + of_property_read_u16(node, "ti,min-pressure",
> > > + &tsc->min_pressure);
> >
> > You didn't mention these were 16-bit values in the binding.
> >
> > As DTB is encoded big-endian, and you didn't use a /bits/ 16 declaration
> > (making the property a u32 cell), won't this read 0 in all cases you have a
> > value in the expected range (as in your example)?
> >
> >
> > I will mention these values as 16bit. values in binding.
>
> Please explain _why_ they are 16-bit values. Even if they are 16-bit it may
> make sense to have them as u32 values for general consistency and least
> surprise.
Similarly as above, I just referred a platform data which mentioned
this field as u16 and accordingly add a DT property for same.
I am not seeing any harm to make this property u32. I will make this
property u32.
Regards
Manish Badarkhe
^ permalink raw reply
* Re: [PATCH] HID: wiimote: add pro-controller analog stick calibration
From: David Herrmann @ 2013-10-30 7:54 UTC (permalink / raw)
To: Rafael Brune; +Cc: open list:HID CORE LAYER, Jiri Kosina
In-Reply-To: <7969D126-74F7-4B91-9B5C-213AC76B3A66@rbrune.de>
Hi Rafael
On Wed, Oct 30, 2013 at 12:28 AM, Rafael Brune <mail@rbrune.de> wrote:
>
> On Oct 28, 2013, at 5:49 PM, David Herrmann <dh.herrmann@gmail.com> wrote:
>
>> 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>
>> Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>
> Tested-by: Rafael Brune <mail@rbrune.de>
>
>> ---
>> Hi Rafael
>>
>> Could you give this a try? It works for me quite well.
>>
>> Thanks
>> David
>
> Hi David,
>
> also for me it works very well. As much as I don’t like the ‘initialize by first
> observed values’ approach, with the capability to change the calibration
> values from user-space it’s a simple and good solution.
> Also I like the changes of the ‘flat’ values.
> We should keep our eyes open if other pro- or third-party controllers
> exceed the +/- 0x400 range of values more than our ones. But I think
> Nintendo does the calibration very similar and therefore that should not
> happen.
> Great work!
Thanks for testing! I am no big fan of this approach either. However,
it has the advantage that we can adjust the internal handling at any
time without affecting the outside. Problem with the min/max approach
is that it returns garbage until the first real *far* analog-movement.
I was thinking of a more advanced state-machine, but could not come up
with a good approach (neither do I have motivation and time to do some
more thorough research). I am willing to implement any extensions if
some-one has good ideas. But I'd like to see it added to "xwiishow"
first, so I can verify it works well. If it does, we can move it into
the hid-wiimote driver in the kernel.
Furthermore, in case anyone finds out the EEPROM calib-storage, we can
easily adjust the kernel driver to read it from there.
@Jiri: I marked the sysfs-docs as 3.13. If it doesn't make it into the
next merge-window, I can resend it marked as 3.14.
Thanks for the report and testing!
David
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Tomi Valkeinen @ 2013-10-30 10:59 UTC (permalink / raw)
To: Simon Horman, Mark Brown, Laurent Pinchart
Cc: linux-fbdev, Wolfram Sang, Linus Walleij, Guennadi Liakhovetski,
Thierry Reding, linux-mtd, linux-i2c, Laurent Pinchart,
Vinod Koul, Joerg Roedel, linux-sh, Magnus Damm, Eduardo Valentin,
linux-serial, linux-input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media, linux-pwm,
Samuel Ortiz, linux-pm, Ian Molton, linux-arm-kernel, Sergei
In-Reply-To: <20131030000501.GE21262@verge.net.au>
[-- Attachment #1.1: Type: text/plain, Size: 1640 bytes --]
On 2013-10-30 02:05, Simon Horman wrote:
> On Tue, Oct 29, 2013 at 10:58:34AM -0700, Mark Brown wrote:
>> On Tue, Oct 29, 2013 at 06:29:59PM +0100, Laurent Pinchart wrote:
>>> On Tuesday 29 October 2013 10:23:31 Mark Brown wrote:
>>>> On Tue, Oct 29, 2013 at 06:05:53PM +0100, Laurent Pinchart wrote:
>>>>> The first one is that I can't compile-test all those drivers on all
>>>>> architectures. The spi-sh-msiof driver, for instance, uses
>>>>> io(read|write)(16|
>>
>>>> Which architectures are these and is there not a symbol we can depend on
>>>> for them?
>>
>>> arch/cris for instance. We can use readl/writel instead (maybe it would be
>>> time to rationalize and document the I/O accessors across all architectures,
>>> but that's another topic).
>>
>> It'd certainly be sensible, or adding a config option to depend on if
>> you rely on these functions.
>>
>>> My point is that there might be other issues that I won't be able to easily
>>> catch. This would break compilation for everybody for no reason, as the
>>> drivers are useless on non-SuperH, non-ARM platforms. That's why I believe
>>> COMPILE_TEST would be a better option as a first step.
>>
>> Yes, it would - please do that. Note that it won't stop anyone running
>> into build issues on other architectures though, it's just about
>> stopping Kconfig noise.
>
> FWIW, I am happy with using COMPILE_TEST for this series.
I'd also go for COMPILE_TEST. I once enabled omapdss and omapfb to be
compilable without any extra dependencies, and Linus wasn't fond of
getting asked if he wants to compile omapfb or not...
Tomi
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]
[-- Attachment #2: Type: text/plain, Size: 144 bytes --]
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH] HID: wiimote: fix inverted pro-controller axes
From: Jiri Kosina @ 2013-10-30 13:15 UTC (permalink / raw)
To: Rafael Brune; +Cc: David Herrmann, open list:HID CORE LAYER, stable
In-Reply-To: <1530A042-4C08-422E-A162-2057D250D325@rbrune.de>
On Wed, 30 Oct 2013, Rafael Brune wrote:
> > The analog-stick vertical axes are inverted. Fix that! Otherwise, games
> > and other gamepad applications need to carry their own fixups (which they
> > thankfully haven't done, yet).
> >
> > Cc: <stable@vger.kernel.org> # 3.11+
> > Reported-by: Rafael Brune <mail@rbrune.de>
> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
> Tested-by: Rafael Brune <mail@rbrune.de>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: wiimote: add pro-controller analog stick calibration
From: Jiri Kosina @ 2013-10-30 13:15 UTC (permalink / raw)
To: Rafael Brune; +Cc: David Herrmann, open list:HID CORE LAYER
In-Reply-To: <7969D126-74F7-4B91-9B5C-213AC76B3A66@rbrune.de>
On Wed, 30 Oct 2013, Rafael Brune wrote:
> > 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>
> > Signed-off-by: David Herrmann <dh.herrmann@gmail.com>
>
> Tested-by: Rafael Brune <mail@rbrune.de>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/3] HID: roccat: Added new device return value
From: Jiri Kosina @ 2013-10-30 13:18 UTC (permalink / raw)
To: Stefan Achatz; +Cc: Rob Landley, linux-doc, linux-kernel, linux-input
In-Reply-To: <1382982723.2453.9.camel@neuromancer.tessier-ashpool>
On Mon, 28 Oct 2013, Stefan Achatz wrote:
> Ryos uses a new return value for critical errors, others have been
> confirmed.
>
> Signed-off-by: Stefan Achatz <erazor_de@users.sourceforge.net>
I have applied all 3 patches. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Stop querying for init reports
From: Jiri Kosina @ 2013-10-30 13:24 UTC (permalink / raw)
To: Bibek Basu; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <1382329753-15589-1-git-send-email-bbasu@nvidia.com>
On Mon, 21 Oct 2013, Bibek Basu wrote:
> According to specifications, HID over I2C devices
> are not bound to respond to query for INPUT
> REPORTS. Thus dropping the call during init
> as many devices does not respond causing error
> messages during boot.
>
> Signed-off-by: Bibek Basu <bbasu@nvidia.com>
I am queuing this for 3.13. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: hid-sensor-hub: fix report size
From: Jiri Kosina @ 2013-10-30 13:27 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: linux-input
In-Reply-To: <1382807049-28478-1-git-send-email-srinivas.pandruvada@linux.intel.com>
On Sat, 26 Oct 2013, Srinivas Pandruvada wrote:
> Most of the hid sensor field size is reported in report_size field
> in the report descriptor. For rotation fusion sensor the quaternion
> data is 16 byte field, the report size was set to 4 and report
> count field is set to 4. So the total size is 16 bytes. But the current
> driver has a bug and not taking account for report count field. This
> causes user space to see only 4 bytes of data sent via IIO interface.
> The number of bytes in a field needs to take account of report_count
> field. Need to multiply report_size and report_count to get total
> number of bytes.
>
> Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Thanks, applied.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* changes to ati_remote to support ATI Remote Wonder Plus RF Remote Control
From: Stephen Oberski @ 2013-10-30 13:37 UTC (permalink / raw)
To: linux-input; +Cc: sfo
[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]
Originally sent this Fri, October 25, 2013 9:19 am but it did not seem to make it onto the list.
--
Stephen Oberski sfo@cargocult.ca
289 430 5076
http://ca.linkedin.com/in/stephenoberski/
Attached is a text document describing proposed changes to the ati_remote kernel module to support
the ATI Remote Wonder Plus RF Remote Control.
I've forwarded these proposed changes to the listed authors of the module for review (Anssi
Hannula <anssi.hannula@XXX.YYY> and Torrey Hoffman <thoffman@XXX.YYY>) and have not heard back
from Anssi Hannul and I include Torrey Hoffman's response below.
Thanks,
--
Stephen Oberski sfo@cargocult.ca
289 430 5076
http://ca.linkedin.com/in/stephenoberski/
---------------------------------------- Original Message ----------------------------------------
Subject: Re: [Fwd: changes to ati_remote to support ATI Remote Wonder Plus RF Remote Control]
From: "Torrey Hoffman" <thoffman@XXX.YYY>
Date: Mon, October 21, 2013 12:21 pm
To: sfo@cargocult.ca
--------------------------------------------------------------------------------------------------
Thanks for the heads up, and for working on this.
Unfortunately I no longer have any relevant hardware to test with. If you would like to be the
official maintainer of this module, that would be excellent.
Best wishes,
Torrey
On Mon, Oct 21, 2013 at 5:18 PM, Stephen Oberski <sfo@cargocult.ca> wrote:
> Hi Torrey,
>
> Attached is a text document describing proposed changes to the ati_remote kernel module to support
> the ATI Remote Wonder Plus RF Remote Control.
>
> I am sending this to you as the author of the module before posting to the linux-input mailing
> list and would appreciate any feedback.
>
> Thanks,
>
> --
> Stephen Oberski sfo@cargocult.ca
> 289 430 5076
> http://ca.linkedin.com/in/stephenoberski/
>
>
> ---------------------------------------- Original Message
> ----------------------------------------
> Subject: changes to ati_remote to support ATI Remote Wonder Plus RF Remote
> Control
> From: "Stephen Oberski" <sfo@cargocult.ca>
> Date: Sat, October 12, 2013 9:53 pm
> To: anssi.hannula@XXX.YYY
> Cc: sfo@cargocult.ca
>
> --------------------------------------------------------------------------------------------------
>
> Hi Anssi,
>
> Attached is a text document describing proposed changes to the ati_remote kernel module to support
> the ATI Remote Wonder Plus RF Remote Control.
>
> I am sending this to you as the author of the module before posting to the linux-input mailing
> list and would appreciated any feedback.
>
> Thanks,
>
> --
> Stephen Oberski sfo@cargocult.ca
> 289 430 5076
>
[-- Attachment #2: linux-input_ati_remote-problem.txt --]
[-- Type: text/plain, Size: 12887 bytes --]
Proposed changes to the ati_remote kernel loadable module (drivers/media/rc/ati_remote.c) to support the ATI Remote Wonder Plus RF Remote Control
-------------------------------------------------------------------------------------------------------------------------------------------------
Date: Thu Oct 10 10:53:59 EDT 2013
By: Stephen Oberski (sfo@cargocult.ca)
Overview
========
The ati_remote.c USB ATI Remote support loadable kernel module (Version 2.2.0, Linux 3.8.0-31-generic)
supports the SnapStream Media Firefly PC Remote Wireless Receiver Model R1000-1 receiver (FF receiver) with the Firefly RF Remote Control Model R1000 (FF remote).
It also supports the ATI USB RF Wireless Remote Receiver Part # 5000027000G receiver (ATI receiver) with the Firefly RF Remote Control Model R1000.
However neither the SnapStream Media Firefly PC Remote Wireless Receiver Model R1000-1 receiver nor the ATI USB RF Wireless Remote Receiver Part # 5000027000G receiver
are supported with the ATI Remote Wonder Plus RF Remote Control Part # 5000026900G (ATI remote).
A simple change to the ati_remote.c module results in the support of all combinations of the FF and ATI RF receivers and remotes.
The RF receiver initialization sequence is modified and the processing of the 4 byte remote inputs by the driver is modified to support a leading byte value of 0x15 as well as the current 0x14.
These changes appear to be backward compatible and do no seem to impact the existing behaviour of the module when presented with data from currently supported RF receiver and remote combinations
while allowing currently unsupported combinations to be used.
Problem Scope
=============
It appears that data generated by the ATI remote is never being received by the ati_remote kernel module:
============================== CUT HERE ==============================
# terminal window 1
# modprobe usbmon
# cd /sys/kernel/debug/usb/usbmon
# lsusb
...
Bus 004 Device 008: ID 0bc7:0004 X10 Wireless Technology, Inc. X10 Receiver
...
# rmmod ati_remote
# modprobe ati_remote
# terminal window 2
# grep --line-buffered '4:008' 4u
ffff88018a00d3c0 1361036384 C Ii:4:008:1 -108:8 0
ffff88018a00d240 1385420709 S Io:4:008:2 -115:8 5 = 80010020 14
ffff88018a00d240 1385424393 C Io:4:008:2 0:8 5 >
ffff88018a00d240 1385424401 S Io:4:008:2 -115:8 8 = 80010020 14202020
ffff88018a00d240 1385432392 C Io:4:008:2 0:8 8 >
ffff88018a00da80 1385432519 S Ii:4:008:1 -115:8 8 <
ffff88018a00da80 1385440394 C Ii:4:008:1 0:8 1 = ff
ffff88018a00da80 1385440399 S Ii:4:008:1 -115:8 8 <
ffff88018a00da80 1415136406 C Ii:4:008:1 0:8 4 = 14658010
ffff88018a00da80 1415136432 S Ii:4:008:1 -115:8 8 <
ffff88018a00da80 1415176406 C Ii:4:008:1 0:8 4 = 14658010
ffff88018a00da80 1415176413 S Ii:4:008:1 -115:8 8 <
ffff88018a00da80 1415216405 C Ii:4:008:1 0:8 4 = 14658010
ffff88018a00da80 1415216411 S Ii:4:008:1 -115:8 8 <
ffff88018a00da80 1415256404 C Ii:4:008:1 0:8 4 = 14658010
ffff88018a00da80 1415256410 S Ii:4:008:1 -115:8 8 <
ffff88018a00da80 1415296405 C Ii:4:008:1 0:8 4 = 14658010
ffff88018a00da80 1415296412 S Ii:4:008:1 -115:8 8 <
ffff88018a00da80 1415336404 C Ii:4:008:1 0:8 4 = 14658010
ffff88018a00da80 1415336410 S Ii:4:008:1 -115:8 8 <
============================== CUT HERE ==============================
We log USB data for the RF receiver in window 2.
In window 1 we enable USB monitoring and unload and reload the ati_remote module.
We can see the 2 initialization strings being sent to the RF receiver via the interrupt out (Io) lines
and then when we press the Firefly key on the FF remote we see the repeated USB packets sent by the RF remote (14658010).
However when we press any keys on the ATI remote no data is logged by usbmon.
This indicates that the RF receiver is ignoring data sent by the ATI remote when initialized by the ati_remote modules.
However when we load the modified version of the ati_remote module we see:
============================== CUT HERE ==============================
# rmmod ati_remote
# insmod ./ati_remote_plus.ko
# grep --line-buffered '4:008' 4u
ffff88018a00da80 2183228699 C Ii:4:008:1 -108:8 0
ffff880181305a80 2197203596 S Io:4:008:2 -115:8 9 = 8080051b 15142024 15
ffff880181305a80 2197216703 C Io:4:008:2 0:8 9 >
ffff880181305a80 2197216761 S Io:4:008:2 -115:8 3 = 808303
ffff880181305a80 2197224702 C Io:4:008:2 0:8 3 >
ffff880181305a80 2197224714 S Io:4:008:2 -115:8 4 = 8084d720
ffff880181305a80 2197232701 C Io:4:008:2 0:8 4 >
ffff8801813050c0 2197232835 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2197240704 C Ii:4:008:1 0:8 1 = 00
ffff8801813050c0 2197240711 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2219904713 C Ii:4:008:1 0:8 4 = 14658010
ffff8801813050c0 2219904740 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2219944712 C Ii:4:008:1 0:8 4 = 14658010
ffff8801813050c0 2219944720 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2219984712 C Ii:4:008:1 0:8 4 = 14658010
ffff8801813050c0 2219984718 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2220024715 C Ii:4:008:1 0:8 4 = 14658010
ffff8801813050c0 2220024722 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2220064715 C Ii:4:008:1 0:8 4 = 14658010
ffff8801813050c0 2220064721 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2221952713 C Ii:4:008:1 0:8 4 = 15222d20
ffff8801813050c0 2221952740 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2221992712 C Ii:4:008:1 0:8 4 = 15222d20
ffff8801813050c0 2221992720 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2222032713 C Ii:4:008:1 0:8 4 = 15222d20
ffff8801813050c0 2222032720 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2222072715 C Ii:4:008:1 0:8 4 = 15222d20
ffff8801813050c0 2222072721 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2222120710 C Ii:4:008:1 0:8 4 = 15222d20
ffff8801813050c0 2222120716 S Ii:4:008:1 -115:8 8 <
ffff8801813050c0 2222160714 C Ii:4:008:1 0:8 4 = 15222d20
ffff8801813050c0 2222160720 S Ii:4:008:1 -115:8 8 <
============================== CUT HERE ==============================
Here we can see the modified initialization sequence being sent to the RF remote and when we press the Firefly key on the FF remote we see the repeated USB packets sent by the FF remote (14658010)
and when we press the ATI key on the ATI remote we see the repeated USB packets sent by the ATI remote (15222d20).
The conclusion is that the RF receiver initialization must be changed in the ati_remote module in order to support the ATI remote.
History
=======
The changes made to the ati_remote.c module are based on changes made to the LIRC lirc_atiusb.c code [1]
by Cymen Vig in Feb 2006, who used a USB packet snooping program on Windows, these changes now seems to have disappeared from the current version of LIRC (0.9.0)
and a patch made to the drivers/media/rc/ati_remote.c file for the 2.6.31 kernel [2] which was never committed into the Linux source tree.
Hardware
========
- ATI USB RF Wireless Remote Receiver Part # 5000027000G:
Oct 10 16:07:08 acer-Veriton-N282G kernel: [695612.752080] usb 2-2: new low-speed USB device number 4 using uhci_hcd
Oct 10 16:07:08 acer-Veriton-N282G kernel: [695612.929218] usb 2-2: New USB device found, idVendor=0bc7, idProduct=0004
Oct 10 16:07:08 acer-Veriton-N282G kernel: [695612.929227] usb 2-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 10 16:07:08 acer-Veriton-N282G kernel: [695612.929233] usb 2-2: Product: USB Receiver
Oct 10 16:07:08 acer-Veriton-N282G kernel: [695612.929239] usb 2-2: Manufacturer: X10 Wireless Technology Inc
Oct 10 16:07:08 acer-Veriton-N282G kernel: [695613.044063] Registered IR keymap rc-ati-x10
- SnapStream Media Firefly PC Remote Wireless Receiver Model R1000-1:
Oct 10 19:14:59 OptiPlex-755 kernel: [534490.804065] usb 4-1: new low-speed USB device number 6 using uhci_hcd
Oct 10 19:14:59 OptiPlex-755 kernel: [534490.974451] usb 4-1: New USB device found, idVendor=0bc7, idProduct=0008
Oct 10 19:14:59 OptiPlex-755 kernel: [534490.974455] usb 4-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Oct 10 19:14:59 OptiPlex-755 kernel: [534490.974458] usb 4-1: Product: USB Receiver
Oct 10 19:14:59 OptiPlex-755 kernel: [534490.974461] usb 4-1: Manufacturer: X10 Wireless Technology Inc
Oct 10 19:15:00 OptiPlex-755 kernel: [534491.032019] Registered IR keymap rc-snapstream-firefly
- Firefly RF Remote Control Model R1000
- ATI Remote Wonder Plus RF Remote Control Part # 5000026900G
Product ID Test Coverage
========================
+--------------------------+------+-----+------+-----------------------+---------------------+
|Product Name +ID +FF RC+ATI RC+3.8.0-31-generic/x86_64+3.8.0-31-generic/i686|
+--------------------------+------+-----+------+-----------------------+---------------------+
|LOLA_REMOTE_PRODUCT_ID |0x0002|No |No |No |No |
|LOLA2_REMOTE_PRODUCT_ID |0x0003|No |No |No |No |
|ATI_REMOTE_PRODUCT_ID |0x0004|Yes |Yes |Yes |Yes |
|NVIDIA_REMOTE_PRODUCT_ID |0x0005|No |No |No |No |
|MEDION_REMOTE_PRODUCT_ID |0x0006|No |No |No |No |
|FIREFLY_REMOTE_PRODUCT_ID |0x0008|Yes |Yes |Yes |Yes |
+--------------------------+------+-----+------+-----------------------+---------------------+
FF RC: Firefly Remote Control
ATI RC: ATI Remote Control
3.8.0-31-generic/x86_64: 64 bit kernel
3.8.0-31-generic/i686: 32 bit kernel
Yes: Successful test
No: Not tested
Userspace Test
==============
A userspace test program [3] was developed to test the Remote receiver and remote control combinations.
It locates the X10 receiver by searching the USB devices for a Vendor ID of 0xbc7, any Product ID is allowed.
It then initializes the X10 receiver via interrupt writes using the new initialization strings discovered by Cymen Vig [1]:
static char init1[] = { 0x80, 0x05, 0x1b, 0x15, 0x14, 0x20, 0x24, 0x15 };
static char init2[] = { 0x83, 0x03 };
static char init3[] = { 0x84, 0xd7, 0x020 };
It then enters a loop and displays all packets received via interrupt reads, along with the computed checksum.
It is assumed that the libusb-dev: "userspace USB programming library development files" package is installed.
Compile and link as follows:
$ gcc -c testlibusb1.c
$ gcc testlibusb1.o -o testlibusb1 -lusb
Unload the "ati_remote" module if loaded:
$ sudo rmmod ati_remote
Run the test program:
$ sudo ./testlibusb1
...
found X10 0xbc7:0x8
found 1 interfaces
found 2 endpoints
endpoint 0 direction IN 0x81
endpoint 1 direction OUT 0x2
X10 open() OK
X10 set configuration OK
X10 claim interface 0 OK
X10 write 8 bytes to endpoint 0x2 OK with 8 bytes written
X10 write 2 bytes to endpoint 0x2 OK with 2 bytes written
X10 write 3 bytes to endpoint 0x2 OK with 3 bytes written
X10 read from endpoint 0x1 returned 4
0:14 1:e5 2:00 3:10 checksum e5
X10 read from endpoint 0x1 returned 4
0:14 1:e5 2:00 3:10 checksum e5
X10 read from endpoint 0x1 returned 4
0:14 1:e5 2:00 3:10 checksum e5
X10 read from endpoint 0x1 returned 4
X10 read from endpoint 0x1 returned 4
0:15 1:a2 2:ad 3:20 checksum a2
X10 read from endpoint 0x1 returned 4
0:15 1:a2 2:ad 3:20 checksum a2
X10 read from endpoint 0x1 returned 4
0:15 1:a2 2:ad 3:20 checksum a2
X10 read from endpoint 0x1 returned 4
0:15 1:a2 2:ad 3:20 checksum a2
...
^C
In the sample output above the SnapStream Media Firefly PC Remote Wireless Receiver Model R1000-1 was connected as can be seen by the Vendor ID value of 0x8.
Each remote key press generates 4 usb packets, each USB packet is always 4 bytes in length.
The first 4 packets were from the Firefly button on the Firefly RF Remote Control Model R1000, byte 0 is always 0x14 for this remote.
The second 4 packets were from the ATI button on the ATI Remote Wonder Plus RF Remote Control Part # 5000026900G, byte 0 is always 0x15 for this remote.
Other than the value of byte 0 the format of the the USB packets generated by the Firefly and ATI remotes are identical, including the channel mask (byte 3) and checksum calculation.
Exactly the same results are obtained when the ATI USB RF Wireless Remote Receiver Part # 5000027000G is used.
Conclusions
===========
The modified version of the ati_remote driver [4] and the corresponding patch file [5] are provided.
The untested Product ID and remote control combinations need to be tested.
I have no access to the untested RF receivers corresponding to the Product IDs so perhaps users on the linux-input and linux-media
could test this patch using other RF receiver and remote combinations.
References
==========
[1] http://www.mythtv.org/pipermail/mythtv-users/2006-February/121861.html
[2] http://www.mythtv.org/wiki/ATI_Remote_Wonder_Plus
[3] http://cargocult.ca/testlibusb1.c
[4] http://cargocult.ca/ati_remote_plus.c
[5] http://cargocult.ca/ati_remote.patch
^ permalink raw reply
* Re: [PATCH] HID: remove self-assignment from hid_input_report
From: Jiri Kosina @ 2013-10-30 13:41 UTC (permalink / raw)
To: Felix Rueegg; +Cc: linux-input, linux-kernel
In-Reply-To: <1381253627-2223-1-git-send-email-felix.rueegg@gmail.com>
On Tue, 8 Oct 2013, Felix Rueegg wrote:
> The ternary expression will always result in a self-assignment, which is pointless.
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [patch] HID: logitech-dj: small cleanup in rdcat()
From: Jiri Kosina @ 2013-10-30 13:45 UTC (permalink / raw)
To: Dan Carpenter; +Cc: linux-input, kernel-janitors
In-Reply-To: <20131019090859.GD9312@longonot.mountain>
On Sat, 19 Oct 2013, Dan Carpenter wrote:
> We could pass the "rdsec" pointer instead of the address of the "rdesc"
> and it's a little simpler.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Cosmetic change on a borderline of being justified to bother with :)
Thanks Dan, applying now for 3.13.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCHv2 1/3] Input: twl4030-keypad - add device tree support
From: Grant Likely @ 2013-10-30 13:53 UTC (permalink / raw)
To: Pavel Machek, linux-input, 'Beno?t Cousson',
Tony Lindgren, Rob Herring, Pawel Moll, Mark Rutland,
Stephen Warren, Ian Campbell, Rob Landley, Russell King,
Dmitry Torokhov, devicetree, linux-doc, linux-kernel,
linux-arm-kernel, linux-omap
In-Reply-To: <20131027114753.GB14901@amd.pavel.ucw.cz>
On Sun, 27 Oct 2013 12:47:53 +0100, Pavel Machek <pavel@ucw.cz> wrote:
> > > > +#if IS_ENABLED(CONFIG_OF)
> > > I'm probably missing something here, but why not #ifdef CONFIG_OF?
> >
> > I have been told for other drivers, that IS_ENABLED() is
> > the prefered way to check for configuration these days.
>
> CONFIG_OF can not be module, using IS_ENABLED() on it is just wrong.
That makes no sense. There is absolutely nothing wrong with using
IS_ENABLED() for CONFIG_OF.
g.
^ permalink raw reply
* Re: [PATCHv2 1/3] Input: twl4030-keypad - add device tree support
From: Pavel Machek @ 2013-10-30 13:59 UTC (permalink / raw)
To: Grant Likely
Cc: linux-input, 'Beno?t Cousson', Tony Lindgren, Rob Herring,
Pawel Moll, Mark Rutland, Stephen Warren, Ian Campbell,
Rob Landley, Russell King, Dmitry Torokhov, devicetree, linux-doc,
linux-kernel, linux-arm-kernel, linux-omap
In-Reply-To: <20131030135307.D8CE1C402A0@trevor.secretlab.ca>
On Wed 2013-10-30 06:53:07, Grant Likely wrote:
> On Sun, 27 Oct 2013 12:47:53 +0100, Pavel Machek <pavel@ucw.cz> wrote:
> > > > > +#if IS_ENABLED(CONFIG_OF)
> > > > I'm probably missing something here, but why not #ifdef CONFIG_OF?
> > >
> > > I have been told for other drivers, that IS_ENABLED() is
> > > the prefered way to check for configuration these days.
> >
> > CONFIG_OF can not be module, using IS_ENABLED() on it is just wrong.
>
> That makes no sense. There is absolutely nothing wrong with using
> IS_ENABLED() for CONFIG_OF.
Besides being too long, confusing for a reader, and testing for an
option that can't exist?
include/linux/kconfig.h-/*
include/linux/kconfig.h: * IS_ENABLED(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y' or 'm',
include/linux/kconfig.h- * 0 otherwise.
include/linux/kconfig.h- *
include/linux/kconfig.h- */
include/linux/kconfig.h:#define IS_ENABLED(option) \
include/linux/kconfig.h- (config_enabled(option) || config_enabled(option##_MODULE))
include/linux/kconfig.h-
include/linux/kconfig.h-/*
include/linux/kconfig.h- * IS_BUILTIN(CONFIG_FOO) evaluates to 1 if CONFIG_FOO is set to 'y', 0
include/linux/kconfig.h- * otherwise. For boolean options, this is
equivalent to
include/linux/kconfig.h: * IS_ENABLED(CONFIG_FOO).
include/linux/kconfig.h- */
include/linux/kconfig.h-#define IS_BUILTIN(option) config_enabled(option)
include/linux/kconfig.h-
Oops. And I made a mistake of looking up config_enabled(). Obfuscated
C code contest.
Just use #ifdef CONFIG_foo.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] input: i8042 - add PNP modaliases
From: Tom Gundersen @ 2013-10-30 14:30 UTC (permalink / raw)
To: linux-input@vger.kernel.org
Cc: LKML, Tom Gundersen, Matthew Garrett, Dmitry Torokhov
In-Reply-To: <CAG-2HqUhZdYgYcDGJaFUJV-AqgbbFh55HMcw6nRppiUyeHGjcw@mail.gmail.com>
On Fri, Oct 4, 2013 at 2:26 PM, Tom Gundersen <teg@jklm.no> wrote:
> On Wed, Sep 4, 2013 at 11:27 AM, Tom Gundersen <teg@jklm.no> wrote:
>> This allows the module to be autoloaded in the common case.
>>
>> In order to work on non-PnP systems the module should be compiled in or loaded
>> unconditionally at boot (c.f. modules-load.d(5)), as before.
>>
>> Cc: Matthew Garrett <mjg59@srcf.ucam.org>
>> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
>> Signed-off-by: Tom Gundersen <teg@jklm.no>
>> --
>
>
> Hi Dmitry,
>
> Any comments on this? Any chance of having this (and the two patches
> dropping EXPERT=y requirements) included for 3.13 (or even 3.12 if it
> is not too late for this kind of stuff)? Let me know if I should
> resend the three patches.
Ping? Any chance of seeing this in 3.13?
Cheers,
Tom
^ permalink raw reply
* [PATCH RESEND v2] Input: add driver for Neonode zForce based touchscreens
From: Heiko Stübner @ 2013-10-30 16:18 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Henrik Rydberg, linux-kernel, linux-input
This adds a driver for touchscreens using the zforce infrared
technology from Neonode connected via i2c to the host system.
It supports multitouch with up to two fingers and tracking of the
contacts in hardware.
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
---
changes since v1:
- address comments from Dmitry Torokhov
but I kept the access_mutex due to the possible race I described in the mail:
- touch -> interrupt
- isr reads first packet
- user closes device -> stop command sent
- isr reads payload
- address comments from Henrik Rydberg, letting the input system collect
singletouch from the multitouch data using the appropriate functions
drivers/input/touchscreen/Kconfig | 13 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/zforce_ts.c | 826 +++++++++++++++++++++++++++++++
include/linux/platform_data/zforce_ts.h | 26 +
4 files changed, 866 insertions(+)
create mode 100644 drivers/input/touchscreen/zforce_ts.c
create mode 100644 include/linux/platform_data/zforce_ts.h
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 3b9758b..ade11b7 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -919,4 +919,17 @@ config TOUCHSCREEN_TPS6507X
To compile this driver as a module, choose M here: the
module will be called tps6507x_ts.
+config TOUCHSCREEN_ZFORCE
+ tristate "Neonode zForce infrared touchscreens"
+ depends on I2C
+ depends on GPIOLIB
+ help
+ Say Y here if you have a touchscreen using the zforce
+ infraread technology from Neonode.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called zforce_ts.
+
endif
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index f5216c1..7587883 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -75,3 +75,4 @@ 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_TPS6507X) += tps6507x-ts.o
+obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
diff --git a/drivers/input/touchscreen/zforce_ts.c b/drivers/input/touchscreen/zforce_ts.c
new file mode 100644
index 0000000..f4cfd4d
--- /dev/null
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -0,0 +1,826 @@
+/*
+ * Copyright (C) 2012-2013 MundoReader S.L.
+ * Author: Heiko Stuebner <heiko@sntech.de>
+ *
+ * based in parts on Nook zforce driver
+ *
+ * Copyright (C) 2010 Barnes & Noble, Inc.
+ * Author: Pieter Truter<ptruter@intrinsyc.com>
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/hrtimer.h>
+#include <linux/slab.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/i2c.h>
+#include <linux/delay.h>
+#include <linux/gpio.h>
+#include <linux/device.h>
+#include <linux/sysfs.h>
+#include <linux/input/mt.h>
+#include <linux/platform_data/zforce_ts.h>
+
+#define WAIT_TIMEOUT msecs_to_jiffies(1000)
+
+#define FRAME_START 0xee
+
+/* Offsets of the different parts of the payload the controller sends */
+#define PAYLOAD_HEADER 0
+#define PAYLOAD_LENGTH 1
+#define PAYLOAD_BODY 2
+
+/* Response offsets */
+#define RESPONSE_ID 0
+#define RESPONSE_DATA 1
+
+/* Commands */
+#define COMMAND_DEACTIVATE 0x00
+#define COMMAND_INITIALIZE 0x01
+#define COMMAND_RESOLUTION 0x02
+#define COMMAND_SETCONFIG 0x03
+#define COMMAND_DATAREQUEST 0x04
+#define COMMAND_SCANFREQ 0x08
+#define COMMAND_STATUS 0X1e
+
+/*
+ * Responses the controller sends as a result of
+ * command requests
+ */
+#define RESPONSE_DEACTIVATE 0x00
+#define RESPONSE_INITIALIZE 0x01
+#define RESPONSE_RESOLUTION 0x02
+#define RESPONSE_SETCONFIG 0x03
+#define RESPONSE_SCANFREQ 0x08
+#define RESPONSE_STATUS 0X1e
+
+/*
+ * Notifications are send by the touch controller without
+ * being requested by the driver and include for example
+ * touch indications
+ */
+#define NOTIFICATION_TOUCH 0x04
+#define NOTIFICATION_BOOTCOMPLETE 0x07
+#define NOTIFICATION_OVERRUN 0x25
+#define NOTIFICATION_PROXIMITY 0x26
+#define NOTIFICATION_INVALID_COMMAND 0xfe
+
+#define ZFORCE_REPORT_POINTS 2
+#define ZFORCE_MAX_AREA 0xff
+
+#define STATE_DOWN 0
+#define STATE_MOVE 1
+#define STATE_UP 2
+
+#define SETCONFIG_DUALTOUCH (1 << 0)
+
+struct zforce_point {
+ int coord_x;
+ int coord_y;
+ int state;
+ int id;
+ int area_major;
+ int area_minor;
+ int orientation;
+ int pressure;
+ int prblty;
+};
+
+/*
+ * @client the i2c_client
+ * @input the input device
+ * @suspending in the process of going to suspend (don't emit wakeup
+ * events for commands executed to suspend the device)
+ * @suspended device suspended
+ * @access_mutex serialize i2c-access, to keep multipart reads together
+ * @command_done completion to wait for the command result
+ * @command_mutex serialize commands send to the ic
+ * @command_waiting the id of the command that that is currently waiting
+ * for a result
+ * @command_result returned result of the command
+ */
+struct zforce_ts {
+ struct i2c_client *client;
+ struct input_dev *input;
+ const struct zforce_ts_platdata *pdata;
+ char phys[32];
+
+ bool suspending;
+ bool suspended;
+ bool boot_complete;
+
+ /* Firmware version information */
+ u16 version_major;
+ u16 version_minor;
+ u16 version_build;
+ u16 version_rev;
+
+ struct mutex access_mutex;
+
+ struct completion command_done;
+ struct mutex command_mutex;
+ int command_waiting;
+ int command_result;
+};
+
+static int zforce_command(struct zforce_ts *ts, u8 cmd)
+{
+ struct i2c_client *client = ts->client;
+ char buf[3];
+ int ret;
+
+ dev_dbg(&client->dev, "%s: 0x%x\n", __func__, cmd);
+
+ buf[0] = FRAME_START;
+ buf[1] = 1; /* data size, command only */
+ buf[2] = cmd;
+
+ mutex_lock(&ts->access_mutex);
+ ret = i2c_master_send(client, &buf[0], ARRAY_SIZE(buf));
+ mutex_unlock(&ts->access_mutex);
+ if (ret < 0) {
+ dev_err(&client->dev, "i2c send data request error: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int zforce_send_wait(struct zforce_ts *ts, const char *buf, int len)
+{
+ struct i2c_client *client = ts->client;
+ int ret;
+
+ ret = mutex_trylock(&ts->command_mutex);
+ if (!ret) {
+ dev_err(&client->dev, "already waiting for a command\n");
+ return -EBUSY;
+ }
+
+ dev_dbg(&client->dev, "sending %d bytes for command 0x%x\n",
+ buf[1], buf[2]);
+
+ ts->command_waiting = buf[2];
+
+ mutex_lock(&ts->access_mutex);
+ ret = i2c_master_send(client, buf, len);
+ mutex_unlock(&ts->access_mutex);
+ if (ret < 0) {
+ dev_err(&client->dev, "i2c send data request error: %d\n", ret);
+ goto unlock;
+ }
+
+ dev_dbg(&client->dev, "waiting for result for command 0x%x\n", buf[2]);
+
+ if (wait_for_completion_timeout(&ts->command_done, WAIT_TIMEOUT) == 0) {
+ ret = -ETIME;
+ goto unlock;
+ }
+
+ ret = ts->command_result;
+
+unlock:
+ mutex_unlock(&ts->command_mutex);
+ return ret;
+}
+
+static int zforce_command_wait(struct zforce_ts *ts, u8 cmd)
+{
+ struct i2c_client *client = ts->client;
+ char buf[3];
+ int ret;
+
+ dev_dbg(&client->dev, "%s: 0x%x\n", __func__, cmd);
+
+ buf[0] = FRAME_START;
+ buf[1] = 1; /* data size, command only */
+ buf[2] = cmd;
+
+ ret = zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
+ if (ret < 0) {
+ dev_err(&client->dev, "i2c send data request error: %d\n", ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int zforce_resolution(struct zforce_ts *ts, u16 x, u16 y)
+{
+ struct i2c_client *client = ts->client;
+ char buf[7] = { FRAME_START, 5, COMMAND_RESOLUTION,
+ (x & 0xff), ((x >> 8) & 0xff),
+ (y & 0xff), ((y >> 8) & 0xff) };
+
+ dev_dbg(&client->dev, "set resolution to (%d,%d)\n", x, y);
+
+ return zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
+}
+
+static int zforce_scan_frequency(struct zforce_ts *ts, u16 idle, u16 finger,
+ u16 stylus)
+{
+ struct i2c_client *client = ts->client;
+ char buf[9] = { FRAME_START, 7, COMMAND_SCANFREQ,
+ (idle & 0xff), ((idle >> 8) & 0xff),
+ (finger & 0xff), ((finger >> 8) & 0xff),
+ (stylus & 0xff), ((stylus >> 8) & 0xff) };
+
+ dev_dbg(&client->dev, "set scan frequency to (idle: %d, finger: %d, stylus: %d)\n",
+ idle, finger, stylus);
+
+ return zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
+}
+
+static int zforce_setconfig(struct zforce_ts *ts, char b1)
+{
+ struct i2c_client *client = ts->client;
+ char buf[7] = { FRAME_START, 5, COMMAND_SETCONFIG,
+ b1, 0, 0, 0 };
+
+ dev_dbg(&client->dev, "set config to (%d)\n", b1);
+
+ return zforce_send_wait(ts, &buf[0], ARRAY_SIZE(buf));
+}
+
+static int zforce_start(struct zforce_ts *ts)
+{
+ struct i2c_client *client = ts->client;
+ const struct zforce_ts_platdata *pdata = dev_get_platdata(&client->dev);
+ int ret;
+
+ dev_dbg(&client->dev, "starting device\n");
+
+ ret = zforce_command_wait(ts, COMMAND_INITIALIZE);
+ if (ret) {
+ dev_err(&client->dev, "Unable to initialize, %d\n", ret);
+ return ret;
+ }
+
+ ret = zforce_resolution(ts, pdata->x_max, pdata->y_max);
+ if (ret) {
+ dev_err(&client->dev, "Unable to set resolution, %d\n", ret);
+ goto error;
+ }
+
+ ret = zforce_scan_frequency(ts, 10, 50, 50);
+ if (ret) {
+ dev_err(&client->dev, "Unable to set scan frequency, %d\n",
+ ret);
+ goto error;
+ }
+
+ if (zforce_setconfig(ts, SETCONFIG_DUALTOUCH)) {
+ dev_err(&client->dev, "Unable to set config\n");
+ goto error;
+ }
+
+ /* start sending touch events */
+ ret = zforce_command(ts, COMMAND_DATAREQUEST);
+ if (ret) {
+ dev_err(&client->dev, "Unable to request data\n");
+ goto error;
+ }
+
+ /* Per NN, initial cal. take max. of 200msec.
+ * Allow time to complete this calibration
+ */
+ msleep(200);
+
+ return 0;
+
+error:
+ zforce_command_wait(ts, COMMAND_DEACTIVATE);
+ return ret;
+}
+
+static int zforce_stop(struct zforce_ts *ts)
+{
+ struct i2c_client *client = ts->client;
+ int ret;
+
+ dev_dbg(&client->dev, "stopping device\n");
+
+ /* deactivates touch sensing and puts the device into sleep */
+ ret = zforce_command_wait(ts, COMMAND_DEACTIVATE);
+ if (ret != 0) {
+ dev_err(&client->dev, "could not deactivate device, %d\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static int zforce_touch_event(struct zforce_ts *ts, u8 *payload)
+{
+ struct i2c_client *client = ts->client;
+ const struct zforce_ts_platdata *pdata = dev_get_platdata(&client->dev);
+ struct zforce_point point;
+ int count, i, num = 0;
+
+ count = payload[0];
+ if (count > ZFORCE_REPORT_POINTS) {
+ dev_warn(&client->dev, "to many coordinates %d, expected max %d\n",
+ count, ZFORCE_REPORT_POINTS);
+ count = ZFORCE_REPORT_POINTS;
+ }
+
+ for (i = 0; i < count; i++) {
+ point.coord_x =
+ payload[9 * i + 2] << 8 | payload[9 * i + 1];
+ point.coord_y =
+ payload[9 * i + 4] << 8 | payload[9 * i + 3];
+
+ if (point.coord_x > pdata->x_max ||
+ point.coord_y > pdata->y_max) {
+ dev_warn(&client->dev, "coordinates (%d,%d) invalid\n",
+ point.coord_x, point.coord_y);
+ point.coord_x = point.coord_y = 0;
+ }
+
+ point.state = payload[9 * i + 5] & 0x03;
+ point.id = (payload[9 * i + 5] & 0xfc) >> 2;
+
+ /* determine touch major, minor and orientation */
+ point.area_major = max(payload[9 * i + 6],
+ payload[9 * i + 7]);
+ point.area_minor = min(payload[9 * i + 6],
+ payload[9 * i + 7]);
+ point.orientation = payload[9 * i + 6] > payload[9 * i + 7];
+
+ point.pressure = payload[9 * i + 8];
+ point.prblty = payload[9 * i + 9];
+
+ dev_dbg(&client->dev, "point %d/%d: state %d, id %d, pressure %d, prblty %d, x %d, y %d, amajor %d, aminor %d, ori %d\n",
+ i, count, point.state, point.id,
+ point.pressure, point.prblty,
+ point.coord_x, point.coord_y,
+ point.area_major, point.area_minor,
+ point.orientation);
+
+ /* the zforce id starts with "1", so needs to be decreased */
+ input_mt_slot(ts->input, point.id - 1);
+
+ input_mt_report_slot_state(ts->input, MT_TOOL_FINGER,
+ point.state != STATE_UP);
+
+ if (point.state != STATE_UP) {
+ input_report_abs(ts->input, ABS_MT_POSITION_X,
+ point.coord_x);
+ input_report_abs(ts->input, ABS_MT_POSITION_Y,
+ point.coord_y);
+ input_report_abs(ts->input, ABS_MT_TOUCH_MAJOR,
+ point.area_major);
+ input_report_abs(ts->input, ABS_MT_TOUCH_MINOR,
+ point.area_minor);
+ input_report_abs(ts->input, ABS_MT_ORIENTATION,
+ point.orientation);
+ num++;
+ }
+ }
+
+ input_mt_sync_frame(ts->input);
+
+ input_mt_report_finger_count(ts->input, num);
+
+ input_sync(ts->input);
+
+ return 0;
+}
+
+static int zforce_read_packet(struct zforce_ts *ts, u8 *buf)
+{
+ struct i2c_client *client = ts->client;
+ int ret;
+
+ mutex_lock(&ts->access_mutex);
+
+ /* read 2 byte message header */
+ ret = i2c_master_recv(client, buf, 2);
+ if (ret < 0) {
+ dev_err(&client->dev, "error reading header: %d\n", ret);
+ goto unlock;
+ }
+
+ if (buf[PAYLOAD_HEADER] != FRAME_START) {
+ dev_err(&client->dev, "invalid frame start: %d\n", buf[0]);
+ ret = -EIO;
+ goto unlock;
+ }
+
+ if (buf[PAYLOAD_LENGTH] <= 0 || buf[PAYLOAD_LENGTH] > 255) {
+ dev_err(&client->dev, "invalid payload length: %d\n",
+ buf[PAYLOAD_LENGTH]);
+ ret = -EIO;
+ goto unlock;
+ }
+
+ /* read the message */
+ ret = i2c_master_recv(client, &buf[PAYLOAD_BODY], buf[PAYLOAD_LENGTH]);
+ if (ret < 0) {
+ dev_err(&client->dev, "error reading payload: %d\n", ret);
+ goto unlock;
+ }
+
+ dev_dbg(&client->dev, "read %d bytes for response command 0x%x\n",
+ buf[PAYLOAD_LENGTH], buf[PAYLOAD_BODY]);
+
+unlock:
+ mutex_unlock(&ts->access_mutex);
+ return ret;
+}
+
+static void zforce_complete(struct zforce_ts *ts, int cmd, int result)
+{
+ struct i2c_client *client = ts->client;
+
+ if (ts->command_waiting == cmd) {
+ dev_dbg(&client->dev, "completing command 0x%x\n", cmd);
+ ts->command_result = result;
+ complete(&ts->command_done);
+ } else {
+ dev_dbg(&client->dev, "command %d not for us\n", cmd);
+ }
+}
+
+static irqreturn_t zforce_interrupt(int irq, void *dev_id)
+{
+ struct zforce_ts *ts = dev_id;
+ struct i2c_client *client = ts->client;
+ const struct zforce_ts_platdata *pdata = dev_get_platdata(&client->dev);
+ int ret;
+ u8 payload_buffer[512];
+ u8 *payload;
+
+ /*
+ * When suspended, emit a wakeup signal if necessary and return.
+ * Due to the level-interrupt we will get re-triggered later.
+ */
+ if (ts->suspended) {
+ if (device_may_wakeup(&client->dev))
+ pm_wakeup_event(&client->dev, 500);
+ msleep(20);
+ return IRQ_HANDLED;
+ }
+
+ dev_dbg(&client->dev, "handling interrupt\n");
+
+ /* Don't emit wakeup events from commands run by zforce_suspend */
+ if (!ts->suspending && device_may_wakeup(&client->dev))
+ pm_stay_awake(&client->dev);
+
+ while (!gpio_get_value(pdata->gpio_int)) {
+ ret = zforce_read_packet(ts, payload_buffer);
+ if (ret < 0) {
+ dev_err(&client->dev, "could not read packet, ret: %d\n",
+ ret);
+ break;
+ }
+
+ payload = &payload_buffer[PAYLOAD_BODY];
+
+ switch (payload[RESPONSE_ID]) {
+ case NOTIFICATION_TOUCH:
+ /* Always report touch-events received while
+ * suspending, when being a wakeup source
+ */
+ if (ts->suspending && device_may_wakeup(&client->dev))
+ pm_wakeup_event(&client->dev, 500);
+ zforce_touch_event(ts, &payload[RESPONSE_DATA]);
+ break;
+ case NOTIFICATION_BOOTCOMPLETE:
+ ts->boot_complete = payload[RESPONSE_DATA];
+ zforce_complete(ts, payload[RESPONSE_ID], 0);
+ break;
+ case RESPONSE_INITIALIZE:
+ case RESPONSE_DEACTIVATE:
+ case RESPONSE_SETCONFIG:
+ case RESPONSE_RESOLUTION:
+ case RESPONSE_SCANFREQ:
+ zforce_complete(ts, payload[RESPONSE_ID],
+ payload[RESPONSE_DATA]);
+ break;
+ case RESPONSE_STATUS:
+ /* Version Payload Results
+ * [2:major] [2:minor] [2:build] [2:rev]
+ */
+ ts->version_major = (payload[RESPONSE_DATA + 1] << 8) |
+ payload[RESPONSE_DATA];
+ ts->version_minor = (payload[RESPONSE_DATA + 3] << 8) |
+ payload[RESPONSE_DATA + 2];
+ ts->version_build = (payload[RESPONSE_DATA + 5] << 8) |
+ payload[RESPONSE_DATA + 4];
+ ts->version_rev = (payload[RESPONSE_DATA + 7] << 8) |
+ payload[RESPONSE_DATA + 6];
+ dev_dbg(&ts->client->dev, "Firmware Version %04x:%04x %04x:%04x\n",
+ ts->version_major, ts->version_minor,
+ ts->version_build, ts->version_rev);
+
+ zforce_complete(ts, payload[RESPONSE_ID], 0);
+ break;
+ case NOTIFICATION_INVALID_COMMAND:
+ dev_err(&ts->client->dev, "invalid command: 0x%x\n",
+ payload[RESPONSE_DATA]);
+ break;
+ default:
+ dev_err(&ts->client->dev, "unrecognized response id: 0x%x\n",
+ payload[RESPONSE_ID]);
+ break;
+ }
+ }
+
+ if (!ts->suspending && device_may_wakeup(&client->dev))
+ pm_relax(&client->dev);
+
+ dev_dbg(&client->dev, "finished interrupt\n");
+
+ return IRQ_HANDLED;
+}
+
+static int zforce_input_open(struct input_dev *dev)
+{
+ struct zforce_ts *ts = input_get_drvdata(dev);
+ int ret;
+
+ ret = zforce_start(ts);
+ if (ret)
+ return ret;
+
+ return 0;
+}
+
+static void zforce_input_close(struct input_dev *dev)
+{
+ struct zforce_ts *ts = input_get_drvdata(dev);
+ struct i2c_client *client = ts->client;
+ int ret;
+
+ ret = zforce_stop(ts);
+ if (ret)
+ dev_warn(&client->dev, "stopping zforce failed\n");
+
+ return;
+}
+
+#ifdef CONFIG_PM_SLEEP
+static int zforce_suspend(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct zforce_ts *ts = i2c_get_clientdata(client);
+ struct input_dev *input = ts->input;
+ int ret = 0;
+
+ mutex_lock(&input->mutex);
+ ts->suspending = true;
+
+ /* when configured as wakeup source, device should always wake system
+ * therefore start device if necessary
+ */
+ if (device_may_wakeup(&client->dev)) {
+ dev_dbg(&client->dev, "suspend while being a wakeup source\n");
+
+ /* need to start device if not open, to be wakeup source */
+ if (!input->users) {
+ ret = zforce_start(ts);
+ if (ret)
+ goto unlock;
+ }
+
+ enable_irq_wake(client->irq);
+ } else if (input->users) {
+ dev_dbg(&client->dev, "suspend without being a wakeup source\n");
+
+ ret = zforce_stop(ts);
+ if (ret)
+ goto unlock;
+
+ disable_irq(client->irq);
+ }
+
+ ts->suspended = true;
+
+unlock:
+ ts->suspending = false;
+ mutex_unlock(&input->mutex);
+
+ return ret;
+}
+
+static int zforce_resume(struct device *dev)
+{
+ struct i2c_client *client = to_i2c_client(dev);
+ struct zforce_ts *ts = i2c_get_clientdata(client);
+ struct input_dev *input = ts->input;
+ int ret = 0;
+
+ mutex_lock(&input->mutex);
+
+ ts->suspended = false;
+
+ if (device_may_wakeup(&client->dev)) {
+ dev_dbg(&client->dev, "resume from being a wakeup source\n");
+
+ disable_irq_wake(client->irq);
+
+ /* need to stop device if it was not open on suspend */
+ if (!input->users) {
+ ret = zforce_stop(ts);
+ if (ret)
+ goto unlock;
+ }
+ } else if (input->users) {
+ dev_dbg(&client->dev, "resume without being a wakeup source\n");
+
+ enable_irq(client->irq);
+
+ ret = zforce_start(ts);
+ if (ret < 0)
+ goto unlock;
+ }
+
+unlock:
+ mutex_unlock(&input->mutex);
+
+ return ret;
+}
+#endif
+
+static SIMPLE_DEV_PM_OPS(zforce_pm_ops, zforce_suspend, zforce_resume);
+
+static void zforce_reset(void *data)
+{
+ struct zforce_ts *ts = data;
+
+ gpio_set_value(ts->pdata->gpio_rst, 0);
+}
+
+static int zforce_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ const struct zforce_ts_platdata *pdata = dev_get_platdata(&client->dev);
+ struct zforce_ts *ts;
+ struct input_dev *input_dev;
+ int ret;
+
+ if (!pdata)
+ return -EINVAL;
+
+ ts = devm_kzalloc(&client->dev, sizeof(struct zforce_ts), GFP_KERNEL);
+ if (!ts)
+ return -ENOMEM;
+
+ ret = devm_gpio_request_one(&client->dev, pdata->gpio_int, GPIOF_IN,
+ "zforce_ts_int");
+ if (ret) {
+ dev_err(&client->dev, "request of gpio %d failed, %d\n",
+ pdata->gpio_int, ret);
+ return ret;
+ }
+
+ ret = devm_gpio_request_one(&client->dev, pdata->gpio_rst,
+ GPIOF_OUT_INIT_LOW, "zforce_ts_rst");
+ if (ret) {
+ dev_err(&client->dev, "request of gpio %d failed, %d\n",
+ pdata->gpio_rst, ret);
+ return ret;
+ }
+
+ ret = devm_add_action(&client->dev, zforce_reset, ts);
+ if (ret) {
+ dev_err(&client->dev, "failed to register reset action, %d\n",
+ ret);
+ return ret;
+ }
+
+ snprintf(ts->phys, sizeof(ts->phys),
+ "%s/input0", dev_name(&client->dev));
+
+ input_dev = devm_input_allocate_device(&client->dev);
+ if (!input_dev) {
+ dev_err(&client->dev, "could not allocate input device\n");
+ return -ENOMEM;
+ }
+
+ mutex_init(&ts->access_mutex);
+ mutex_init(&ts->command_mutex);
+
+ ts->pdata = pdata;
+ ts->client = client;
+ ts->input = input_dev;
+
+ input_dev->name = "Neonode zForce touchscreen";
+ input_dev->phys = ts->phys;
+ input_dev->id.bustype = BUS_I2C;
+ input_dev->dev.parent = &client->dev;
+
+ input_dev->open = zforce_input_open;
+ input_dev->close = zforce_input_close;
+
+ set_bit(EV_KEY, input_dev->evbit);
+ set_bit(EV_SYN, input_dev->evbit);
+ set_bit(EV_ABS, input_dev->evbit);
+
+ /* For multi touch */
+ input_set_abs_params(input_dev, ABS_MT_POSITION_X, 0,
+ pdata->x_max, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_POSITION_Y, 0,
+ pdata->y_max, 0, 0);
+
+ input_set_abs_params(input_dev, ABS_MT_TOUCH_MAJOR, 0,
+ ZFORCE_MAX_AREA, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_TOUCH_MINOR, 0,
+ ZFORCE_MAX_AREA, 0, 0);
+ input_set_abs_params(input_dev, ABS_MT_ORIENTATION, 0, 1, 0, 0);
+ input_mt_init_slots(input_dev, ZFORCE_REPORT_POINTS, INPUT_MT_DIRECT);
+
+ input_set_drvdata(ts->input, ts);
+
+ init_completion(&ts->command_done);
+
+ /* The zforce pulls the interrupt low when it has data ready.
+ * After it is triggered the isr thread runs until all the available
+ * packets have been read and the interrupt is high again.
+ * Therefore we can trigger the interrupt anytime it is low and do
+ * not need to limit it to the interrupt edge.
+ */
+ ret = devm_request_threaded_irq(&client->dev, client->irq, NULL,
+ zforce_interrupt,
+ IRQF_TRIGGER_LOW | IRQF_ONESHOT,
+ input_dev->name, ts);
+ if (ret) {
+ dev_err(&client->dev, "irq %d request failed\n", client->irq);
+ return ret;
+ }
+
+ i2c_set_clientdata(client, ts);
+
+ /* let the controller boot */
+ gpio_set_value(pdata->gpio_rst, 1);
+
+ ts->command_waiting = NOTIFICATION_BOOTCOMPLETE;
+ if (wait_for_completion_timeout(&ts->command_done, WAIT_TIMEOUT) == 0)
+ dev_warn(&client->dev, "bootcomplete timed out\n");
+
+ /* need to start device to get version information */
+ ret = zforce_command_wait(ts, COMMAND_INITIALIZE);
+ if (ret) {
+ dev_err(&client->dev, "unable to initialize, %d\n", ret);
+ return ret;
+ }
+
+ /* this gets the firmware version among other informations */
+ ret = zforce_command_wait(ts, COMMAND_STATUS);
+ if (ret < 0) {
+ dev_err(&client->dev, "couldn't get status, %d\n", ret);
+ zforce_stop(ts);
+ return ret;
+ }
+
+ /* stop device and put it into sleep until it is opened */
+ ret = zforce_stop(ts);
+ if (ret < 0)
+ return ret;
+
+ device_set_wakeup_capable(&client->dev, true);
+
+ ret = input_register_device(input_dev);
+ if (ret) {
+ dev_err(&client->dev, "could not register input device, %d\n",
+ ret);
+ return ret;
+ }
+
+ return 0;
+}
+
+static struct i2c_device_id zforce_idtable[] = {
+ { "zforce-ts", 0 },
+ { }
+};
+MODULE_DEVICE_TABLE(i2c, zforce_idtable);
+
+static struct i2c_driver zforce_driver = {
+ .driver = {
+ .owner = THIS_MODULE,
+ .name = "zforce-ts",
+ .pm = &zforce_pm_ops,
+ },
+ .probe = zforce_probe,
+ .id_table = zforce_idtable,
+};
+
+module_i2c_driver(zforce_driver);
+
+MODULE_AUTHOR("Heiko Stuebner <heiko@sntech.de>");
+MODULE_DESCRIPTION("zForce TouchScreen Driver");
+MODULE_LICENSE("GPL");
diff --git a/include/linux/platform_data/zforce_ts.h b/include/linux/platform_data/zforce_ts.h
new file mode 100644
index 0000000..0472ab2
--- /dev/null
+++ b/include/linux/platform_data/zforce_ts.h
@@ -0,0 +1,26 @@
+/* drivers/input/touchscreen/zforce.c
+ *
+ * Copyright (C) 2012-2013 MundoReader S.L.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#ifndef _LINUX_INPUT_ZFORCE_TS_H
+#define _LINUX_INPUT_ZFORCE_TS_H
+
+struct zforce_ts_platdata {
+ int gpio_int;
+ int gpio_rst;
+
+ unsigned int x_max;
+ unsigned int y_max;
+};
+
+#endif /* _LINUX_INPUT_ZFORCE_TS_H */
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv8][ 1/4] Input: tsc2007: Add device tree support.
From: Denis Carikli @ 2013-10-30 17:58 UTC (permalink / raw)
To: Shawn Guo
Cc: Eric Bénard, linux-arm-kernel, Sascha Hauer, Denis Carikli,
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, devicetree, Dmitry Torokhov, linux-input,
Lothar Waßmann
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Lothar Waßmann <LW@KARO-electronics.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v7->v8:
- Fixed the lack of x and z fuzz properties.
- The pendown gpio is better documented.
- Added Shawn Guo in the cc list.
---
.../bindings/input/touchscreen/tsc2007.txt | 48 +++++
drivers/input/touchscreen/tsc2007.c | 204 ++++++++++++++++----
2 files changed, 211 insertions(+), 41 deletions(-)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
new file mode 100644
index 0000000..0b5c3a9
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/tsc2007.txt
@@ -0,0 +1,48 @@
+* Texas Instruments tsc2007 touchscreen controller
+
+Required properties:
+- compatible: must be "ti,tsc2007".
+- reg: I2C address of the chip.
+- ti,x-plate-ohms: X-plate resistance in ohms.
+
+Optional properties:
+- gpios: the interrupt gpio the chip is connected to (trough the penirq pin).
+ The penirq pin goes to low when the panel is touched.
+ (see GPIO binding[2] for more details).
+- interrupt-parent: the phandle for the gpio controller
+ (see interrupt binding[1]).
+- interrupts: (gpio) interrupt to which the chip is connected
+ (see interrupt binding[1]).
+- pinctrl-0: Should specify pin control groups used for the gpio
+ (see pinctrl bindings[0]).
+- pinctrl-names: Should contain only one value - "default"
+ (see pinctrl bindings[0]).
+- ti,max-rt: maximum pressure.
+- ti,fuzzx: specifies the absolute input fuzz x value.
+ If set, it will permit noise in the data up to +- the value given to the fuzz
+ parameter, that is used to filter noise from the event stream.
+- ti,fuzzy: specifies the absolute input fuzz y value.
+- ti,fuzzz: specifies the absolute input fuzz z value.
+- ti,poll-period: how much time to wait(in millisecond) before reading again the
+ values from the tsc2007.
+
+[0]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
+[1]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
+[2]: Documentation/devicetree/bindings/gpio/gpio.txt
+
+Example:
+ &i2c1 {
+ /* ... */
+ tsc2007@49 {
+ compatible = "ti,tsc2007";
+ reg = <0x49>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc2007_1>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0x0 0x8>;
+ gpios = <&gpio4 0 0>;
+ ti,x-plate-ohms = <180>;
+ };
+
+ /* ... */
+ };
diff --git a/drivers/input/touchscreen/tsc2007.c b/drivers/input/touchscreen/tsc2007.c
index 0b67ba4..3168a99 100644
--- a/drivers/input/touchscreen/tsc2007.c
+++ b/drivers/input/touchscreen/tsc2007.c
@@ -26,6 +26,9 @@
#include <linux/interrupt.h>
#include <linux/i2c.h>
#include <linux/i2c/tsc2007.h>
+#include <linux/of_device.h>
+#include <linux/of.h>
+#include <linux/of_gpio.h>
#define TSC2007_MEASURE_TEMP0 (0x0 << 4)
#define TSC2007_MEASURE_AUX (0x2 << 4)
@@ -74,7 +77,12 @@ struct tsc2007 {
u16 max_rt;
unsigned long poll_delay;
unsigned long poll_period;
+ int fuzzx;
+ int fuzzy;
+ int fuzzz;
+ char of;
+ unsigned gpio;
int irq;
wait_queue_head_t wait;
@@ -84,6 +92,11 @@ struct tsc2007 {
void (*clear_penirq)(void);
};
+static int tsc2007_get_pendown_state_dt(struct tsc2007 *ts)
+{
+ return !gpio_get_value(ts->gpio);
+}
+
static inline int tsc2007_xfer(struct tsc2007 *tsc, u8 cmd)
{
s32 data;
@@ -142,6 +155,14 @@ static u32 tsc2007_calculate_pressure(struct tsc2007 *tsc, struct ts_event *tc)
return rt;
}
+static bool tsc2007_is_pen_down_valid(struct tsc2007 *ts)
+{
+ if (ts->of)
+ return gpio_is_valid(ts->gpio);
+ else
+ return ts->get_pendown_state ? true : false;
+}
+
static bool tsc2007_is_pen_down(struct tsc2007 *ts)
{
/*
@@ -158,10 +179,13 @@ static bool tsc2007_is_pen_down(struct tsc2007 *ts)
* to fall back on the pressure reading.
*/
- if (!ts->get_pendown_state)
+ if (!tsc2007_is_pen_down_valid(ts))
return true;
- return ts->get_pendown_state();
+ if (ts->of)
+ return tsc2007_get_pendown_state_dt(ts);
+ else
+ return ts->get_pendown_state();
}
static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
@@ -178,7 +202,7 @@ static irqreturn_t tsc2007_soft_irq(int irq, void *handle)
rt = tsc2007_calculate_pressure(ts, &tc);
- if (rt == 0 && !ts->get_pendown_state) {
+ if (!rt && !tsc2007_is_pen_down_valid(ts)) {
/*
* If pressure reported is 0 and we don't have
* callback to check pendown state, we have to
@@ -228,7 +252,7 @@ static irqreturn_t tsc2007_hard_irq(int irq, void *handle)
{
struct tsc2007 *ts = handle;
- if (!ts->get_pendown_state || likely(ts->get_pendown_state()))
+ if (tsc2007_is_pen_down(ts))
return IRQ_WAKE_THREAD;
if (ts->clear_penirq)
@@ -273,34 +297,71 @@ static void tsc2007_close(struct input_dev *input_dev)
tsc2007_stop(ts);
}
-static int tsc2007_probe(struct i2c_client *client,
- const struct i2c_device_id *id)
+#ifdef CONFIG_OF
+static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts,
+ struct device_node *np)
{
- struct tsc2007 *ts;
- struct tsc2007_platform_data *pdata = client->dev.platform_data;
- struct input_dev *input_dev;
- int err;
-
- if (!pdata) {
- dev_err(&client->dev, "platform data is required!\n");
+ int err = 0;
+ u32 val32;
+ u64 val64;
+
+ if (!of_property_read_u32(np, "ti,max-rt", &val32))
+ ts->max_rt = val32;
+ else
+ ts->max_rt = MAX_12BIT;
+
+ if (!of_property_read_u32(np, "ti,fuzzx", &val32))
+ ts->fuzzx = val32;
+
+ if (!of_property_read_u32(np, "ti,fuzzy", &val32))
+ ts->fuzzy = val32;
+
+ if (!of_property_read_u32(np, "ti,fuzzz", &val32))
+ ts->fuzzz = val32;
+
+ if (!of_property_read_u64(np, "ti,poll-period", &val64))
+ ts->poll_period = val64;
+ else
+ ts->poll_period = 1;
+
+ if (!of_property_read_u32(np, "ti,x-plate-ohms", &val32)) {
+ ts->x_plate_ohms = val32;
+ } else {
+ dev_err(&client->dev,
+ "Error: lacking ti,x-plate-ohms devicetree property. (err %d).",
+ err);
return -EINVAL;
}
- if (!i2c_check_functionality(client->adapter,
- I2C_FUNC_SMBUS_READ_WORD_DATA))
- return -EIO;
+ ts->gpio = of_get_gpio(np, 0);
+ if (!gpio_is_valid(ts->gpio))
+ dev_err(&client->dev,
+ "GPIO not found (of_get_gpio returned %d)\n",
+ ts->gpio);
- ts = kzalloc(sizeof(struct tsc2007), GFP_KERNEL);
- input_dev = input_allocate_device();
- if (!ts || !input_dev) {
- err = -ENOMEM;
- goto err_free_mem;
- }
+ /* Used to detect if it is probed trough the device tree,
+ * in order to be able to use that information in the IRQ handler.
+ */
+ ts->of = 1;
- ts->client = client;
- ts->irq = client->irq;
- ts->input = input_dev;
- init_waitqueue_head(&ts->wait);
+ return 0;
+}
+#else
+static int tsc2007_probe_dt(struct i2c_client *client, struct tsc2007 *ts,
+ struct device_node *np)
+{
+ return -ENODEV;
+}
+#endif
+
+static int tsc2007_probe_pdev(struct i2c_client *client, struct tsc2007 *ts,
+ struct tsc2007_platform_data *pdata,
+ const struct i2c_device_id *id)
+{
+ if (!pdata) {
+ dev_err(&client->dev, "platform data is required!\n");
+ return -EINVAL;
+ }
ts->model = pdata->model;
ts->x_plate_ohms = pdata->x_plate_ohms;
@@ -309,13 +370,59 @@ static int tsc2007_probe(struct i2c_client *client,
ts->poll_period = pdata->poll_period ? : 1;
ts->get_pendown_state = pdata->get_pendown_state;
ts->clear_penirq = pdata->clear_penirq;
+ ts->fuzzx = pdata->fuzzx;
+ ts->fuzzy = pdata->fuzzy;
+ ts->fuzzz = pdata->fuzzz;
if (pdata->x_plate_ohms == 0) {
dev_err(&client->dev, "x_plate_ohms is not set up in platform data");
- err = -EINVAL;
- goto err_free_mem;
+ return -EINVAL;
}
+ /* Used to detect if it is probed trough the device tree,
+ * in order to be able to use that information in the IRQ handler.
+ */
+ ts->of = 0;
+
+ return 0;
+}
+
+static int tsc2007_probe(struct i2c_client *client,
+ const struct i2c_device_id *id)
+{
+ struct device_node *np = client->dev.of_node;
+ struct tsc2007_platform_data *pdata = client->dev.platform_data;
+ struct tsc2007 *ts;
+ struct input_dev *input_dev;
+ int err = 0;
+
+ ts = devm_kzalloc(&client->dev, sizeof(struct tsc2007), GFP_KERNEL);
+ if (!ts)
+ return -ENOMEM;
+
+ if (np)
+ err = tsc2007_probe_dt(client, ts, np);
+ else
+ err = tsc2007_probe_pdev(client, ts, pdata, id);
+
+ if (err)
+ return err;
+
+ if (!i2c_check_functionality(client->adapter,
+ I2C_FUNC_SMBUS_READ_WORD_DATA))
+ return -EIO;
+
+ input_dev = input_allocate_device();
+ if (!input_dev) {
+ err = -ENOMEM;
+ goto err_free_input;
+ };
+
+ ts->client = client;
+ ts->irq = client->irq;
+ ts->input = input_dev;
+ init_waitqueue_head(&ts->wait);
+
snprintf(ts->phys, sizeof(ts->phys),
"%s/input0", dev_name(&client->dev));
@@ -331,19 +438,21 @@ static int tsc2007_probe(struct i2c_client *client,
input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
input_dev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
- input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, pdata->fuzzx, 0);
- input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, pdata->fuzzy, 0);
+ input_set_abs_params(input_dev, ABS_X, 0, MAX_12BIT, ts->fuzzx, 0);
+ input_set_abs_params(input_dev, ABS_Y, 0, MAX_12BIT, ts->fuzzy, 0);
input_set_abs_params(input_dev, ABS_PRESSURE, 0, MAX_12BIT,
- pdata->fuzzz, 0);
+ ts->fuzzz, 0);
- if (pdata->init_platform_hw)
- pdata->init_platform_hw();
+ if (!np) {
+ if (pdata->init_platform_hw)
+ pdata->init_platform_hw();
+ }
err = request_threaded_irq(ts->irq, tsc2007_hard_irq, tsc2007_soft_irq,
IRQF_ONESHOT, client->dev.driver->name, ts);
if (err < 0) {
dev_err(&client->dev, "irq %d busy?\n", ts->irq);
- goto err_free_mem;
+ goto err_free_input;
}
tsc2007_stop(ts);
@@ -358,23 +467,27 @@ static int tsc2007_probe(struct i2c_client *client,
err_free_irq:
free_irq(ts->irq, ts);
- if (pdata->exit_platform_hw)
- pdata->exit_platform_hw();
- err_free_mem:
+ if (!np) {
+ if (pdata->exit_platform_hw)
+ pdata->exit_platform_hw();
+ }
+ err_free_input:
input_free_device(input_dev);
- kfree(ts);
return err;
}
static int tsc2007_remove(struct i2c_client *client)
{
+ struct device_node *np = client->dev.of_node;
struct tsc2007 *ts = i2c_get_clientdata(client);
struct tsc2007_platform_data *pdata = client->dev.platform_data;
free_irq(ts->irq, ts);
- if (pdata->exit_platform_hw)
- pdata->exit_platform_hw();
+ if (!np) {
+ if (pdata->exit_platform_hw)
+ pdata->exit_platform_hw();
+ }
input_unregister_device(ts->input);
kfree(ts);
@@ -389,10 +502,19 @@ static const struct i2c_device_id tsc2007_idtable[] = {
MODULE_DEVICE_TABLE(i2c, tsc2007_idtable);
+#ifdef CONFIG_OF
+static const struct of_device_id tsc2007_of_match[] = {
+ { .compatible = "ti,tsc2007" },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(of, tsc2007_of_match);
+#endif
+
static struct i2c_driver tsc2007_driver = {
.driver = {
.owner = THIS_MODULE,
- .name = "tsc2007"
+ .name = "tsc2007",
+ .of_match_table = of_match_ptr(tsc2007_of_match),
},
.id_table = tsc2007_idtable,
.probe = tsc2007_probe,
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv8][ 2/4] ARM: dts: cpuimx35 Add touchscreen support.
From: Denis Carikli @ 2013-10-30 17:58 UTC (permalink / raw)
To: Shawn Guo
Cc: Eric Bénard, linux-arm-kernel, Sascha Hauer, Denis Carikli,
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, devicetree, Dmitry Torokhov, linux-input,
Lothar Waßmann
In-Reply-To: <1383155923-24076-1-git-send-email-denis@eukrea.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Lothar Waßmann <LW@KARO-electronics.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v7->v8:
- Added Shawn Guo in the cc list.
---
arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi b/arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
index 2c2d4cd..a22230b 100644
--- a/arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
+++ b/arch/arm/boot/dts/imx35-eukrea-cpuimx35.dtsi
@@ -41,6 +41,17 @@
compatible = "nxp,pcf8563";
reg = <0x51>;
};
+
+ tsc2007: tsc2007@48 {
+ compatible = "ti,tsc2007";
+ reg = <0x48>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc2007_1>;
+ interrupt-parent = <&gpio3>;
+ interrupts = <0x2 0x8>;
+ gpios = <&gpio3 2 0>;
+ ti,x-plate-ohms = <180>;
+ };
};
&iomuxc {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCHv8][ 3/4] ARM: dts: cpuimx51 Add touchscreen support.
From: Denis Carikli @ 2013-10-30 17:58 UTC (permalink / raw)
To: Shawn Guo
Cc: Eric Bénard, linux-arm-kernel, Sascha Hauer, Denis Carikli,
Rob Herring, Pawel Moll, Mark Rutland, Stephen Warren,
Ian Campbell, devicetree, Dmitry Torokhov, linux-input,
Lothar Waßmann
In-Reply-To: <1383155923-24076-1-git-send-email-denis@eukrea.com>
Cc: Rob Herring <rob.herring@calxeda.com>
Cc: Pawel Moll <pawel.moll@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Stephen Warren <swarren@wwwdotorg.org>
Cc: Ian Campbell <ijc+devicetree@hellion.org.uk>
Cc: devicetree@vger.kernel.org
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
Cc: Sascha Hauer <kernel@pengutronix.de>
Cc: linux-arm-kernel@lists.infradead.org
Cc: Lothar Waßmann <LW@KARO-electronics.de>
Cc: Shawn Guo <shawn.guo@linaro.org>
Cc: Eric Bénard <eric@eukrea.com>
Signed-off-by: Denis Carikli <denis@eukrea.com>
---
ChangeLog v7->v8:
- Added Shawn Guo in the cc list.
---
arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi b/arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
index 8638656..34ca8d3a 100644
--- a/arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
+++ b/arch/arm/boot/dts/imx51-eukrea-cpuimx51.dtsi
@@ -42,6 +42,17 @@
compatible = "nxp,pcf8563";
reg = <0x51>;
};
+
+ tsc2007: tsc2007@49 {
+ compatible = "ti,tsc2007";
+ reg = <0x49>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&pinctrl_tsc2007_1>;
+ interrupt-parent = <&gpio4>;
+ interrupts = <0x0 0x8>;
+ gpios = <&gpio4 0 0>;
+ ti,x-plate-ohms = <180>;
+ };
};
&iomuxc {
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox