* Fw: (7)
From: Andrew Haines @ 2014-05-08 14:52 UTC (permalink / raw)
To: linux-input
Hello!
http://ambiaudio.com/-hello.friend?syfiguco=8382909&mecudonu=810041
^ permalink raw reply
* [PATCH 2/2] input: atmel-wm97xx: only build for AVR32
From: Arnd Bergmann @ 2014-05-08 14:56 UTC (permalink / raw)
To: linux-arm-kernel
Cc: Arnd Bergmann, Dmitry Torokhov, linux-kernel, Mark Brown,
linux-input, Liam Girdwood
In-Reply-To: <1399560990-1402858-1-git-send-email-arnd@arndb.de>
Building this driver on ARM/at91 always gives us this error message:
drivers/input/touchscreen/atmel-wm97xx.c:63:2: error: #error Unknown CPU, this driver only supports AT32AP700X CPUs.
Clearly this configuration is not meant to work, so let's just prevent
it in Kconfig. If we ever want to use it on another platform, we should
also pass proper resources for GPIO, IRQ and memory, which are hardcoded
to AT32AP700X at the moment.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lrg@slimlogic.co.uk>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
---
drivers/input/touchscreen/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index e2f0264..fe4c264 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -640,7 +640,7 @@ config TOUCHSCREEN_WM9713
config TOUCHSCREEN_WM97XX_ATMEL
tristate "WM97xx Atmel accelerated touch"
- depends on TOUCHSCREEN_WM97XX && (AVR32 || ARCH_AT91)
+ depends on TOUCHSCREEN_WM97XX && AVR32
help
Say Y here for support for streaming mode with WM97xx touchscreens
on Atmel AT91 or AVR32 systems with an AC97C module.
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/2] input: fix ps2/serio module dependency
From: Arnd Bergmann @ 2014-05-08 14:56 UTC (permalink / raw)
To: linux-arm-kernel
Cc: linux-kernel, Arnd Bergmann, Dmitry Torokhov, linux-input
In-Reply-To: <1399560990-1402858-1-git-send-email-arnd@arndb.de>
The ps2 mouse and keyboard drivers use the "serio" framework that
they correctly select in Kconfig, and that in turn depends on the
i8042 driver, which is also allowed to be disabled for architectures
that don't have an i8042.
However, Kconfig also allows i8042 to be built as a module while
the serio framework is built-in, which causes this link error:
drivers/built-in.o: In function `ps2_begin_command':
:(.text+0x26b6cc): undefined reference to `i8042_check_port_owner'
:(.text+0x26b6d4): undefined reference to `i8042_lock_chip'
drivers/built-in.o: In function `ps2_end_command':
:(.text+0x26b734): undefined reference to `i8042_check_port_owner'
:(.text+0x26b73c): undefined reference to `i8042_unlock_chip'
On x86, a specific 'select SERIO_I8042' takes care of it, but
not on the other architecture that potentially have a u8042.
This patch changes the Kconfig logic to ensure that whenever
there is an i8042, it does get used for the serio driver, avoiding
the link error above.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: linux-input@vger.kernel.org
---
drivers/input/keyboard/Kconfig | 2 +-
drivers/input/mouse/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 4f115db..dd2435a 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -71,7 +71,7 @@ config KEYBOARD_ATKBD
default y
select SERIO
select SERIO_LIBPS2
- select SERIO_I8042 if X86
+ select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
select SERIO_GSCPS2 if GSC
help
Say Y here if you want to use a standard AT or PS/2 keyboard. Usually
diff --git a/drivers/input/mouse/Kconfig b/drivers/input/mouse/Kconfig
index effa9c5..cf534ee 100644
--- a/drivers/input/mouse/Kconfig
+++ b/drivers/input/mouse/Kconfig
@@ -17,7 +17,7 @@ config MOUSE_PS2
default y
select SERIO
select SERIO_LIBPS2
- select SERIO_I8042 if X86
+ select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
select SERIO_GSCPS2 if GSC
help
Say Y here if you have a PS/2 mouse connected to your system. This
--
1.8.3.2
^ permalink raw reply related
* [git pull] Input updates for 3.15-rc4
From: Dmitry Torokhov @ 2014-05-08 15:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-kernel, linux-input
[-- Attachment #1: Type: text/plain, Size: 1224 bytes --]
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
or
master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. Just a few fixups to various
drivers.
Changelog:
---------
Dr. H. Nikolaus Schaller (2):
Input: bma150 - extend chip detection for bma180
Input: tca8418 - fix loading this driver as a module from a device tree
Hans de Goede (2):
Input: synaptics - add min/max quirk for ThinkPad Edge E431
Input: elantech - fix touchpad initialization on Gigabyte U2442
Sheng-Liang Song (1):
Input: atkbd - fix keyboard not working on some LG laptops
Diffstat:
--------
Documentation/input/elantech.txt | 5 ++++-
drivers/input/keyboard/atkbd.c | 29 ++++++++++++++++++++++++++++-
drivers/input/keyboard/tca8418_keypad.c | 7 +++++++
drivers/input/misc/bma150.c | 4 +++-
drivers/input/mouse/elantech.c | 26 +++++++++++++++++++++++++-
drivers/input/mouse/elantech.h | 1 +
drivers/input/mouse/synaptics.c | 8 ++++++++
7 files changed, 76 insertions(+), 4 deletions(-)
--
Dmitry
[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH 01/13] Input: clps711x-keypad - Make of_device_id array const
From: Dmitry Torokhov @ 2014-05-08 15:52 UTC (permalink / raw)
To: Jingoo Han; +Cc: linux-input, 'Alexander Shiyan'
In-Reply-To: <022e01cf69d4$62d1e5e0$2875b1a0$%han@samsung.com>
On Wed, May 07, 2014 at 06:11:52PM +0900, Jingoo Han wrote:
> Make of_device_id array const, because all OF functions
> handle it as const.
>
> Signed-off-by: Jingoo Han <jg1.han@samsung.com>
Applied the whole lot, thank you.
> ---
> drivers/input/keyboard/clps711x-keypad.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/keyboard/clps711x-keypad.c b/drivers/input/keyboard/clps711x-keypad.c
> index 3955aec..552b65c 100644
> --- a/drivers/input/keyboard/clps711x-keypad.c
> +++ b/drivers/input/keyboard/clps711x-keypad.c
> @@ -185,7 +185,7 @@ static int clps711x_keypad_remove(struct platform_device *pdev)
> return 0;
> }
>
> -static struct of_device_id clps711x_keypad_of_match[] = {
> +static const struct of_device_id clps711x_keypad_of_match[] = {
> { .compatible = "cirrus,clps711x-keypad", },
> { }
> };
> --
> 1.7.10.4
>
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] input: fix ps2/serio module dependency
From: Dmitry Torokhov @ 2014-05-08 15:59 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linux-arm-kernel, linux-kernel, linux-input
In-Reply-To: <1399560990-1402858-15-git-send-email-arnd@arndb.de>
Hi Arnd,
On Thu, May 08, 2014 at 04:56:26PM +0200, Arnd Bergmann wrote:
> @@ -71,7 +71,7 @@ config KEYBOARD_ATKBD
> default y
> select SERIO
> select SERIO_LIBPS2
> - select SERIO_I8042 if X86
> + select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
x86 also selects ARCH_MIGHT_HAVE_PC_SERIO so shouldn't this be
select SERIO_I8042 if ARCH_MIGHT_HAVE_PC_SERIO
?
I can fix it up on my side if you agree.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Nick Dyer @ 2014-05-08 16:01 UTC (permalink / raw)
To: Stephen Warren, Benson Leung, Dmitry Torokhov
Cc: Yufeng Shen, Daniel Kurtz, linux-input@vger.kernel.org,
Stephen Warren, Bowens, Alan
In-Reply-To: <536963A0.4060506@wwwdotorg.org>
Stephen Warren wrote:
> On 05/06/2014 04:16 PM, Benson Leung wrote:
>> Please coordinate with Nick Dyer, who has a long patch series that's
>> been approved but not yet merged into the input tree. The few patches
>> you've picked from the Chrome OS kernel overlap with his patch series.
>
> Ah I remember you mentioning that before. Is Nick's work still active?
> The link you sent me to the "latest status" was nearly a year ago:
>
> https://lkml.org/lkml/2013/6/27/311
My latest set of patches for upstream was sent just over a month ago:
https://lkml.org/lkml/2014/3/17/403
Dmitry Torokov has signed-off on them but not merged them into his tree
yet. It would be good to hear something from him!
> ... and while the github link you sent:
>
> https://github.com/ndyer/linux/commits/for-next-20140316-v8
>
> ... has much more recent activity, it hasn't been touched /that/
> recently either.
>
> To be honest, it'd be a bit off-putting to hold up a trivial patch
> series like this and make it wait for a huge refactoring series that's
> obviously been dragging on for a long time...
>From my point of view, it would be better if everyone with a stake in this
driver worked together to test and review a single set of improvements that
fixed bugs, added new features, and supported new chips, rather than
everyone implementing trivial fixes in various different ways that cause
merge conflicts and strange bugs.
^ permalink raw reply
* Re: [PATCH] Input: Introduce the use of the managed version of kzalloc
From: Dmitry Torokhov @ 2014-05-08 16:04 UTC (permalink / raw)
To: Himangi Saraogi; +Cc: linux-input, linux-kernel, julia.lawall
In-Reply-To: <20140507044638.GA3447@himangi-Dell>
Hi Himangi,
On Wed, May 07, 2014 at 10:16:38AM +0530, Himangi Saraogi wrote:
> This patch moves data allocated using kzalloc to managed data allocated
> using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> functions.
I prefer not to mix managed and unmanaged resources in one driver. I.e.
either all (or most) resources are managed or they are all unmanaged,
otherwise it is really hard to track which one should be freed and
which will be freed automatically.
In this very simple driver I do not see converting only memory
allocation to devm as bringing clear benefit,
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Stephen Warren @ 2014-05-08 16:41 UTC (permalink / raw)
To: Nick Dyer, Dmitry Torokhov
Cc: Benson Leung, Yufeng Shen, Daniel Kurtz,
linux-input@vger.kernel.org, Stephen Warren, Bowens, Alan
In-Reply-To: <536BAA5A.1010809@itdev.co.uk>
On 05/08/2014 10:01 AM, Nick Dyer wrote:
> Stephen Warren wrote:
>> On 05/06/2014 04:16 PM, Benson Leung wrote:
>>> Please coordinate with Nick Dyer, who has a long patch series that's
>>> been approved but not yet merged into the input tree. The few patches
>>> you've picked from the Chrome OS kernel overlap with his patch series.
>>
>> Ah I remember you mentioning that before. Is Nick's work still active?
>> The link you sent me to the "latest status" was nearly a year ago:
>>
>> https://lkml.org/lkml/2013/6/27/311
>
> My latest set of patches for upstream was sent just over a month ago:
> https://lkml.org/lkml/2014/3/17/403
>
> Dmitry Torokov has signed-off on them but not merged them into his tree
> yet. It would be good to hear something from him!
I don't understand the following comment in patch 0 at that link:
> Hi Dimitry-
>
> Here is a set of patches for atmel_mxt_ts that you've already
> signed-off.
Surely Dmitry would only have signed off on the patches if he had
applied them somewhere. I'm puzzled why he would have applied them but
not pushed them out into linux-next.
Perhaps he didn't sign off on the patches but rather just said they were
OK, or gave an ack? In which case, did you add Dmitry's S-o-b line to
the patches yourself? That's certainly not the correct procedure.
Perhaps he ignored the patches because of that?
Anyway, I'd like to pull these patches into my local repo to build on.
Can you point me at a tree where Dmitry applied them even if not in
linux-next? Alternatively, does your github repo contain exactly the
patches from the recent mailing list posting you linked above?
...
> From my point of view, it would be better if everyone with a stake in this
> driver worked together to test and review a single set of improvements that
> fixed bugs, added new features, and supported new chips, rather than
> everyone implementing trivial fixes in various different ways that cause
> merge conflicts and strange bugs.
Luckily, it doesn't look like it will be too hard to rebase my patches
on top of your work. However, I'd really like some feedback from Dmitry
re: when and where your patches will be applied, so that I know if/when
it makes sense to rebase on top of them.
Thanks.
^ permalink raw reply
* Re: [PATCH 00/22] Random ARM randconfig fixes in drivers
From: Guenter Roeck @ 2014-05-08 16:41 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
bhelgaas-hpIqsD4AKlfQT0dZR+AlfA, dwmw2-wEGCiKHe2LqWVfeAwA7xHQ,
dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w, balbi-l0cyMroinI0,
gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
plagnioj-sclMFOaUSTBWk0Htik3J/w, jic23-DgEjT+Ai2ygdnm+yROfE0A,
josh.wu-AIFe0yeh4nAAvxtiuMwx3w, kishon-l0cyMroinI0,
linus.walleij-QSEj5FYQhm4dnm+yROfE0A,
broonie-DgEjT+Ai2ygdnm+yROfE0A, mturquette-QSEj5FYQhm4dnm+yROfE0A,
nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w, ohad-Ix1uc/W3ht7QT0dZR+AlfA,
linux-lFZ/pmaqli7XmaaqVzeoHQ, tony-4v6yS6AI5VpBDgjK7y7TUQ,
vinod.koul-ral2JQCrhuEAvxtiuMwx3w, wim-IQzOog9fTRqzQB+pC5nmwQ,
wsa-z923LK4zBo2bacvFa/9K2g, dmaengine-u79uwXL29TY76Z2rM5mHXA,
linux-i2c-u79uwXL29TY76Z2rM5mHXA,
linux-ide-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-mtd-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-pci-u79uwXL29TY76Z2rM5mHXA,
linux-samsung-soc-u79uwXL29TY76Z2rM5mHXA,
linux-sh-u79uwXL29TY76Z2rM5mHXA,
linux-watchdog-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1399560433-1402630-1-git-send-email-arnd-r2nGTMty4D4@public.gmane.org>
On Thu, May 08, 2014 at 04:46:51PM +0200, Arnd Bergmann wrote:
> These are a bunch of fixes I had to do to get all randconfig
> configurations on ARM working. Most of these are really old
> bugs, but there are also some new ones. I don't think any of
> them require a backport to linux-stable.
>
> I have checked that they are all still required on yesterday's
> linux-next kernel. Please apply on the appropriate trees unless
> there are objections.
>
Is this series of patches also going to fix arm:allmodconfig ?
Thanks,
Guenter
^ permalink raw reply
* Re: [PATCH] input: rotary encoder: implement quarter period mode
From: Ezequiel García @ 2014-05-08 17:01 UTC (permalink / raw)
To: Dmitry Torokhov, Mark Rutland
Cc: Sascha Hauer, linux-input@vger.kernel.org, Daniel Mack,
devicetree@vger.kernel.org
In-Reply-To: <20140507185932.GA22973@core.coreip.homeip.net>
On 07 May 11:59 AM, Dmitry Torokhov wrote:
> On Wed, May 07, 2014 at 03:45:43PM +0100, Mark Rutland wrote:
> > Hi,
> >
> > On Wed, Dec 18, 2013 at 02:43:18PM +0000, Sascha Hauer wrote:
> > > Some rotary encoders have a stable state in all output state
> > > combinations. Add support for this type of encoder.
> > >
> > > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > > Cc: Daniel Mack <daniel@zonque.org>
> > > Cc: linux-input@vger.kernel.org
> > > Cc: devicetree@vger.kernel.org
> > > ---
> > > .../devicetree/bindings/input/rotary-encoder.txt | 1 +
> > > Documentation/input/rotary-encoder.txt | 9 +++++--
> > > drivers/input/misc/rotary_encoder.c | 30 ++++++++++++++++++++--
> > > include/linux/rotary_encoder.h | 1 +
> > > 4 files changed, 37 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > > index 3315495..cbdb29b 100644
> > > --- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > > +++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
> > > @@ -15,6 +15,7 @@ Optional properties:
> > > - rotary-encoder,rollover: Automatic rollove when the rotary value becomes
> > > greater than the specified steps or smaller than 0. For absolute axis only.
> > > - rotary-encoder,half-period: Makes the driver work on half-period mode.
> > > +- rotary-encoder,quarter-period: Makes the driver work on quarter-period mode.
> >
> > The new property looks as sane to me as the half-period property, so for
> > the binding addition:
>
> Actually, maybe we should deprecate rotary-encoder,half-period and
> instead add rotary-encoder,type property?
>
Mark: what do you say?
I can fix a few patches if everyone agrees...
--
Ezequiel Garcia, VanguardiaSur
www.vanguardiasur.com.ar
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Dmitry Torokhov @ 2014-05-08 17:26 UTC (permalink / raw)
To: Stephen Warren
Cc: Nick Dyer, Benson Leung, Yufeng Shen, Daniel Kurtz,
linux-input@vger.kernel.org, Stephen Warren, Bowens, Alan
In-Reply-To: <536BB3C9.8070908@wwwdotorg.org>
On Thu, May 08, 2014 at 10:41:45AM -0600, Stephen Warren wrote:
> On 05/08/2014 10:01 AM, Nick Dyer wrote:
> > Stephen Warren wrote:
> >> On 05/06/2014 04:16 PM, Benson Leung wrote:
> >>> Please coordinate with Nick Dyer, who has a long patch series that's
> >>> been approved but not yet merged into the input tree. The few patches
> >>> you've picked from the Chrome OS kernel overlap with his patch series.
> >>
> >> Ah I remember you mentioning that before. Is Nick's work still active?
> >> The link you sent me to the "latest status" was nearly a year ago:
> >>
> >> https://lkml.org/lkml/2013/6/27/311
> >
> > My latest set of patches for upstream was sent just over a month ago:
> > https://lkml.org/lkml/2014/3/17/403
> >
> > Dmitry Torokov has signed-off on them but not merged them into his tree
> > yet. It would be good to hear something from him!
>
> I don't understand the following comment in patch 0 at that link:
>
> > Hi Dimitry-
> >
> > Here is a set of patches for atmel_mxt_ts that you've already
> > signed-off.
>
> Surely Dmitry would only have signed off on the patches if he had
> applied them somewhere. I'm puzzled why he would have applied them but
> not pushed them out into linux-next.
I stashed them into a topic branch but never merged it to next because
there were concerns about the firmware loader interface causing long
pauses at startup when driver was built into the kernel. I need to go
over the series again.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Support batch read of input events from fifo
From: Jonathan Cameron @ 2014-05-08 18:10 UTC (permalink / raw)
To: Benjamin Tissoires, Archana Patni
Cc: Jiri Kosina, linux-input, Mika Westerberg, Pandruvada, Srinivas,
Archana Patni, Subramony Sesha
In-Reply-To: <CAN+gG=HQwkqcyvDfK_unSuKRVOt4dyoPDK5Rz0GswrTKL1OMEg@mail.gmail.com>
On May 8, 2014 3:28:23 PM GMT+01:00, Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:
>On Thu, May 8, 2014 at 9:32 AM, Archana Patni
><archana.patni@linux.intel.com> wrote:
>> Some i2c_hid devices like a sensor hub have built-in fifos which
>> can accumulate input events in their buffers and trigger an interrupt
>> at end of a user defined event like fifo full or a timeout. The
>current
>> implementation reads one event at a time in the IRQ handler leading
>to
>> several hundred interrupts being necessary to flush the fifo.
>>
>> This patch changes the threaded IRQ handler to keep input events
>until
>> there are no input events left to read. In the normal case, this will
>> invoke one additional call to fetch an input event to check for no
>pending
>> events and terminate the loop.
>
>I must say, I don't like this patch.
>It seems to me that it will solve your problem but will break other
>devices. Nothing in the spec says what happens if the host tries to
>read while the interrupt line is *not* asserted. I can easily imagine
>several scenarios where the device would hang until the next available
>data, or will just fail.
>
>So the proper way according to the spec is to check the status of the
>interrupt line. This line is the responsibility of the device to be
>asserted and we should rely on it to know if we can read again.
>
>However, a quick check on the interrupt API did not provide me the
>function I would like, so I guess this is something to be work on.
In general it is not possible to check the interrupt state. Some interrupt devices
simply don't provide any means of reading it. Generally a hybrid of a gpio and an
interrupt is needed to do this. They don't technically need to be on the same pin
though they often are...
>
>I can not ack this one until we can be sure not breaking other stuff.
>
>So: NACK.
>
>Cheers,
>Benjamin
>
>>
>> Signed-off-by: Archana Patni <archana.patni@intel.com>
>> Signed-off-by: Subramony Sesha <subramony.sesha@intel.com>
>> Reviewed-by: Mika Westerberg <mika.westerberg@intel.com>
>> Reviewed-by: Srinivas Pandruvada <srinivas.pandruvada@intel.com>
>> ---
>> drivers/hid/i2c-hid/i2c-hid.c | 20 +++++++++++++-------
>> 1 file changed, 13 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/hid/i2c-hid/i2c-hid.c
>b/drivers/hid/i2c-hid/i2c-hid.c
>> index 21aafc8..3f09a50 100644
>> --- a/drivers/hid/i2c-hid/i2c-hid.c
>> +++ b/drivers/hid/i2c-hid/i2c-hid.c
>> @@ -52,6 +52,7 @@
>> static bool debug;
>> module_param(debug, bool, 0444);
>> MODULE_PARM_DESC(debug, "print a lot of debug information");
>> +#define MAX_INPUT_EVENT_READ 100
>>
>> #define i2c_hid_dbg(ihid, fmt, arg...)
> \
>> do {
> \
>> @@ -366,7 +367,7 @@ static int i2c_hid_hwreset(struct i2c_client
>*client)
>> return 0;
>> }
>>
>> -static void i2c_hid_get_input(struct i2c_hid *ihid)
>> +static int i2c_hid_get_input(struct i2c_hid *ihid)
>> {
>> int ret, ret_size;
>> int size = le16_to_cpu(ihid->hdesc.wMaxInputLength);
>> @@ -374,11 +375,11 @@ static void i2c_hid_get_input(struct i2c_hid
>*ihid)
>> ret = i2c_master_recv(ihid->client, ihid->inbuf, size);
>> if (ret != size) {
>> if (ret < 0)
>> - return;
>> + return ret;
>>
>> dev_err(&ihid->client->dev, "%s: got %d data instead
>of %d\n",
>> __func__, ret, size);
>> - return;
>> + return -EIO;
>> }
>>
>> ret_size = ihid->inbuf[0] | ihid->inbuf[1] << 8;
>> @@ -387,13 +388,13 @@ static void i2c_hid_get_input(struct i2c_hid
>*ihid)
>> /* host or device initiated RESET completed */
>> if (test_and_clear_bit(I2C_HID_RESET_PENDING,
>&ihid->flags))
>> wake_up(&ihid->wait);
>> - return;
>> + return 0;
>> }
>>
>> if (ret_size > size) {
>> dev_err(&ihid->client->dev, "%s: incomplete report
>(%d/%d)\n",
>> __func__, size, ret_size);
>> - return;
>> + return -EIO;
>> }
>>
>> i2c_hid_dbg(ihid, "input: %*ph\n", ret_size, ihid->inbuf);
>> @@ -402,17 +403,22 @@ static void i2c_hid_get_input(struct i2c_hid
>*ihid)
>> hid_input_report(ihid->hid, HID_INPUT_REPORT,
>ihid->inbuf + 2,
>> ret_size - 2, 1);
>>
>> - return;
>> + return 1;
>> }
>>
>> static irqreturn_t i2c_hid_irq(int irq, void *dev_id)
>> {
>> struct i2c_hid *ihid = dev_id;
>> + int ret;
>> + int count = 0;
>>
>> if (test_bit(I2C_HID_READ_PENDING, &ihid->flags))
>> return IRQ_HANDLED;
>> + do {
>> + count++;
>> + ret = i2c_hid_get_input(ihid);
>>
>> - i2c_hid_get_input(ihid);
>> + } while (count < MAX_INPUT_EVENT_READ && ret > 0);
>>
>> return IRQ_HANDLED;
>> }
>> --
>> 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
--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.
^ permalink raw reply
* Very Urgent
From: Mr.Sung Lee @ 2014-05-08 18:21 UTC (permalink / raw)
I am Mr.Sung Lee, Auditing and Account Credit Officer, Dah Sing Bank Ltd (Hong Kong).
I have a Profitable business transaction,Please if interested do contact me via email
for more details.
Email:sunglee0020@yahoo.com.hk
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Nick Dyer @ 2014-05-08 19:50 UTC (permalink / raw)
To: Stephen Warren, Dmitry Torokhov
Cc: Benson Leung, Yufeng Shen, Daniel Kurtz,
linux-input@vger.kernel.org, Stephen Warren, Bowens, Alan
In-Reply-To: <536BB3C9.8070908@wwwdotorg.org>
Stephen Warren wrote:
> Anyway, I'd like to pull these patches into my local repo to build on.
> Can you point me at a tree where Dmitry applied them even if not in
> linux-next? Alternatively, does your github repo contain exactly the
> patches from the recent mailing list posting you linked above?
https://git.kernel.org/cgit/linux/kernel/git/dtor/input.git/log/?h=atmel-mxt-ts
However, I have made minor updates on top of that to take account of API
changes since he worked on them (reinit_completion).
The patches I posted at the end of March are the first 22 out of this tag:
https://github.com/ndyer/linux/tree/for-next-20140316-v8
> ...
>> From my point of view, it would be better if everyone with a stake in this
>> driver worked together to test and review a single set of improvements that
>> fixed bugs, added new features, and supported new chips, rather than
>> everyone implementing trivial fixes in various different ways that cause
>> merge conflicts and strange bugs.
>
> Luckily, it doesn't look like it will be too hard to rebase my patches
> on top of your work. However, I'd really like some feedback from Dmitry
> re: when and where your patches will be applied, so that I know if/when
> it makes sense to rebase on top of them.
OK. I agree that it's a good thing if we can get a sensible device tree
patch in as soon as possible. You will notice that a lot of the existing
platform data is removed in that sequence, and we already have a patch to
read the screen resolution from the chip.
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Nick Dyer @ 2014-05-08 19:56 UTC (permalink / raw)
To: Dmitry Torokhov, Stephen Warren
Cc: Benson Leung, Yufeng Shen, Daniel Kurtz,
linux-input@vger.kernel.org, Stephen Warren, Bowens, Alan
In-Reply-To: <20140508172635.GD11672@core.coreip.homeip.net>
Dmitry Torokhov wrote:
>>> Here is a set of patches for atmel_mxt_ts that you've already
>>> signed-off.
>>
>> Surely Dmitry would only have signed off on the patches if he had
>> applied them somewhere. I'm puzzled why he would have applied them but
>> not pushed them out into linux-next.
>
> I stashed them into a topic branch but never merged it to next because
> there were concerns about the firmware loader interface causing long
> pauses at startup when driver was built into the kernel. I need to go
> over the series again.
Thanks! I had wondered why you had left it, you never communicated this to
me unfortunately. Would it be preferable for me to switch to
request_firmware_nowait() and complete the probe asynchronously after it
returns?
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Support batch read of input events from fifo
From: Benjamin Tissoires @ 2014-05-08 21:34 UTC (permalink / raw)
To: Jonathan Cameron
Cc: Archana Patni, Jiri Kosina, linux-input, Mika Westerberg,
Pandruvada, Srinivas, Archana Patni, Subramony Sesha
In-Reply-To: <c6f3b822-9995-4f29-b3d4-2d6b9de7d57b@email.android.com>
On Thu, May 8, 2014 at 2:10 PM, Jonathan Cameron <jic23@kernel.org> wrote:
>
>
> On May 8, 2014 3:28:23 PM GMT+01:00, Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:
>>On Thu, May 8, 2014 at 9:32 AM, Archana Patni
>><archana.patni@linux.intel.com> wrote:
>>> Some i2c_hid devices like a sensor hub have built-in fifos which
>>> can accumulate input events in their buffers and trigger an interrupt
>>> at end of a user defined event like fifo full or a timeout. The
>>current
>>> implementation reads one event at a time in the IRQ handler leading
>>to
>>> several hundred interrupts being necessary to flush the fifo.
>>>
>>> This patch changes the threaded IRQ handler to keep input events
>>until
>>> there are no input events left to read. In the normal case, this will
>>> invoke one additional call to fetch an input event to check for no
>>pending
>>> events and terminate the loop.
>>
>>I must say, I don't like this patch.
>>It seems to me that it will solve your problem but will break other
>>devices. Nothing in the spec says what happens if the host tries to
>>read while the interrupt line is *not* asserted. I can easily imagine
>>several scenarios where the device would hang until the next available
>>data, or will just fail.
>>
>>So the proper way according to the spec is to check the status of the
>>interrupt line. This line is the responsibility of the device to be
>>asserted and we should rely on it to know if we can read again.
>>
>>However, a quick check on the interrupt API did not provide me the
>>function I would like, so I guess this is something to be work on.
> In general it is not possible to check the interrupt state. Some interrupt devices
> simply don't provide any means of reading it. Generally a hybrid of a gpio and an
> interrupt is needed to do this. They don't technically need to be on the same pin
> though they often are...
OK, that's what I was afraid of. :(
Mika, you mentioned in the early tests that you had some devices not
using GPIOs but ACPI IRQ. Are the latest ones still following this?
Would it be costly to export the gpio alongside the irq for the
devices not using a generic interrupt but a GPIO?
If the gpio can be exported, then we can rely on it to get the other events.
I don't know how much weight Microsoft put on the GPIO in the spec,
but they definitively talk about GPIO. I hope that general interrupts
regarding i2c_hid were just a temporary solution until ACPI5 devices
were more widely used. So maybe they implemented this optimization for
true GPIO interrupts (just guessing).
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Support batch read of input events from fifo
From: Mika Westerberg @ 2014-05-09 7:23 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jonathan Cameron, Archana Patni, Jiri Kosina, linux-input,
Pandruvada, Srinivas, Archana Patni, Subramony Sesha
In-Reply-To: <CAN+gG=GsnnkF0T_HQe-g2WX0V2GdTKKGytSU4rZF_RAwKtWCKA@mail.gmail.com>
On Thu, May 08, 2014 at 05:34:49PM -0400, Benjamin Tissoires wrote:
> On Thu, May 8, 2014 at 2:10 PM, Jonathan Cameron <jic23@kernel.org> wrote:
> >
> >
> > On May 8, 2014 3:28:23 PM GMT+01:00, Benjamin Tissoires <benjamin.tissoires@gmail.com> wrote:
> >>On Thu, May 8, 2014 at 9:32 AM, Archana Patni
> >><archana.patni@linux.intel.com> wrote:
> >>> Some i2c_hid devices like a sensor hub have built-in fifos which
> >>> can accumulate input events in their buffers and trigger an interrupt
> >>> at end of a user defined event like fifo full or a timeout. The
> >>current
> >>> implementation reads one event at a time in the IRQ handler leading
> >>to
> >>> several hundred interrupts being necessary to flush the fifo.
> >>>
> >>> This patch changes the threaded IRQ handler to keep input events
> >>until
> >>> there are no input events left to read. In the normal case, this will
> >>> invoke one additional call to fetch an input event to check for no
> >>pending
> >>> events and terminate the loop.
> >>
> >>I must say, I don't like this patch.
> >>It seems to me that it will solve your problem but will break other
> >>devices. Nothing in the spec says what happens if the host tries to
> >>read while the interrupt line is *not* asserted. I can easily imagine
> >>several scenarios where the device would hang until the next available
> >>data, or will just fail.
> >>
> >>So the proper way according to the spec is to check the status of the
> >>interrupt line. This line is the responsibility of the device to be
> >>asserted and we should rely on it to know if we can read again.
> >>
> >>However, a quick check on the interrupt API did not provide me the
> >>function I would like, so I guess this is something to be work on.
> > In general it is not possible to check the interrupt state. Some interrupt devices
> > simply don't provide any means of reading it. Generally a hybrid of a gpio and an
> > interrupt is needed to do this. They don't technically need to be on the same pin
> > though they often are...
>
> OK, that's what I was afraid of. :(
>
> Mika, you mentioned in the early tests that you had some devices not
> using GPIOs but ACPI IRQ. Are the latest ones still following this?
Yes.
Typically it is always GPIO line but you can route it directly to ioapic
with some magic done by BIOS.
> Would it be costly to export the gpio alongside the irq for the
> devices not using a generic interrupt but a GPIO?
We have systems where you can select from BIOS menu whether GPIO or IRQ
resource is passed. However, looks like vendors are passing IRQ only
(just checked Asus T100 and there is no GPIO option at all).
> If the gpio can be exported, then we can rely on it to get the other
> events.
Ideally, you would only have GPIO entry in the table and you could use
it as both a GPIO and an IRQ.
^ permalink raw reply
* Re: [PATCH 1/2] input: fix ps2/serio module dependency
From: Arnd Bergmann @ 2014-05-09 7:34 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-arm-kernel, linux-kernel, linux-input
In-Reply-To: <20140508155931.GA11672@core.coreip.homeip.net>
On Thursday 08 May 2014 08:59:31 Dmitry Torokhov wrote:
> Hi Arnd,
>
> On Thu, May 08, 2014 at 04:56:26PM +0200, Arnd Bergmann wrote:
> > @@ -71,7 +71,7 @@ config KEYBOARD_ATKBD
> > default y
> > select SERIO
> > select SERIO_LIBPS2
> > - select SERIO_I8042 if X86
> > + select SERIO_I8042 if X86 || ARCH_MIGHT_HAVE_PC_SERIO
>
> x86 also selects ARCH_MIGHT_HAVE_PC_SERIO so shouldn't this be
>
> select SERIO_I8042 if ARCH_MIGHT_HAVE_PC_SERIO
>
> ?
>
> I can fix it up on my side if you agree.
Yes, sounds good, thanks!
Arnd
^ permalink raw reply
* RE: [PATCH] Input: Introduce the use of managed version of kzalloc
From: Opensource [Anthony Olech] @ 2014-05-09 9:40 UTC (permalink / raw)
To: Himangi Saraogi, Support Opensource, dmitry.torokhov@gmail.com,
linux-input@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: julia.lawall@lip6.fr, Opensource [Anthony Olech]
In-Reply-To: <20140508040002.GA3307@himangi-Dell>
> -----Original Message-----
> From: Himangi Saraogi [mailto:himangi774@gmail.com]
> Sent: 08 May 2014 05:00
> To: Support Opensource; dmitry.torokhov@gmail.com; linux-
> input@vger.kernel.org; linux-kernel@vger.kernel.org
> Cc: julia.lawall@lip6.fr
> Subject: [PATCH] Input: Introduce the use of managed version of kzalloc
> This patch moves data allocated using kzalloc to managed data allocated
> using devm_kzalloc and cleans now unnecessary kfrees in probe and remove
> functions. This data is the third argument to da9052_request_irq in the two
> cases below.
The remainder of the description .....
> The following Coccinelle semantic patch was used for making the change:
> @platform@
> identifier p, probefn, removefn;
> @@
> struct platform_driver p = {
> .probe = probefn,
> .remove = removefn,
> };
> @prb@
> identifier platform.probefn, pdev;
> expression e, e1, e2;
> @@
> probefn(struct platform_device *pdev, ...) {
> <+...
> - e = kzalloc(e1, e2)
> + e = devm_kzalloc(&pdev->dev, e1, e2)
> ...
> ?-kfree(e);
> ...+>
> }
> @rem depends on prb@
> identifier platform.removefn;
> expression e;
> @@
> removefn(...) {
> <...
> - kfree(e);
> ...>
> }
.... does not seems appropriate for the commit message, it should IMHO go in the following section
> Signed-off-by: Himangi Saraogi <himangi774@gmail.com>
> Acked-by: Julia Lawall <julia.lawall@lip6.fr>
> ---
> As a follow up patch I would like to know if it would be desirable to modify
> request_threaded_irq to devm_request_threaded_irq in the helper function
> da9052_request_irq :
> int da9052_request_irq(struct da9052 *da9052, int irq, char *name,
> irq_handler_t handler, void *data) {
> irq = da9052_map_irq(da9052, irq);
> if (irq < 0)
> return irq;
> return request_threaded_irq(irq, NULL, handler,
> IRQF_TRIGGER_LOW | IRQF_ONESHOT,
> name, data);
> }
The problem here is that there is no way back to the 'dev' associated with the irq.
To solve this requires a change to the function, or even better, just placing the function's
code inline, in which case a two stage approach is required:- first 'inline' the function
(from the common header file) to each of the PMIC's component drivers and second
raise a patch for each component driver do the change as you suggest which will
work because the correct 'dev' is available. Not that the second stage will have to
wait until the first statge is actually in main-line.
> drivers/input/misc/da9052_onkey.c | 4 +---
> drivers/input/touchscreen/da9052_tsi.c | 4 +---
> 2 files changed, 2 insertions(+), 6 deletions(-)
> diff --git a/drivers/input/misc/da9052_onkey.c
> b/drivers/input/misc/da9052_onkey.c
> index 184c8f2..6fc8243 100644
> --- a/drivers/input/misc/da9052_onkey.c
> +++ b/drivers/input/misc/da9052_onkey.c
> @@ -84,7 +84,7 @@ static int da9052_onkey_probe(struct platform_device
> *pdev)
> return -EINVAL;
> }
>
> - onkey = kzalloc(sizeof(*onkey), GFP_KERNEL);
> + onkey = devm_kzalloc(&pdev->dev, sizeof(*onkey), GFP_KERNEL);
> input_dev = input_allocate_device();
> if (!onkey || !input_dev) {
> dev_err(&pdev->dev, "Failed to allocate memory\n"); @@ -
> 126,7 +126,6 @@ err_free_irq:
> cancel_delayed_work_sync(&onkey->work);
> err_free_mem:
> input_free_device(input_dev);
> - kfree(onkey);
>
> return error;
> }
> @@ -139,7 +138,6 @@ static int da9052_onkey_remove(struct
> platform_device *pdev)
> cancel_delayed_work_sync(&onkey->work);
>
> input_unregister_device(onkey->input);
> - kfree(onkey);
>
> return 0;
> }
> diff --git a/drivers/input/touchscreen/da9052_tsi.c
> b/drivers/input/touchscreen/da9052_tsi.c
> index ab64d58..dff6a2e 100644
> --- a/drivers/input/touchscreen/da9052_tsi.c
> +++ b/drivers/input/touchscreen/da9052_tsi.c
> @@ -238,7 +238,7 @@ static int da9052_ts_probe(struct platform_device
> *pdev)
> if (!da9052)
> return -EINVAL;
>
> - tsi = kzalloc(sizeof(struct da9052_tsi), GFP_KERNEL);
> + tsi = devm_kzalloc(&pdev->dev, sizeof(struct da9052_tsi),
> GFP_KERNEL);
> input_dev = input_allocate_device();
> if (!tsi || !input_dev) {
> error = -ENOMEM;
> @@ -311,7 +311,6 @@ err_free_datardy_irq:
> err_free_pendwn_irq:
> da9052_free_irq(tsi->da9052, DA9052_IRQ_PENDOWN, tsi);
> err_free_mem:
> - kfree(tsi);
> input_free_device(input_dev);
>
> return error;
> @@ -327,7 +326,6 @@ static int da9052_ts_remove(struct platform_device
> *pdev)
> da9052_free_irq(tsi->da9052, DA9052_IRQ_PENDOWN, tsi);
>
> input_unregister_device(tsi->dev);
> - kfree(tsi);
>
> return 0;
> }
> --
> 1.9.1
for the content of this patch:
Acked-by: Opensource [Anthony Olech] <anthony.olech.opensource@diasemi.com>
^ permalink raw reply
* Re: [PATCH 00/22] Random ARM randconfig fixes in drivers
From: Arnd Bergmann @ 2014-05-09 11:48 UTC (permalink / raw)
To: Guenter Roeck
Cc: wsa, tony, linux-pci, linus.walleij, nicolas.ferre, linux-ide,
wim, linux-mtd, linux-i2c, linux-samsung-soc, mturquette,
vinod.koul, linux-sh, kishon, linux-iio, linux-input, plagnioj,
ohad, linux-watchdog, broonie, bhelgaas, linux, linux-arm-kernel,
gregkh, dmitry.torokhov, linux-kernel, balbi, josh.wu, netdev,
dmaengine, dwmw2, jic23
In-Reply-To: <20140508164157.GA22224@roeck-us.net>
On Thursday 08 May 2014, Guenter Roeck wrote:
> On Thu, May 08, 2014 at 04:46:51PM +0200, Arnd Bergmann wrote:
> > These are a bunch of fixes I had to do to get all randconfig
> > configurations on ARM working. Most of these are really old
> > bugs, but there are also some new ones. I don't think any of
> > them require a backport to linux-stable.
> >
> > I have checked that they are all still required on yesterday's
> > linux-next kernel. Please apply on the appropriate trees unless
> > there are objections.
> >
> Is this series of patches also going to fix arm:allmodconfig ?
Possibly, I haven't checked in a while. I'm unfortunately sitting on
about 200 other patches in the same branch, which together fix all
build errors in any configuration I encountered.
I should really do some allmodconfig/allnoconfig/allyesconfig
builds without my series again, and prioritize sending out the
ones required for that.
Arnd
^ permalink raw reply
* Re: [PATCH 0/4] Input: atmel_mxt_ts - make it work on Tegra
From: Mark Brown @ 2014-05-09 18:49 UTC (permalink / raw)
To: Nick Dyer
Cc: Dmitry Torokhov, Stephen Warren, Benson Leung, Yufeng Shen,
Daniel Kurtz, linux-input@vger.kernel.org, Stephen Warren,
Bowens, Alan
In-Reply-To: <536BE154.2090701@itdev.co.uk>
[-- Attachment #1: Type: text/plain, Size: 466 bytes --]
On Thu, May 08, 2014 at 08:56:04PM +0100, Nick Dyer wrote:
> Thanks! I had wondered why you had left it, you never communicated this to
> me unfortunately. Would it be preferable for me to switch to
> request_firmware_nowait() and complete the probe asynchronously after it
> returns?
Another common option is to defer the firmware request/load until the
device is opened, but that doesn't work for all devices. That should
mean that userspace is up and running.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Re: [PATCH v5 8/8] ARM: sun7i/sun4i: dt: Add AXP209 support to various boards
From: Maxime Ripard @ 2014-05-10 1:06 UTC (permalink / raw)
To: Carlo Caione
Cc: linux-arm-kernel, Hans De Goede, Emilio Lopez, wens Tsai,
sameo-VuQAYsv1563Yd54FQh9/CA, Dmitry Torokhov,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Liam Girdwood, Mark Brown,
Lee Jones, boris.brezillon-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <CAOQ7t2ay7UNiCZyUw4RrQ+4O1CYUht32U_OSYkbVWRLUq8_hZw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2393 bytes --]
On Thu, May 08, 2014 at 10:17:16AM +0200, Carlo Caione wrote:
> On Thu, May 8, 2014 at 4:53 AM, Maxime Ripard
> <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
>
> <snip>
>
> > What I mean is that no information is still better than wrong
> > informations. If you don't have the schematics, then don't do anything
> > on this boards. Hopefully, someone with more infos on this will know
> > what to do.
>
> I partially agree here. Not specifying the voltage range for the
> regulators but only keeping them always-on from a practical point of
> view means that we do nothing with those regulators (see also
> https://www.mail-archive.com/linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org/msg09532.html
> )
But we don't even know if they are used on these boards or not in the
first place..
> > Moreover, I have the feeling that you just copy pasted all the
> > informations on this patch. The first example I'm seeing is the
> > cubieboard, for which we do have the schematics, and this patch says
> > that ldo4 is used for HDMI, and that is required to stays always on,
> > while LDO4 doesn't seem to be used at all, and that HDMI takes
> > directly its input source from DC-5V.
>
> The names for the regulators are taken from the original Allwinner
> driver and (of course) they can have nothing to do with the function
> they have in the board. I agree that this could be misleading so I'll
> change them with more general names. Concerning LDO4 that is always
> on, it was off until this v4, but I changed it back to have one common
> DT representation among all the boards.
I'm sorry, you did a great job on this PMIC driver, but this is just
wrong. I'm completely fine with the names. What I'm not fine with is
all this "one common DT representation across all boards". Pretty much
all the boards are wired differently when it comes to regulators. Why
do you want to just do some copy pasting without any checking on the
schematics side if not just for the joy of duplicating code?
> > I guess you need some more refining on this patch.
>
> Ok, I'll submit a v6 only for this patch.
Please, please, *please* make sure that the informations you put in
there are actually accurate.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 1/2] Input: wacom: Add support for 0x116 sensor on Win8 Panasonic CF-H2
From: Jason Gerecke @ 2014-05-10 1:30 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pingc; +Cc: Jason Gerecke
The Win8 version of the Panasonic CF-H2 includes a new Wacom device.
The pen interface appears to use the same protocol as before, but the
touch interface has been tweaked to send Win8-compatible reports.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
drivers/input/tablet/wacom_wac.c | 8 ++++++++
drivers/input/tablet/wacom_wac.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index a4d8f1d..e4566c3 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -1107,6 +1107,10 @@ static int wacom_tpc_single_touch(struct wacom_wac *wacom, size_t len)
prox = data[0] & 0x01;
x = get_unaligned_le16(&data[1]);
y = get_unaligned_le16(&data[3]);
+ } else if (len == WACOM_PKGLEN_TPC1FG_B) {
+ prox = data[2] & 0x01;
+ x = le16_to_cpup((__le16 *)&data[3]);
+ y = le16_to_cpup((__le16 *)&data[5]);
} else {
prox = data[1] & 0x01;
x = le16_to_cpup((__le16 *)&data[2]);
@@ -2298,6 +2302,9 @@ static const struct wacom_features wacom_features_0x10E =
static const struct wacom_features wacom_features_0x10F =
{ "Wacom ISDv4 10F", WACOM_PKGLEN_MTTPC, 27760, 15694, 255,
0, MTTPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0x116 =
+ { "Wacom ISDv4 116", WACOM_PKGLEN_GRAPHIRE, 26202, 16325, 255,
+ 0, TABLETPCE, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
static const struct wacom_features wacom_features_0x4001 =
{ "Wacom ISDv4 4001", WACOM_PKGLEN_MTTPC, 26202, 16325, 255,
0, MTTPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
@@ -2512,6 +2519,7 @@ const struct usb_device_id wacom_ids[] = {
{ USB_DEVICE_WACOM(0x10D) },
{ USB_DEVICE_WACOM(0x10E) },
{ USB_DEVICE_WACOM(0x10F) },
+ { USB_DEVICE_WACOM(0x116) },
{ USB_DEVICE_WACOM(0x300) },
{ USB_DEVICE_WACOM(0x301) },
{ USB_DEVICE_DETAILED(0x302, USB_CLASS_HID, 0, 0) },
diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
index 9f947c3..adf73cb 100644
--- a/drivers/input/tablet/wacom_wac.h
+++ b/drivers/input/tablet/wacom_wac.h
@@ -22,6 +22,7 @@
#define WACOM_PKGLEN_BBFUN 9
#define WACOM_PKGLEN_INTUOS 10
#define WACOM_PKGLEN_TPC1FG 5
+#define WACOM_PKGLEN_TPC1FG_B 10
#define WACOM_PKGLEN_TPC2FG 14
#define WACOM_PKGLEN_BBTOUCH 20
#define WACOM_PKGLEN_BBTOUCH3 64
--
1.9.2
^ permalink raw reply related
* [PATCH 2/2] Input: wacom: Add support for three new ISDv4 sensors
From: Jason Gerecke @ 2014-05-10 1:30 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pingc; +Cc: Jason Gerecke
In-Reply-To: <1399685417-2063-1-git-send-email-killertofu@gmail.com>
This patch adds support for the 0x4004, 0x5000, and 0x5002 sensors found
on what should be the Motion R12, Fujitsu Q704, and Fujitsu T904. These
tablets use a new report ID (3) for their touch packets and a slightly
different HID descriptor format, but are otherwise largely identical in
protocol to the "MTTPC" tablets.
Note:
* The R12 uses its 0x4004 sensor for touch input only. A pen interface
is not present in its HID descriptor, though its possible a 0x4004
may be used for pen input by other tablet PCs in the future.
* The 0x5002 sensor appears to use a new report ID (8) for its pen
packets. The other sensors continue to use the traditional report
ID (2).
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
drivers/input/tablet/wacom_sys.c | 19 +++++++++++++++++++
drivers/input/tablet/wacom_wac.c | 20 +++++++++++++++++++-
drivers/input/tablet/wacom_wac.h | 3 +++
3 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index b16ebef..0056a6d 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -364,6 +364,7 @@ static int wacom_parse_hid(struct usb_interface *intf,
break;
case MTTPC:
+ case MTTPC_B:
features->pktlen = WACOM_PKGLEN_MTTPC;
break;
@@ -395,6 +396,16 @@ static int wacom_parse_hid(struct usb_interface *intf,
i += 12;
break;
+ case MTTPC_B:
+ features->x_max =
+ get_unaligned_le16(&report[i + 3]);
+ features->x_phy =
+ get_unaligned_le16(&report[i + 6]);
+ features->unit = report[i - 5];
+ features->unitExpo = report[i - 3];
+ i += 9;
+ break;
+
default:
features->x_max =
get_unaligned_le16(&report[i + 3]);
@@ -447,6 +458,14 @@ static int wacom_parse_hid(struct usb_interface *intf,
i += 12;
break;
+ case MTTPC_B:
+ features->y_max =
+ get_unaligned_le16(&report[i + 3]);
+ features->y_phy =
+ get_unaligned_le16(&report[i + 6]);
+ i += 9;
+ break;
+
default:
features->y_max =
features->x_max;
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index e4566c3..12da87e 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -1022,7 +1022,7 @@ static int wacom_mt_touch(struct wacom_wac *wacom)
int x_offset = 0;
/* MTTPC does not support Height and Width */
- if (wacom->features.type == MTTPC)
+ if (wacom->features.type == MTTPC || wacom->features.type == MTTPC_B)
x_offset = -4;
/*
@@ -1179,6 +1179,9 @@ static int wacom_tpc_irq(struct wacom_wac *wacom, size_t len)
case WACOM_PKGLEN_TPC2FG:
return wacom_tpc_mt_touch(wacom);
+ case WACOM_PKGLEN_PENABLED:
+ return wacom_tpc_pen(wacom);
+
default:
switch (data[0]) {
case WACOM_REPORT_TPC1FG:
@@ -1188,6 +1191,7 @@ static int wacom_tpc_irq(struct wacom_wac *wacom, size_t len)
return wacom_tpc_single_touch(wacom, len);
case WACOM_REPORT_TPCMT:
+ case WACOM_REPORT_TPCMT2:
return wacom_mt_touch(wacom);
case WACOM_REPORT_PENABLED:
@@ -1530,6 +1534,7 @@ void wacom_wac_irq(struct wacom_wac *wacom_wac, size_t len)
case TABLETPC2FG:
case MTSCREEN:
case MTTPC:
+ case MTTPC_B:
sync = wacom_tpc_irq(wacom_wac, len);
break;
@@ -1871,6 +1876,7 @@ int wacom_setup_input_capabilities(struct input_dev *input_dev,
case MTSCREEN:
case MTTPC:
+ case MTTPC_B:
case TABLETPC2FG:
if (features->device_type == BTN_TOOL_FINGER) {
unsigned int flags = INPUT_MT_DIRECT;
@@ -2308,6 +2314,15 @@ static const struct wacom_features wacom_features_0x116 =
static const struct wacom_features wacom_features_0x4001 =
{ "Wacom ISDv4 4001", WACOM_PKGLEN_MTTPC, 26202, 16325, 255,
0, MTTPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0x4004 =
+ { "Wacom ISDv4 4004", WACOM_PKGLEN_MTTPC, 11060, 6220, 255,
+ 0, MTTPC_B, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0x5000 =
+ { "Wacom ISDv4 5000", WACOM_PKGLEN_MTTPC, 27848, 15752, 1023,
+ 0, MTTPC_B, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0x5002 =
+ { "Wacom ISDv4 5002", WACOM_PKGLEN_MTTPC, 29576, 16724, 1023,
+ 0, MTTPC_B, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
static const struct wacom_features wacom_features_0x47 =
{ "Wacom Intuos2 6x8", WACOM_PKGLEN_INTUOS, 20320, 16240, 1023,
31, INTUOS, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
@@ -2530,6 +2545,9 @@ const struct usb_device_id wacom_ids[] = {
{ USB_DEVICE_DETAILED(0x315, USB_CLASS_HID, 0, 0) },
{ USB_DEVICE_DETAILED(0x317, USB_CLASS_HID, 0, 0) },
{ USB_DEVICE_WACOM(0x4001) },
+ { USB_DEVICE_WACOM(0x4004) },
+ { USB_DEVICE_WACOM(0x5000) },
+ { USB_DEVICE_WACOM(0x5002) },
{ USB_DEVICE_WACOM(0x47) },
{ USB_DEVICE_WACOM(0xF4) },
{ USB_DEVICE_WACOM(0xF8) },
diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
index adf73cb..84013a7 100644
--- a/drivers/input/tablet/wacom_wac.h
+++ b/drivers/input/tablet/wacom_wac.h
@@ -31,6 +31,7 @@
#define WACOM_PKGLEN_MTOUCH 62
#define WACOM_PKGLEN_MTTPC 40
#define WACOM_PKGLEN_DTUS 68
+#define WACOM_PKGLEN_PENABLED 8
/* wacom data size per MT contact */
#define WACOM_BYTES_PER_MT_PACKET 11
@@ -53,6 +54,7 @@
#define WACOM_REPORT_TPC1FG 6
#define WACOM_REPORT_TPC2FG 13
#define WACOM_REPORT_TPCMT 13
+#define WACOM_REPORT_TPCMT2 3
#define WACOM_REPORT_TPCHID 15
#define WACOM_REPORT_TPCST 16
#define WACOM_REPORT_DTUS 17
@@ -106,6 +108,7 @@ enum {
TABLETPC2FG,
MTSCREEN,
MTTPC,
+ MTTPC_B,
MAX_TYPE
};
--
1.9.2
^ 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