* [appleir] BUG: unable to handle kernel NULL pointer dereference
From: Luis Henriques @ 2013-10-29 14:51 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, linux-kernel, linux-input, James Henstridge
Hi,
James has reported a NULL pointer dereference[1] on the appleir
driver. From the bug report[2] it looks like it is 100%
reproducible using a 3.12-rc6 kernel simply by pressing any button on
the IR remote.
>From the stack trace, it looks like input_event is invoked with the
input_dev parameter set to NULL, which seems to indicate that
appleir_input_configured is never invoked.
Any ideas?
[1] https://launchpadlibrarian.net/154942024/macmini-oops.jpg
[2] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1244505
Cheers,
--
Luis
^ permalink raw reply
* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Mark Brown @ 2013-10-29 16:04 UTC (permalink / raw)
To: Simon Horman
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,
Tomi Valkeinen, linux-serial, linux-input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media, linux-pwm,
Samuel Ortiz, linux-pm, Ian Molton, linux-arm-ker
In-Reply-To: <20131029060427.GF11580@verge.net.au>
[-- Attachment #1.1: Type: text/plain, Size: 223 bytes --]
On Tue, Oct 29, 2013 at 03:04:27PM +0900, Simon Horman wrote:
> I think this is a step in a good direction.
> However, I think it would be even better if the architecture dependency was
> removed completely.
Yes, please.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 176 bytes --]
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Linus Walleij @ 2013-10-29 16:28 UTC (permalink / raw)
To: Laurent Pinchart
Cc: linux-fbdev@vger.kernel.org, linux-sh@vger.kernel.org,
Guennadi Liakhovetski, Thierry Reding,
linux-mtd@lists.infradead.org, linux-i2c@vger.kernel.org,
Vinod Koul, Joerg Roedel, Wolfram Sang, Magnus Damm,
Eduardo Valentin, Tomi Valkeinen, linux-serial@vger.kernel.org,
Linux Input, Zhang Rui, Chris Ball,
Jean-Christophe Plagniol-Villard, linux-media@vger.kernel.org
In-Reply-To: <1383004027-25036-1-git-send-email-laurent.pinchart+renesas@ideasonboard.com>
On Mon, Oct 28, 2013 at 4:46 PM, Laurent Pinchart
<laurent.pinchart+renesas@ideasonboard.com> wrote:
> If you believe the issue should be solved in a different way (for instance by
> removing the architecture dependency completely) please reply to the cover
> letter to let other maintainers chime in.
I have no real opinions on whether this is a good itermediate step towards
complete arch-independence or not, but I just noticed that you still
have the <mach/*> hierarchy in mach-shmobile/include/mach/*, and
grep:ing around this seems totally unnecessary, I think it would be
easy to produce a patch set eliminating <mach/*> from shmobile.
(Usually we will just move all the headers down into the
mach-shmobile folder.)
Yours,
Linus Walleij
______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/
^ permalink raw reply
* Re: [PATCH 00/19] Enable various Renesas drivers on all ARM platforms
From: Laurent Pinchart @ 2013-10-29 17:05 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: <20131029160449.GD16686-GFdadSzt00ze9xe1eoZjHA@public.gmane.org>
[-- Attachment #1.1: Type: text/plain, Size: 1030 bytes --]
Hi Mark,
On Tuesday 29 October 2013 09:04:49 Mark Brown wrote:
> On Tue, Oct 29, 2013 at 03:04:27PM +0900, Simon Horman wrote:
> > I think this is a step in a good direction.
> > However, I think it would be even better if the architecture dependency
> > was removed completely.
>
> Yes, please.
I've kept it for two reasons.
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|
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.
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.
--
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:23 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: <1577821.Q7gttkPE2J@avalon>
[-- Attachment #1.1: Type: text/plain, Size: 1082 bytes --]
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?
> 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.
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 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: 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
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