* [PATCH] Input: wacom: Use unaligned access where necessary
From: Jason Gerecke @ 2014-05-14 23:46 UTC (permalink / raw)
To: linux-input, pingc, dmitry.torokhov; +Cc: Jason Gerecke
A few caes of incorrectly using 'le16_to_cpup' instead of
'get_unaligned_le16' have been noticed and fixed.
Signed-off-by: Jason Gerecke <killertofu@gmail.com>
---
drivers/input/tablet/wacom_wac.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 1c779a6..20ea522 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -988,12 +988,12 @@ static int wacom_24hdt_irq(struct wacom_wac *wacom)
input_mt_report_slot_state(input, MT_TOOL_FINGER, touch);
if (touch) {
- int t_x = le16_to_cpup((__le16 *)&data[offset + 2]);
- int c_x = le16_to_cpup((__le16 *)&data[offset + 4]);
- int t_y = le16_to_cpup((__le16 *)&data[offset + 6]);
- int c_y = le16_to_cpup((__le16 *)&data[offset + 8]);
- int w = le16_to_cpup((__le16 *)&data[offset + 10]);
- int h = le16_to_cpup((__le16 *)&data[offset + 12]);
+ int t_x = get_unaligned_le16(&data[offset + 2]);
+ int c_x = get_unaligned_le16(&data[offset + 4]);
+ int t_y = get_unaligned_le16(&data[offset + 6]);
+ int c_y = get_unaligned_le16(&data[offset + 8]);
+ int w = get_unaligned_le16(&data[offset + 10]);
+ int h = get_unaligned_le16(&data[offset + 12]);
input_report_abs(input, ABS_MT_POSITION_X, t_x);
input_report_abs(input, ABS_MT_POSITION_Y, t_y);
@@ -1038,7 +1038,7 @@ static int wacom_mt_touch(struct wacom_wac *wacom)
for (i = 0; i < contacts_to_send; i++) {
int offset = (WACOM_BYTES_PER_MT_PACKET + x_offset) * i + 3;
bool touch = data[offset] & 0x1;
- int id = le16_to_cpup((__le16 *)&data[offset + 1]);
+ int id = get_unaligned_le16(&data[offset + 1]);
int slot = input_mt_get_slot_by_key(input, id);
if (slot < 0)
@@ -1047,8 +1047,8 @@ static int wacom_mt_touch(struct wacom_wac *wacom)
input_mt_slot(input, slot);
input_mt_report_slot_state(input, MT_TOOL_FINGER, touch);
if (touch) {
- int x = le16_to_cpup((__le16 *)&data[offset + x_offset + 7]);
- int y = le16_to_cpup((__le16 *)&data[offset + x_offset + 9]);
+ int x = get_unaligned_le16(&data[offset + x_offset + 7]);
+ int y = get_unaligned_le16(&data[offset + x_offset + 9]);
input_report_abs(input, ABS_MT_POSITION_X, x);
input_report_abs(input, ABS_MT_POSITION_Y, y);
}
--
1.9.2
^ permalink raw reply related
* [PATCH v2] Input: wacom: Add support for three new ISDv4 sensors
From: Jason Gerecke @ 2014-05-14 22:31 UTC (permalink / raw)
To: linux-input, pingc, dmitry.torokhov; +Cc: Jason Gerecke
In-Reply-To: <20140514184624.GH30089@core.coreip.homeip.net>
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>
---
Changes from v1:
* None; rebased.
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 5baab92..1c779a6 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
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Michal Malý @ 2014-05-14 19:40 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, linux-kernel, jkosina, elias.vds, anssi.hannula,
simon
In-Reply-To: <20140514181402.GF30089@core.coreip.homeip.net>
On Wednesday 14 of May 2014 11:14:02 Dmitry Torokhov wrote:
> On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> > +
> > +/** input_ff_create_mlnx() - Register a device within ff-memless-next and
> > + * the kernel force feedback system
> > + * @dev: Pointer to the struct input_dev associated with the device.
> > + * @data: Any device-specific data that shall be passed to the callback.
> > + * function called by ff-memless-next when a force feedback action
> > + * shall be performed.
> > + * @control_effect: Pointer to the callback function.
> > + * @update_date: Delay in milliseconds between two recalculations of
> > periodic + * effects, ramp effects and envelopes. Note that
> > this value will + * never be lower than (CONFIG_HZ / 1000)
> > + 1 regardless of the + * value specified here. This is not
> > a "hard" rate limiter. + * Userspace still can submit
> > effects at a rate faster than + * this value.
>
> The update rate change seems useful whether we use new ff implementation
> or enhance the old one but I would prefer having a separate call to
> control it.
OK, that should not be a problem. Please note that the plan is to use this
value to do proper "hard" rate limiting in the future.
--
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 v4 01/24] input: Add ff-memless-next module
From: Michal Malý @ 2014-05-14 19:38 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, linux-kernel, jkosina, elias.vds, anssi.hannula,
simon, edwin
In-Reply-To: <20140514180558.GB30089@core.coreip.homeip.net>
On Wednesday 14 of May 2014 11:05:58 Dmitry Torokhov wrote:
> On Wed, May 14, 2014 at 10:35:25AM +0200, Michal Malý wrote:
> > Hi Dmitry,
> >
> > thank you for reviewing this.
> >
> > On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:
> > > On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> > > > +
> > > > +/** DEFINITION OF TERMS
> > > > + *
> > > > + * Combined effect - An effect whose force is a superposition of
> > > > forces
> > > > + * generated by all effects that can be added
> > > > together.
> > > > + * Only one combined effect can be playing at a
> > > > time.
> > > > + * Effects that can be added together to create a
> > > > combined + * effect are FF_CONSTANT, FF_PERIODIC and
> > > > FF_RAMP. + * Uncombinable effect - An effect that cannot be combined
> > > > with
> > > > another effect. + * All conditional effects -
> > > > FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
> > > > FF_SPRING are uncombinable. + * Number of
> > > > uncombinable effects playing simultaneously + *
> > > > depends on the capabilities of the hardware. + * Rumble effect - An
> > > > effect generated by device's rumble motors instead of + *
> > > > force feedback actuators.
> > > > + *
> > > > + *
> > > > + * HANDLING OF UNCOMBINABLE EFFECTS
> > > > + *
> > > > + * Uncombinable effects cannot be combined together into just one
> > > > effect,
> > > > at + * least not in a clear and obvious manner. Therefore these
> > > > effects
> > > > have to + * be handled individually by ff-memless-next. Handling of
> > > > these
> > > > effects is + * left entirely to the hardware-specific driver,
> > > > ff-memless-next merely + * passes these effects to the
> > > > hardware-specific
> > > > driver at appropriate time. + * ff-memless-next provides the UPLOAD
> > > > command to notify the hardware-specific + * driver that the userspace
> > > > is
> > > > about to request playback of an uncombinable + * effect. The
> > > > hardware-specific driver shall take all steps needed to make + * the
> > > > device ready to play the effect when it receives the UPLOAD command. +
> > > > *
> > > > The actual playback shall commence when START_UNCOMB command is
> > > > received.
> > > > + * Opposite to the UPLOAD command is the ERASE command which tells +
> > > > *
> > > > the hardware-specific driver that the playback has finished and that +
> > > > *
> > > > the effect will not be restarted. STOP_UNCOMB command tells
> > > > + * the hardware-specific driver that the playback shall stop but the
> > > > device + * shall still be ready to resume the playback immediately.
> > > > + *
> > > > + * In case it is not possible to make the device ready to play an
> > > > uncombinable + * effect (all hardware effect slots are occupied), the
> > > > hardware-specific + * driver may return an error when it receives an
> > > > UPLOAD command. If the
> > >
> > > This part concerns me. It seems to me that devices supporting
> > > "uncombinable" effects are in fact not memoryless devices and we should
> > > not be introducing this term here. If the goal is to work around limited
> > > number of effect slots in the devices by combining certain effects then
> > > it needs to be done at ff-core level as it will be potentially useful
> > > for all devices.
> >
> > Force generated by a conditional effect (referred to as "uncombinable"
> > within ff-memless-next to make the distinction clear) depends on a
> > position of the device. For instance the more a device is deflected from
> > a neutral position the greater force FF_SPRING generates. A truly
> > memoryless device would have to report its position to the driver, have
> > it calculate the appropriate force and send it back to the device. IMHO
> > such a loop would require a very high USB polling rate to play
> > conditional effects with acceptable quality.
> >
> > We know for a fact that at least many (all?) Logitech devices that support
> > conditional effects use this "semi-memoryless" approach where FF_CONSTANT
> > and FF_PERIODIC are handled in the memoryless fashion and conditional
> > effects are uploaded to the device (in a somewhat simplified form). The
> > amount of effects that can be uploaded to a device is limited which is
> > why ff-memless-next uses two steps (UPLOAD/ERASE and START/STOP) to
> > handle these effects.
> >
> > Conditional effects - even if they are of the same type - cannot be
> > effectively combined into one because superposition doesn't seem to work
> > here so they have to be processed one by one.
> >
> > If we ever come across a really memoryless device it should not be
> > particularly difficult to add another callback to ff-memless-next which
> > would emulate conditional effects with constant force.
>
> Thank you for the explanation. This further solidifies for me the idea
> that handling of such effects that are in fact uploaded to and managed
> by the device should not be handled by the memoryless core but rather by
> the driver itself. I.e. such drivers should implement their own play(),
> upload(), erase(), etc, and decide whether to use a hardware slot for
> the effect or handle effect in memoryless fashion (if possible). We can
> open ff-memless to allow such drivers to use parts of memoryless
> handling.
Well, these effects are not exactly managed by the device. The only thing that
is uploaded to the device are parameters of the force to be generated. Other
parameters - such as timing - still have to be managed by the driver. Any
driver supporting conditional effects would then have to reimplement at least
the timing logic.
Another thing of concern is rate limiting. During our testing we have
discovered that some games can fire off FF commands at a very fast rate - much
faster than USB polling rate of a device. This eventually overfills the USB
submit queue and messes everything up. A proper way to fix this would be to
limit the rate at which the driver sends HW requests. We already have a few
ideas as to how to implement this in ff-memless-next. If we had the driver use
ff-memless-next to manage one category of effects and use its own logic to
manage the rest it'd be next to impossible to do this properly.
It should also be noted that ff-memless-next almost passes the conditional
effects through to the HW-specific driver that then takes care of everything. A
practical example of how this works can be found in an experimental port of
"hid-lg4ff" driver to ff-memless-next by Edwin Velds (https://github.com/edwin-v/linux-hid-lg4ff-next). The only thing that ff-memless-next does is that it
tells the HW-specific driver that such an effect such start or stop playing.
The reasoning above made me implement the support for conditional effects in
the way I did. As much as I agree that we're not dealing with purely
memoryless devices here, I believe that most more advanced FFB wheels/sticks
are in fact "semi-memoryless" and will therefore benefit from the approach used
in ff-memless-next.
Michal
--
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
* Apply for Loan
From: Skymoh Loan Firm @ 2014-05-13 17:46 UTC (permalink / raw)
To: Recipients
We offer the right solution to your financial needs.
We stand apart from other lenders because we believe in customer service,
and we stay with you until you get the results you want. In general we
offer home loans,car loans, hotel loans, commercial loans, business loans,
e.t.c, at lower interest rate of 2%. Contact us via E-MAIL:
mohammadfirm1@gmail.com, +91847945117
^ permalink raw reply
* Re: [PATCH] Input: pmic8xxx-pwrkey - Set sane default for debounce time
From: Dmitry Torokhov @ 2014-05-14 19:02 UTC (permalink / raw)
To: Stephen Boyd
Cc: linux-arm-msm, Arnd Bergmann, linux-kernel, linux-arm-kernel,
linux-input
In-Reply-To: <5339B407.1050308@codeaurora.org>
On Mon, Mar 31, 2014 at 11:29:27AM -0700, Stephen Boyd wrote:
> On 03/31/14 11:23, Dmitry Torokhov wrote:
> > On Mon, Mar 31, 2014 at 11:14:24AM -0700, Stephen Boyd wrote:
> >> If the debounce time is 0 our usage of ilog2() later on in this
> >> driver will cause undefined behavior. If CONFIG_OF=n this fact is
> >> evident to the compiler, and it emits a call to ____ilog2_NaN()
> >> which doesn't exist. Fix this by setting a sane default for
> >> debounce.
> >>
> >> Reported-by: Arnd Bergmann <arnd@arndb.de>
> >> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >> ---
> >> drivers/input/misc/pmic8xxx-pwrkey.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/input/misc/pmic8xxx-pwrkey.c b/drivers/input/misc/pmic8xxx-pwrkey.c
> >> index 1cb8fda7a166..27add04676e1 100644
> >> --- a/drivers/input/misc/pmic8xxx-pwrkey.c
> >> +++ b/drivers/input/misc/pmic8xxx-pwrkey.c
> >> @@ -92,7 +92,7 @@ static int pmic8xxx_pwrkey_probe(struct platform_device *pdev)
> >> bool pull_up;
> >>
> >> if (of_property_read_u32(pdev->dev.of_node, "debounce", &kpd_delay))
> >> - kpd_delay = 0;
> >> + kpd_delay = 15625;
> > What if somebody supplied 0 via DT? Can we check and return -EINVAL?
>
> Sure. Here's a v2.
>
> -----8<------
> From: Stephen Boyd <sboyd@codeaurora.org>
> Subject: [PATCH v2] Input: pmic8xxx-pwrkey - Set sane default for debounce
> time
>
> If the debounce time is 0 our usage of ilog2() later on in this
> driver will cause undefined behavior. If CONFIG_OF=n this fact is
> evident to the compiler, and it emits a call to ____ilog2_NaN()
> which doesn't exist. Fix this by setting a sane default for
> debounce and failing to probe if debounce is 0 in the DT.
>
> Reported-by: Arnd Bergmann <arnd@arndb.de>
> Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
Applied, thank you. Sorry for the delay.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: wacom: Add support for 0x116 sensor on Win8 Panasonic CF-H2
From: Dmitry Torokhov @ 2014-05-14 18:47 UTC (permalink / raw)
To: Ping Cheng; +Cc: Jason Gerecke, linux-input
In-Reply-To: <CAF8JNhLNR3STcRcQumUN1SchreX=kVPGA5BSpGm5PH15rMV9Pg@mail.gmail.com>
On Wed, May 14, 2014 at 11:27:27AM -0700, Ping Cheng wrote:
> On Fri, May 9, 2014 at 6:30 PM, Jason Gerecke <killertofu@gmail.com> wrote:
> > 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]);
>
> Above two lines should use get_unaligned_le16() instead.
> wacom_mt_touch() needs some cleanup too.
>
> Except that, the whole patchset looks good to me.
>
> Reviewed-by: Ping Cheng <pingc@wacom.com>
I changed le16_to_cpup to get_unaligned_le16 locally and applied, thank
you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/2] Input: wacom: Add support for three new ISDv4 sensors
From: Dmitry Torokhov @ 2014-05-14 18:46 UTC (permalink / raw)
To: Jason Gerecke; +Cc: linux-input, pingc
In-Reply-To: <1399685417-2063-2-git-send-email-killertofu@gmail.com>
On Fri, May 09, 2014 at 06:30:17PM -0700, Jason Gerecke wrote:
> 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>
Hmm, that does not apply to my next branch, could it be because I pulled
out a patch unifying some reports that Ping asked me to pull out?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 2/2] input: sun4i-ts: Add support for temperature sensor
From: Dmitry Torokhov @ 2014-05-14 18:41 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: linux-sunxi, Maxime Ripard, linux-input-u79uwXL29TY76Z2rM5mHXA,
LM Sensors, linux-arm-kernel, devicetree, Hans de Goede
In-Reply-To: <CAGb2v66EiYy3XbLqBXmOhOfHF=2DC_tOyQpdM8Q05iR6+X66zg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, May 12, 2014 at 04:44:51PM +0800, Chen-Yu Tsai wrote:
> Hi,
>
> On Sun, May 11, 2014 at 4:06 PM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> > @@ -232,14 +284,39 @@ static int sun4i_ts_probe(struct platform_device *pdev)
> > writel(STYLUS_UP_DEBOUN(5) | STYLUS_UP_DEBOUN_EN(1) | TP_MODE_EN(1),
> > ts->base + TP_CTRL1);
> >
> > - ret = input_register_device(ts->input);
> > - if (ret)
> > - return ret;
> > + hwmon = devm_hwmon_device_register_with_groups(ts->dev, "sun4i_ts",
> > + ts, sun4i_ts_groups);
>
> This fails to compile when HWMON is not selected:
>
> drivers/built-in.o: In function `sun4i_ts_probe':
> /home/wens/cubieboard/linux/drivers/input/touchscreen/sun4i-ts.c:287:
> undefined reference to `devm_hwmon_device_register_with_groups'
>
> Best do a wrapper around the hwmon related code.
> drivers/input/touchscreen/ads7846.c has something similar, albeit for voltage.
I added dependency on HWMON and applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: wacom: Add support for 0x116 sensor on Win8 Panasonic CF-H2
From: Ping Cheng @ 2014-05-14 18:27 UTC (permalink / raw)
To: Jason Gerecke; +Cc: linux-input, Dmitry Torokhov
In-Reply-To: <1399685417-2063-1-git-send-email-killertofu@gmail.com>
On Fri, May 9, 2014 at 6:30 PM, Jason Gerecke <killertofu@gmail.com> wrote:
> 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]);
Above two lines should use get_unaligned_le16() instead.
wacom_mt_touch() needs some cleanup too.
Except that, the whole patchset looks good to me.
Reviewed-by: Ping Cheng <pingc@wacom.com>
Ping
> } 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
>
> --
> 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 v4 01/24] input: Add ff-memless-next module
From: Dmitry Torokhov @ 2014-05-14 18:14 UTC (permalink / raw)
To: Michal Malý
Cc: linux-input, linux-kernel, jkosina, elias.vds, anssi.hannula,
simon
In-Reply-To: <1398524543-15012-2-git-send-email-madcatxster@devoid-pointer.net>
On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> +
> +/** input_ff_create_mlnx() - Register a device within ff-memless-next and
> + * the kernel force feedback system
> + * @dev: Pointer to the struct input_dev associated with the device.
> + * @data: Any device-specific data that shall be passed to the callback.
> + * function called by ff-memless-next when a force feedback action
> + * shall be performed.
> + * @control_effect: Pointer to the callback function.
> + * @update_date: Delay in milliseconds between two recalculations of periodic
> + * effects, ramp effects and envelopes. Note that this value will
> + * never be lower than (CONFIG_HZ / 1000) + 1 regardless of the
> + * value specified here. This is not a "hard" rate limiter.
> + * Userspace still can submit effects at a rate faster than
> + * this value.
The update rate change seems useful whether we use new ff implementation
or enhance the old one but I would prefer having a separate call to
control it.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] synaptics: Add min/max quirk for the ThinkPad W540
From: Dmitry Torokhov @ 2014-05-14 18:11 UTC (permalink / raw)
To: Hans de Goede; +Cc: linux-input, stable
In-Reply-To: <1400064364-14626-1-git-send-email-hdegoede@redhat.com>
On Wed, May 14, 2014 at 12:46:04PM +0200, Hans de Goede wrote:
> https://bugzilla.redhat.com/show_bug.cgi?id=1096436
>
> Cc: stable@vger.kernel.org
> Tested-and-reported-by: ajayr@bigfoot.com
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
*growl*
Applied, thank you.
> ---
> drivers/input/mouse/synaptics.c | 8 ++++++++
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> index d68d33f..d4c05b1 100644
> --- a/drivers/input/mouse/synaptics.c
> +++ b/drivers/input/mouse/synaptics.c
> @@ -1614,6 +1614,14 @@ static const struct dmi_system_id min_max_dmi_table[] __initconst = {
> .driver_data = (int []){1024, 5112, 2024, 4832},
> },
> {
> + /* Lenovo ThinkPad W540 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> + DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W540"),
> + },
> + .driver_data = (int []){1024, 5112, 2024, 4832},
> + },
> + {
> /* Lenovo Yoga S1 */
> .matches = {
> DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
> --
> 1.9.0
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND] input: dts: Add commonly used event types
From: Dmitry Torokhov @ 2014-05-14 18:08 UTC (permalink / raw)
To: Alexander Shiyan; +Cc: linux-input, devicetree
In-Reply-To: <1398490639-18411-1-git-send-email-shc_work@mail.ru>
On Sat, Apr 26, 2014 at 09:37:19AM +0400, Alexander Shiyan wrote:
> Patch adds commonly used event types (EV_KEY and EV_SW) to
> devicetree bindings header for input subsystem.
>
> Signed-off-by: Alexander Shiyan <shc_work@mail.ru>
Will DT folks pick it up please?
> ---
> include/dt-bindings/input/input.h | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/include/dt-bindings/input/input.h b/include/dt-bindings/input/input.h
> index 042e7b3..3a141d92 100644
> --- a/include/dt-bindings/input/input.h
> +++ b/include/dt-bindings/input/input.h
> @@ -9,6 +9,9 @@
> #ifndef _DT_BINDINGS_INPUT_INPUT_H
> #define _DT_BINDINGS_INPUT_INPUT_H
>
> +#define EV_KEY 0x01
> +#define EV_SW 0x05
> +
> #define KEY_RESERVED 0
> #define KEY_ESC 1
> #define KEY_1 2
> --
> 1.8.3.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH RESEND 1/2] input: gpio_keys_polled: Convert to devm-* API
From: Dmitry Torokhov @ 2014-05-14 18:07 UTC (permalink / raw)
To: Alexander Shiyan; +Cc: linux-input
In-Reply-To: <1399878902.755384741@f304.i.mail.ru>
On Mon, May 12, 2014 at 11:15:02AM +0400, Alexander Shiyan wrote:
> Mon, 5 May 2014 21:18:18 -0700 от Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > On Tue, Apr 29, 2014 at 08:40:59PM +0400, Alexander Shiyan wrote:
> > > Tue, 29 Apr 2014 09:36:49 -0700 от Dmitry Torokhov <dmitry.torokhov@gmail.com>:
> > > > On Tue, Apr 29, 2014 at 08:24:19PM +0400, Alexander Shiyan wrote:
> > > ...
> > > > > > > > > > On Sat, Apr 26, 2014 at 09:53:13AM +0400, Alexander Shiyan wrote:
> > > > > > > > > > > Replace existing resource handling in the driver with managed
> > > > > > > > > > > device resource, this ensures more consistent error values and
> > > > > > > > > > > simplifies error paths.
> > > > > > > > > > > kzalloc -> devm_kzalloc
> > > > > > > > > > > gpio_request_one -> devm_gpio_request_one
> > > > > > > ...
> > > > > > > > > > @@ -162,8 +160,7 @@ static struct gpio_keys_platform_data *gpio_keys_polled_get_devtree_pdata(struct
> > > > > > > > > > if (of_property_read_u32(pp, "linux,code", &button->code)) {
> > > > > > > > > > dev_err(dev, "Button without keycode: 0x%x\n",
> > > > > > > > > > button->gpio);
> > > > > > > > > > - error = -EINVAL;
> > > > > > > > > > - goto err_free_pdata;
> > > > > > > > > > + return ERR_PTR(-EINVAL);
> > > > > > > > > > }
> > > > > > > > >
> > > > > > > > > We can even use return value from of_property_read_u32() on error.
> > > > > > > > >
> > > > > > > > > All other looks OK.
> > > > > > > >
> > > > > > > > Do you have hardware that uses gpio_keys_polled?
> > > > > > >
> > > > > > > Yes.
> > > > > >
> > > > > > So did you have a chance to actually try my version(s)? I would feel
> > > > > > much better if you had ;)
> > > > >
> > > > > Unfortunately, due to the large following weekends, I cannot do it earlier
> > > > > than 2 weeks.
> > > >
> > > > That is fine, there is no rush.
> > >
> > > OK. In this case it would be nice to have a separate branch with poll-series
> > > and this patch. Can you make it?
> >
> > I just pushed new input-polldev branch containing input polldev changes
> > and your patches to gpio-keys and gpio-keys-polled. It is based on 3.14.
>
> This works for me as expected, so:
>
> Tested-by: Alexander Shiyan <shc_work@mail.ru>
Thank you Alexander, I queued them all for the next merge window.
--
Dmitry
--
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 v4 01/24] input: Add ff-memless-next module
From: Dmitry Torokhov @ 2014-05-14 18:05 UTC (permalink / raw)
To: Michal Malý
Cc: linux-input, linux-kernel, jkosina, elias.vds, anssi.hannula,
simon
In-Reply-To: <1818063.tFLKhAd1oy@sigyn>
On Wed, May 14, 2014 at 10:35:25AM +0200, Michal Malý wrote:
> Hi Dmitry,
>
> thank you for reviewing this.
>
> On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:
> > On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
> > > +
> > > +/** DEFINITION OF TERMS
> > > + *
> > > + * Combined effect - An effect whose force is a superposition of forces
> > > + * generated by all effects that can be added together.
> > > + * Only one combined effect can be playing at a time.
> > > + * Effects that can be added together to create a
> > > combined + * effect are FF_CONSTANT, FF_PERIODIC and
> > > FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
> > > another effect. + * All conditional effects -
> > > FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
> > > FF_SPRING are uncombinable. + * Number of
> > > uncombinable effects playing simultaneously + *
> > > depends on the capabilities of the hardware. + * Rumble effect - An
> > > effect generated by device's rumble motors instead of + *
> > > force feedback actuators.
> > > + *
> > > + *
> > > + * HANDLING OF UNCOMBINABLE EFFECTS
> > > + *
> > > + * Uncombinable effects cannot be combined together into just one effect,
> > > at + * least not in a clear and obvious manner. Therefore these effects
> > > have to + * be handled individually by ff-memless-next. Handling of these
> > > effects is + * left entirely to the hardware-specific driver,
> > > ff-memless-next merely + * passes these effects to the hardware-specific
> > > driver at appropriate time. + * ff-memless-next provides the UPLOAD
> > > command to notify the hardware-specific + * driver that the userspace is
> > > about to request playback of an uncombinable + * effect. The
> > > hardware-specific driver shall take all steps needed to make + * the
> > > device ready to play the effect when it receives the UPLOAD command. + *
> > > The actual playback shall commence when START_UNCOMB command is received.
> > > + * Opposite to the UPLOAD command is the ERASE command which tells + *
> > > the hardware-specific driver that the playback has finished and that + *
> > > the effect will not be restarted. STOP_UNCOMB command tells
> > > + * the hardware-specific driver that the playback shall stop but the
> > > device + * shall still be ready to resume the playback immediately.
> > > + *
> > > + * In case it is not possible to make the device ready to play an
> > > uncombinable + * effect (all hardware effect slots are occupied), the
> > > hardware-specific + * driver may return an error when it receives an
> > > UPLOAD command. If the
> > This part concerns me. It seems to me that devices supporting
> > "uncombinable" effects are in fact not memoryless devices and we should
> > not be introducing this term here. If the goal is to work around limited
> > number of effect slots in the devices by combining certain effects then
> > it needs to be done at ff-core level as it will be potentially useful
> > for all devices.
>
> Force generated by a conditional effect (referred to as "uncombinable" within
> ff-memless-next to make the distinction clear) depends on a position of the
> device. For instance the more a device is deflected from a neutral position the
> greater force FF_SPRING generates. A truly memoryless device would have to
> report its position to the driver, have it calculate the appropriate force and
> send it back to the device. IMHO such a loop would require a very high USB
> polling rate to play conditional effects with acceptable quality.
>
> We know for a fact that at least many (all?) Logitech devices that support
> conditional effects use this "semi-memoryless" approach where FF_CONSTANT and
> FF_PERIODIC are handled in the memoryless fashion and conditional effects are
> uploaded to the device (in a somewhat simplified form). The amount of effects
> that can be uploaded to a device is limited which is why ff-memless-next uses
> two steps (UPLOAD/ERASE and START/STOP) to handle these effects.
>
> Conditional effects - even if they are of the same type - cannot be effectively
> combined into one because superposition doesn't seem to work here so they have
> to be processed one by one.
>
> If we ever come across a really memoryless device it should not be
> particularly difficult to add another callback to ff-memless-next which would
> emulate conditional effects with constant force.
Thank you for the explanation. This further solidifies for me the idea
that handling of such effects that are in fact uploaded to and managed
by the device should not be handled by the memoryless core but rather by
the driver itself. I.e. such drivers should implement their own play(),
upload(), erase(), etc, and decide whether to use a hardware slot for
the effect or handle effect in memoryless fashion (if possible). We can
open ff-memless to allow such drivers to use parts of memoryless
handling.
Thanks.
--
Dmitry
--
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 v4 01/24] input: Add ff-memless-next module
From: Dmitry Torokhov @ 2014-05-14 17:58 UTC (permalink / raw)
To: simon
Cc: "Michal Malý", linux-input, linux-kernel, jkosina,
elias.vds, anssi.hannula
In-Reply-To: <ceda9d065796952132cc6ff971c0537b.squirrel@mungewell.org>
On Wed, May 14, 2014 at 11:11:40AM -0400, simon@mungewell.org wrote:
>
> > If we ever come across a really memoryless device it should not be
> > particularly difficult to add another callback to ff-memless-next which
> > would emulate conditional effects with constant force.
>
> It should be noted that some (/many?) applications/games already use the
> CF with position feedback to emulate behaviour such as springs. The feed
> back loop is simply not fast enough to do emulation of friction/inertia.
>
> I don't believe that the FF layer in the kernel should be 'tricked out'
> with lots of emulation features.
>
> As a game designer (ok... tinkerer) it's a bit of a pain that devices lie
> about what they can really do - ie. gamepads claiming periodic ability
> when all they are doing is faking it with rumble.
Would it help if kernel would indicate which effects are native and
which are emulated?
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: simon @ 2014-05-14 15:11 UTC (permalink / raw)
To: "Michal Malý"
Cc: Dmitry Torokhov, linux-input, linux-kernel, jkosina, elias.vds,
anssi.hannula, simon
In-Reply-To: <1818063.tFLKhAd1oy@sigyn>
> If we ever come across a really memoryless device it should not be
> particularly difficult to add another callback to ff-memless-next which
> would emulate conditional effects with constant force.
It should be noted that some (/many?) applications/games already use the
CF with position feedback to emulate behaviour such as springs. The feed
back loop is simply not fast enough to do emulation of friction/inertia.
I don't believe that the FF layer in the kernel should be 'tricked out'
with lots of emulation features.
As a game designer (ok... tinkerer) it's a bit of a pain that devices lie
about what they can really do - ie. gamepads claiming periodic ability
when all they are doing is faking it with rumble.
Simon.
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Support batch read of input events from fifo
From: Benjamin Tissoires @ 2014-05-14 13:43 UTC (permalink / raw)
To: Archana Patni
Cc: Srinivas Pandruvada, Jiri Kosina, Jonathan Cameron, linux-input,
Mika Westerberg, Pandruvada, Srinivas, Archana Patni,
Subramony Sesha
In-Reply-To: <52040.10.223.188.192.1400065472.squirrel@linux.intel.com>
On Wed, May 14, 2014 at 7:04 AM, <archana.patni@linux.intel.com> wrote:
>> On 05/12/2014 09:03 AM, Benjamin Tissoires wrote:
>>> Hi Srinivas,
>>>
>>> On Sat, May 10, 2014 at 2:48 PM, Srinivas Pandruvada
>>> <srinivas.pandruvada@linux.intel.com> wrote:
>>>> Hi Benjamin,
>>>>
>>>> On 05/08/2014 07:28 AM, Benjamin Tissoires 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.
>>>>>
>>>>> I can not ack this one until we can be sure not breaking other stuff.
>>>>>
>>>>> So: NACK.
>>>> I understand your reason, there may be some HID device which will have
>>>> issue
>>>> with this change.
>>>> I am interested in throwing some idea, as I am trying to keep the
>>>> devices in
>>>> deepest idle states as
>>>> long as possible. Sensors are one of the offenders.
>>>> - This driver can register i2c_driver, command callback. We can define
>>>> one
>>>> of the command to set the set the max size dynamically or fire this
>>>> logic to
>>>> empty buffers. This way, we can only enable such logic, when a sensor
>>>> hub
>>>> has capability and notifies this capability dynamically without
>>>> affecting
>>>> any other hid devices.
>>> I am OK with the logic as long as the i2c calls are independent of the
>>> HID layer. Remember that if the advertised bus is BUS_I2C, it might as
>>> well be an uhid device which will not handle the i2c calls.
>>>
>>> Another solution could be to add a HID quirk which triggers the "empty
>>> while input are here" and set this quirk in hid-sensor-hub. This way,
>>> you will be in control of it and other devices might use it as well if
>>> they support it.
>>>
>>> I am not a big fan of quirks, so I would still prefer your solution if
>>> you can control it without disturbing the HID subsystem. This will all
>>> depend where you can enable the functionality on the device.
>> I also don't like quirks as they start becoming de facto solutions.
>>
>> Archana,
>>
>> Can you prototype this using i2c_client_commands by keeping above
>> constraints?
>>
>> Thanks,
>> Srinivas
>
> Benjamin,
>
> The i2c_clients_command callback hook seems to be deprecated and not
> widely used. We had a quick check with Srinivas and he asked us to fall
> back to a quirk based approach.
>
> We will create a device specific quirk (using vendor ID) which sets up a
> batched read IRQ handler if it sees a device capable of supporting batch
> reads from the fifo. In the normal case, the current IRQ handler will
> continue to be used. As more devices support this feature, they can turn
> on the batched handler via the quirk.
>
> Does this look ok to you ?
Yep, fine by me.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH v4 01/24] input: Add ff-memless-next module
From: Elias Vanderstuyft @ 2014-05-14 11:26 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Michal Malý, linux-input, linux-kernel, Jiri Kosina,
Anssi Hannula, Simon Wood
In-Reply-To: <1818063.tFLKhAd1oy@sigyn>
On Wed, May 14, 2014 at 10:35 AM, Michal Malý
<madcatxster@devoid-pointer.net> wrote:
> Hi Dmitry,
>
> thank you for reviewing this.
>
> On Tuesday 13 of May 2014 23:38:06 Dmitry Torokhov wrote:
>> On Sat, Apr 26, 2014 at 05:02:00PM +0200, Michal Malý wrote:
>> > +
>> > +/** DEFINITION OF TERMS
>> > + *
>> > + * Combined effect - An effect whose force is a superposition of forces
>> > + * generated by all effects that can be added together.
>> > + * Only one combined effect can be playing at a time.
>> > + * Effects that can be added together to create a
>> > combined + * effect are FF_CONSTANT, FF_PERIODIC and
>> > FF_RAMP. + * Uncombinable effect - An effect that cannot be combined with
>> > another effect. + * All conditional effects -
>> > FF_DAMPER, FF_FRICTION, + * FF_INERTIA and
>> > FF_SPRING are uncombinable. + * Number of
>> > uncombinable effects playing simultaneously + *
>> > depends on the capabilities of the hardware. + * Rumble effect - An
>> > effect generated by device's rumble motors instead of + *
>> > force feedback actuators.
>> > + *
>> > + *
>> > + * HANDLING OF UNCOMBINABLE EFFECTS
>> > + *
>> > + * Uncombinable effects cannot be combined together into just one effect,
>> > at + * least not in a clear and obvious manner. Therefore these effects
>> > have to + * be handled individually by ff-memless-next. Handling of these
>> > effects is + * left entirely to the hardware-specific driver,
>> > ff-memless-next merely + * passes these effects to the hardware-specific
>> > driver at appropriate time. + * ff-memless-next provides the UPLOAD
>> > command to notify the hardware-specific + * driver that the userspace is
>> > about to request playback of an uncombinable + * effect. The
>> > hardware-specific driver shall take all steps needed to make + * the
>> > device ready to play the effect when it receives the UPLOAD command. + *
>> > The actual playback shall commence when START_UNCOMB command is received.
>> > + * Opposite to the UPLOAD command is the ERASE command which tells + *
>> > the hardware-specific driver that the playback has finished and that + *
>> > the effect will not be restarted. STOP_UNCOMB command tells
>> > + * the hardware-specific driver that the playback shall stop but the
>> > device + * shall still be ready to resume the playback immediately.
>> > + *
>> > + * In case it is not possible to make the device ready to play an
>> > uncombinable + * effect (all hardware effect slots are occupied), the
>> > hardware-specific + * driver may return an error when it receives an
>> > UPLOAD command. If the
>> This part concerns me. It seems to me that devices supporting
>> "uncombinable" effects are in fact not memoryless devices and we should
>> not be introducing this term here. If the goal is to work around limited
>> number of effect slots in the devices by combining certain effects then
>> it needs to be done at ff-core level as it will be potentially useful
>> for all devices.
>
> Force generated by a conditional effect (referred to as "uncombinable" within
> ff-memless-next to make the distinction clear) depends on a position of the
> device. For instance the more a device is deflected from a neutral position the
> greater force FF_SPRING generates. A truly memoryless device would have to
> report its position to the driver, have it calculate the appropriate force and
> send it back to the device. IMHO such a loop would require a very high USB
> polling rate to play conditional effects with acceptable quality.
>
> We know for a fact that at least many (all?) Logitech devices that support
> conditional effects use this "semi-memoryless" approach where FF_CONSTANT and
> FF_PERIODIC are handled in the memoryless fashion and conditional effects are
> uploaded to the device (in a somewhat simplified form). The amount of effects
> that can be uploaded to a device is limited which is why ff-memless-next uses
> two steps (UPLOAD/ERASE and START/STOP) to handle these effects.
>
> Conditional effects - even if they are of the same type - cannot be effectively
> combined into one because superposition doesn't seem to work here so they have
> to be processed one by one.
>
> If we ever come across a really memoryless device it should not be
> particularly difficult to add another callback to ff-memless-next which would
> emulate conditional effects with constant force.
And I should add that even the conditional effects themselves are
handled semi-memless by the Logitech devices:
the effects' time parameters are handled in a memless way: the
scheduling has to be done by the driver, and is not uploaded to the
device.
Compare this with a fully non-memless device, an example of a driver
that handles such devices: "hid-pidff.c"
Here, all effect data is sent directly to the device, also the
time-related parameters.
Elias
^ permalink raw reply
* Re: [PATCH] HID: i2c-hid: Support batch read of input events from fifo
From: archana.patni @ 2014-05-14 11:04 UTC (permalink / raw)
To: Srinivas Pandruvada
Cc: Benjamin Tissoires, Archana Patni, Jiri Kosina, Jonathan Cameron,
linux-input, Mika Westerberg, Pandruvada, Srinivas, Archana Patni,
Subramony Sesha
In-Reply-To: <5370FDA9.90309@linux.intel.com>
> On 05/12/2014 09:03 AM, Benjamin Tissoires wrote:
>> Hi Srinivas,
>>
>> On Sat, May 10, 2014 at 2:48 PM, Srinivas Pandruvada
>> <srinivas.pandruvada@linux.intel.com> wrote:
>>> Hi Benjamin,
>>>
>>> On 05/08/2014 07:28 AM, Benjamin Tissoires 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.
>>>>
>>>> I can not ack this one until we can be sure not breaking other stuff.
>>>>
>>>> So: NACK.
>>> I understand your reason, there may be some HID device which will have
>>> issue
>>> with this change.
>>> I am interested in throwing some idea, as I am trying to keep the
>>> devices in
>>> deepest idle states as
>>> long as possible. Sensors are one of the offenders.
>>> - This driver can register i2c_driver, command callback. We can define
>>> one
>>> of the command to set the set the max size dynamically or fire this
>>> logic to
>>> empty buffers. This way, we can only enable such logic, when a sensor
>>> hub
>>> has capability and notifies this capability dynamically without
>>> affecting
>>> any other hid devices.
>> I am OK with the logic as long as the i2c calls are independent of the
>> HID layer. Remember that if the advertised bus is BUS_I2C, it might as
>> well be an uhid device which will not handle the i2c calls.
>>
>> Another solution could be to add a HID quirk which triggers the "empty
>> while input are here" and set this quirk in hid-sensor-hub. This way,
>> you will be in control of it and other devices might use it as well if
>> they support it.
>>
>> I am not a big fan of quirks, so I would still prefer your solution if
>> you can control it without disturbing the HID subsystem. This will all
>> depend where you can enable the functionality on the device.
> I also don't like quirks as they start becoming de facto solutions.
>
> Archana,
>
> Can you prototype this using i2c_client_commands by keeping above
> constraints?
>
> Thanks,
> Srinivas
Benjamin,
The i2c_clients_command callback hook seems to be deprecated and not
widely used. We had a quick check with Srinivas and he asked us to fall
back to a quirk based approach.
We will create a device specific quirk (using vendor ID) which sets up a
batched read IRQ handler if it sees a device capable of supporting batch
reads from the fifo. In the normal case, the current IRQ handler will
continue to be used. As more devices support this feature, they can turn
on the batched handler via the quirk.
Does this look ok to you ?
Thanks
Archana
>
>
>> Cheers,
>> Benjamin
>>
>>> Thanks,
>>> Srinivas
>>>
>>>
>>>> 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
>>>> --
>>>> 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
* [PATCH] synaptics: Add min/max quirk for the ThinkPad W540
From: Hans de Goede @ 2014-05-14 10:46 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, Hans de Goede, stable
https://bugzilla.redhat.com/show_bug.cgi?id=1096436
Cc: stable@vger.kernel.org
Tested-and-reported-by: ajayr@bigfoot.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/input/mouse/synaptics.c | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
index d68d33f..d4c05b1 100644
--- a/drivers/input/mouse/synaptics.c
+++ b/drivers/input/mouse/synaptics.c
@@ -1614,6 +1614,14 @@ static const struct dmi_system_id min_max_dmi_table[] __initconst = {
.driver_data = (int []){1024, 5112, 2024, 4832},
},
{
+ /* Lenovo ThinkPad W540 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
+ DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W540"),
+ },
+ .driver_data = (int []){1024, 5112, 2024, 4832},
+ },
+ {
/* Lenovo Yoga S1 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
--
1.9.0
^ permalink raw reply related
* Re: [STLinux Kernel] [PATCH v4 2/7] driver: reset: sti: add keyscan for stih415
From: Maxime Coquelin @ 2014-05-14 10:00 UTC (permalink / raw)
To: Philipp Zabel
Cc: Gabriel FERNANDEZ, Dmitry Torokhov, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Grant Likely, Arnd Bergmann, olof Johansson, devicetree, kernel,
linux-doc, linux-kernel, Gabriel Fernandez, linux-input,
Lee Jones, linux-arm-kernel, Giuseppe Condorelli
In-Reply-To: <1400058953.13056.2.camel@paszta.hi.pengutronix.de>
Thanks Philipp.
On 05/14/2014 11:15 AM, Philipp Zabel wrote:
> Hi Maxime,
>
> Am Mittwoch, den 14.05.2014, 10:51 +0200 schrieb Maxime Coquelin:
>> Hi Philipp,
>>
>> I am preparing the arm_soc pull request for STi platforms.
>>
>> In this series, there are DT patches depending on this reset patch
>> (same for patch 3).
>>
>> Can I queue theses two reset patches in my pull request for arm_soc to
>> avoid compilation breakage?
>
> Yes, please do. For both of them, feel free to add my
> Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
>
> best regards
> Philipp
>
^ permalink raw reply
* Re: [STLinux Kernel] [PATCH v4 2/7] driver: reset: sti: add keyscan for stih415
From: Philipp Zabel @ 2014-05-14 9:15 UTC (permalink / raw)
To: Maxime Coquelin
Cc: Gabriel FERNANDEZ, Dmitry Torokhov, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Grant Likely, Arnd Bergmann, olof Johansson, devicetree, kernel,
linux-doc, linux-kernel, Gabriel Fernandez, linux-input,
Lee Jones, linux-arm-kernel, Giuseppe Condorelli
In-Reply-To: <53732EAB.1050709@st.com>
Hi Maxime,
Am Mittwoch, den 14.05.2014, 10:51 +0200 schrieb Maxime Coquelin:
> Hi Philipp,
>
> I am preparing the arm_soc pull request for STi platforms.
>
> In this series, there are DT patches depending on this reset patch
> (same for patch 3).
>
> Can I queue theses two reset patches in my pull request for arm_soc to
> avoid compilation breakage?
Yes, please do. For both of them, feel free to add my
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
best regards
Philipp
^ permalink raw reply
* Re: [STLinux Kernel] [PATCH v4 2/7] driver: reset: sti: add keyscan for stih415
From: Maxime Coquelin @ 2014-05-14 8:51 UTC (permalink / raw)
To: Gabriel FERNANDEZ, Dmitry Torokhov, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Grant Likely, Philipp Zabel, Arnd Bergmann, olof Johansson
Cc: devicetree, kernel, linux-doc, linux-kernel, Gabriel Fernandez,
linux-input, Lee Jones, linux-arm-kernel, Giuseppe Condorelli
In-Reply-To: <1397228856-9218-3-git-send-email-gabriel.fernandez@linaro.org>
Hi Philipp,
I am preparing the arm_soc pull request for STi platforms.
In this series, there are DT patches depending on this reset patch
(same for patch 3).
Can I queue theses two reset patches in my pull request for arm_soc to
avoid compilation breakage?
Best regards,
Maxime
On 04/11/2014 05:07 PM, Gabriel FERNANDEZ wrote:
> Add keyscan reset on stih415 reset controller.
>
> Signed-off-by: Giuseppe Condorelli <giuseppe.condorelli@st.com>
> Signed-off-by: Gabriel Fernandez <gabriel.fernandez@linaro.org>
> ---
> drivers/reset/sti/reset-stih415.c | 1 +
> include/dt-bindings/reset-controller/stih415-resets.h | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/reset/sti/reset-stih415.c b/drivers/reset/sti/reset-stih415.c
> index e6f6c41..c93fd26 100644
> --- a/drivers/reset/sti/reset-stih415.c
> +++ b/drivers/reset/sti/reset-stih415.c
> @@ -73,6 +73,7 @@ static const struct syscfg_reset_channel_data stih415_softresets[] = {
> [STIH415_USB0_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 9),
> [STIH415_USB1_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 10),
> [STIH415_USB2_SOFTRESET] = STIH415_SRST_REAR(SYSCFG_376, 11),
> + [STIH415_KEYSCAN_SOFTRESET] = STIH415_SRST_LPM(LPM_SYSCFG_1, 8),
> };
>
> static struct syscfg_reset_controller_data stih415_powerdown_controller = {
> diff --git a/include/dt-bindings/reset-controller/stih415-resets.h b/include/dt-bindings/reset-controller/stih415-resets.h
> index c2f8a66..c2329fe 100644
> --- a/include/dt-bindings/reset-controller/stih415-resets.h
> +++ b/include/dt-bindings/reset-controller/stih415-resets.h
> @@ -22,5 +22,6 @@
> #define STIH415_USB0_SOFTRESET 3
> #define STIH415_USB1_SOFTRESET 4
> #define STIH415_USB2_SOFTRESET 5
> +#define STIH415_KEYSCAN_SOFTRESET 6
>
> #endif /* _DT_BINDINGS_RESET_CONTROLLER_STIH415 */
>
^ permalink raw reply
* Re: [STLinux Kernel] [PATCH v4 0/7] Add ST Keyscan driver
From: Maxime Coquelin @ 2014-05-14 8:47 UTC (permalink / raw)
To: Gabriel FERNANDEZ, Dmitry Torokhov, Rob Herring, Pawel Moll,
Mark Rutland, Ian Campbell, Kumar Gala, Rob Landley, Russell King,
Grant Likely
Cc: devicetree, kernel, linux-doc, linux-kernel, Gabriel Fernandez,
linux-input, Lee Jones, linux-arm-kernel
In-Reply-To: <1397228856-9218-1-git-send-email-gabriel.fernandez@linaro.org>
Hi Gabi,
For the reset and DT patches:
Acked-by: Maxime Coquelin <maxime.coquelin@st.com>
Regards,
Maxime
On 04/11/2014 05:07 PM, Gabriel FERNANDEZ wrote:
>
> Changes in v4:
> - add reset controller management
> - rename 'st,debounce_us' into 'st,debounce-us' in dt binding
>
> Changes in v3: (bad manipulation)
>
> Changes in v2:
> - use standard format for matrix keymap
> - suppress __exit mark for keyscan_remove()
> - Call to keyscan_stop() shoudl go into keyscan_close() implementation
> - use of SIMPLE_DEV_PM_OPS()
> - rename compatibility name into "st,sti-keyscan"
> - suppress platform data management
> - omit vendor information
> - cosmetic change and renaming
>
> The goal of this series is to add ST Keyscan support to ST SoCs.
> The DT definition is added for STiH415 and STiH416 SoCs on
> B2000 board.
>
>
> Gabriel Fernandez (7):
> drivers: input: keyboard: st-keyscan: add keyscan driver
> driver: reset: sti: add keyscan for stih415
> driver: reset: sti: add keyscan for stih416
> ARM: STi: DT: add keyscan for stih415
> ARM: STi: DT: add keyscan for stih416
> ARM: STi: DT: add keyscan for stih41x-b2000
> ARM: multi_v7_defconfig: add ST Keyscan driver
>
> .../devicetree/bindings/input/st-keyscan.txt | 60 +++++
> arch/arm/boot/dts/stih415-pinctrl.dtsi | 16 ++
> arch/arm/boot/dts/stih415.dtsi | 12 +
> arch/arm/boot/dts/stih416-pinctrl.dtsi | 16 ++
> arch/arm/boot/dts/stih416.dtsi | 12 +
> arch/arm/boot/dts/stih41x-b2000.dtsi | 23 ++
> arch/arm/configs/multi_v7_defconfig | 1 +
> drivers/input/keyboard/Kconfig | 12 +
> drivers/input/keyboard/Makefile | 1 +
> drivers/input/keyboard/st-keyscan.c | 260 +++++++++++++++++++++
> drivers/reset/sti/reset-stih415.c | 1 +
> drivers/reset/sti/reset-stih416.c | 1 +
> .../dt-bindings/reset-controller/stih415-resets.h | 1 +
> .../dt-bindings/reset-controller/stih416-resets.h | 1 +
> 14 files changed, 417 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/st-keyscan.txt
> create mode 100644 drivers/input/keyboard/st-keyscan.c
>
^ 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