* Re: [PULL] drm-intel-next
From: Keith Packard @ 2011-10-23 22:31 UTC (permalink / raw)
To: Martin, linux-kernel
In-Reply-To: <201110231310.00443.marogge@onlinehome.de>
[-- Attachment #1: Type: text/plain, Size: 325 bytes --]
On Sun, 23 Oct 2011 13:10:00 +0200, Martin <marogge@onlinehome.de> wrote:
> I always get my hopes high when I read something like this. Maybe my Clarkdale
> based workstation will eventually get fully stable and I can close my ancient
> bugzilla entries.
Let us know if it helps...
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* [PATCH v3 6/6] Input: wacom - 3rd gen Bamboo P&Touch packet support
From: chris @ 2011-10-23 22:29 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pinglinux, rydberg; +Cc: Chris Bagwell
In-Reply-To: <1319408940-2345-1-git-send-email-chris@cnpbagwell.com>
From: Chris Bagwell <chris@cnpbagwell.com>
3rd generation Bamboo Pen and Touch tablets reuse the older
stylus packet but add an extra fixed zero pad byte to end.
The touch packets are quite different since it supports tracking
of up to 16 touches. The packet is 64-byte fixed size but contains
up to 15 smaller messages indicating data for a single touch or
for tablet button presses.
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Acked-by: Ping Cheng <pingc@wacom.com>
---
New in v3: Add comments and fix some style issues. Also removed
unneeded message count check. All pointed out by Henrik.
New in v2: Fixed a couple of indentation issues.
drivers/input/tablet/wacom_wac.c | 94 ++++++++++++++++++++++++++++++++++++--
drivers/input/tablet/wacom_wac.h | 3 +-
2 files changed, 92 insertions(+), 5 deletions(-)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index d1ced32..164bb55 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -836,6 +836,64 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
return 0;
}
+static void wacom_bpt3_touch_msg(struct wacom_wac *wacom, unsigned char *data)
+{
+ struct input_dev *input = wacom->input;
+ int slot_id = data[0] - 2; /* data[0] is between 2 and 17 */
+ bool touch = data[1] & 0x80;
+
+ touch = touch && !wacom->shared->stylus_in_proximity;
+
+ input_mt_slot(input, slot_id);
+ input_mt_report_slot_state(input, MT_TOOL_FINGER, touch);
+
+ if (touch) {
+ int x = (data[2] << 4) | (data[4] >> 4);
+ int y = (data[3] << 4) | (data[4] & 0x0f);
+ int w = data[6];
+
+ input_report_abs(input, ABS_MT_POSITION_X, x);
+ input_report_abs(input, ABS_MT_POSITION_Y, y);
+ input_report_abs(input, ABS_MT_TOUCH_MAJOR, w);
+ }
+}
+
+static void wacom_bpt3_button_msg(struct wacom_wac *wacom, unsigned char *data)
+{
+ struct input_dev *input = wacom->input;
+
+ input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
+ input_report_key(input, BTN_FORWARD, (data[1] & 0x04) != 0);
+ input_report_key(input, BTN_BACK, (data[1] & 0x02) != 0);
+ input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
+}
+
+static int wacom_bpt3_touch(struct wacom_wac *wacom)
+{
+ struct input_dev *input = wacom->input;
+ unsigned char *data = wacom->data;
+ int count = data[1] & 0x03;
+ int i;
+
+ /* data has up to 7 fixed sized 8-byte messages starting at data[2] */
+ for (i = 0; i < count; i++) {
+ int offset = (8 * i) + 2;
+ int msg_id = data[offset];
+
+ if (msg_id >= 2 && msg_id <= 17)
+ wacom_bpt3_touch_msg(wacom, data + offset);
+ else if (msg_id == 128)
+ wacom_bpt3_button_msg(wacom, data + offset);
+
+ }
+
+ input_mt_report_pointer_emulation(input, true);
+
+ input_sync(input);
+
+ return 0;
+}
+
static int wacom_bpt_pen(struct wacom_wac *wacom)
{
struct input_dev *input = wacom->input;
@@ -906,7 +964,9 @@ static int wacom_bpt_irq(struct wacom_wac *wacom, size_t len)
{
if (len == WACOM_PKGLEN_BBTOUCH)
return wacom_bpt_touch(wacom);
- else if (len == WACOM_PKGLEN_BBFUN)
+ else if (len == WACOM_PKGLEN_BBTOUCH3)
+ return wacom_bpt3_touch(wacom);
+ else if (len == WACOM_PKGLEN_BBFUN || len == WACOM_PKGLEN_BBPEN)
return wacom_bpt_pen(wacom);
return 0;
@@ -1025,9 +1085,9 @@ void wacom_setup_device_quirks(struct wacom_features *features)
features->type == BAMBOO_PT)
features->quirks |= WACOM_QUIRK_MULTI_INPUT;
- /* quirks for bamboo touch */
+ /* quirk for bamboo touch with 2 low res touches */
if (features->type == BAMBOO_PT &&
- features->device_type == BTN_TOOL_DOUBLETAP) {
+ features->pktlen == WACOM_PKGLEN_BBTOUCH) {
features->x_max <<= 5;
features->y_max <<= 5;
features->x_fuzz <<= 5;
@@ -1213,7 +1273,21 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
__set_bit(BTN_TOOL_FINGER, input_dev->keybit);
__set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
- input_mt_init_slots(input_dev, 2);
+ if (features->pktlen == WACOM_PKGLEN_BBTOUCH3) {
+ __set_bit(BTN_TOOL_TRIPLETAP,
+ input_dev->keybit);
+ __set_bit(BTN_TOOL_QUADTAP,
+ input_dev->keybit);
+
+ input_mt_init_slots(input_dev, 16);
+
+ input_set_abs_params(input_dev,
+ ABS_MT_TOUCH_MAJOR,
+ 0, 255, 0, 0);
+ } else {
+ input_mt_init_slots(input_dev, 2);
+ }
+
input_set_abs_params(input_dev, ABS_MT_POSITION_X,
0, features->x_max,
features->x_fuzz, 0);
@@ -1479,6 +1553,15 @@ static const struct wacom_features wacom_features_0xDA =
static struct wacom_features wacom_features_0xDB =
{ "Wacom Bamboo 2FG 6x8 SE", WACOM_PKGLEN_BBFUN, 21648, 13700, 1023,
31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0xDD =
+ { "Wacom Bamboo Connect", WACOM_PKGLEN_BBPEN, 14720, 9200, 1023,
+ 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0xDE =
+ { "Wacom Bamboo 16FG 4x5", WACOM_PKGLEN_BBPEN, 14720, 9200, 1023,
+ 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
+static const struct wacom_features wacom_features_0xDF =
+ { "Wacom Bamboo 16FG 6x8", WACOM_PKGLEN_BBPEN, 21648, 13700, 1023,
+ 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
static const struct wacom_features wacom_features_0x6004 =
{ "ISD-V4", WACOM_PKGLEN_GRAPHIRE, 12800, 8000, 255,
0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
@@ -1574,6 +1657,9 @@ const struct usb_device_id wacom_ids[] = {
{ USB_DEVICE_WACOM(0xD8) },
{ USB_DEVICE_WACOM(0xDA) },
{ USB_DEVICE_WACOM(0xDB) },
+ { USB_DEVICE_WACOM(0xDD) },
+ { USB_DEVICE_WACOM(0xDE) },
+ { USB_DEVICE_WACOM(0xDF) },
{ USB_DEVICE_WACOM(0xF0) },
{ USB_DEVICE_WACOM(0xCC) },
{ USB_DEVICE_WACOM(0x90) },
diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
index af94e6d..27f1d1c 100644
--- a/drivers/input/tablet/wacom_wac.h
+++ b/drivers/input/tablet/wacom_wac.h
@@ -12,7 +12,7 @@
#include <linux/types.h>
/* maximum packet length for USB devices */
-#define WACOM_PKGLEN_MAX 32
+#define WACOM_PKGLEN_MAX 64
/* packet length for individual models */
#define WACOM_PKGLEN_PENPRTN 7
@@ -23,6 +23,7 @@
#define WACOM_PKGLEN_TPC2FG 14
#define WACOM_PKGLEN_BBTOUCH 20
#define WACOM_PKGLEN_BBTOUCH3 64
+#define WACOM_PKGLEN_BBPEN 10
/* device IDs */
#define STYLUS_DEVICE_ID 0x02
--
1.7.6.4
^ permalink raw reply related
* [PATCH v3 5/6] Input: wacom - read 3rd gen Bamboo Touch HID data
From: chris @ 2011-10-23 22:28 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pinglinux, rydberg; +Cc: Chris Bagwell
In-Reply-To: <1319408940-2345-1-git-send-email-chris@cnpbagwell.com>
From: Chris Bagwell <chris@cnpbagwell.com>
Override invalid pen based pktlen and x/y_max with touch
values from HID report.
Since active area of pen and touch are same on these
devices, set physical x/y size while pen x/y_max and
resolution are still valid.
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Acked-by: Ping Cheng <pingc@wacom.com>
---
New in v3: Added packet size of Touch device to this patch to make
bisectable.
drivers/input/tablet/wacom_sys.c | 48 ++++++++++++++++++++++++++++++++++++-
drivers/input/tablet/wacom_wac.h | 1 +
2 files changed, 47 insertions(+), 2 deletions(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index 5e1539c..d19886a 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -28,7 +28,9 @@
#define HID_USAGE_Y_TILT 0x3e
#define HID_USAGE_FINGER 0x22
#define HID_USAGE_STYLUS 0x20
-#define HID_COLLECTION 0xc0
+#define HID_COLLECTION 0xa1
+#define HID_COLLECTION_LOGICAL 0x02
+#define HID_COLLECTION_END 0xc0
enum {
WCM_UNDEFINED = 0,
@@ -165,6 +167,34 @@ static void wacom_close(struct input_dev *dev)
usb_autopm_put_interface(wacom->intf);
}
+static int wacom_parse_logical_collection(unsigned char *report,
+ struct wacom_features *features)
+{
+ int length = 0;
+
+ if (features->type == BAMBOO_PT) {
+
+ /* Logical collection is only used by 3rd gen Bamboo Touch */
+ features->pktlen = WACOM_PKGLEN_BBTOUCH3;
+ features->device_type = BTN_TOOL_DOUBLETAP;
+
+ /*
+ * Stylus and Touch have same active area
+ * so compute physical size based on stylus
+ * data before its overwritten.
+ */
+ features->x_phy = (features->x_max * features->x_resolution)
+ / 100;
+ features->y_phy = (features->y_max * features->y_resolution)
+ / 100;
+
+ features->x_max = features->y_max =
+ get_unaligned_le16(&report[10]);
+ length = 11;
+ }
+ return length;
+}
+
/* Interface Descriptor of wacom devices can be incomplete and
* inconsistent so wacom_features table is used to store stylus
* device's packet lengths, various maximum values, and tablet
@@ -192,6 +222,10 @@ static void wacom_close(struct input_dev *dev)
* X/Y maximum as well as the physical size of tablet. Since touch
* interfaces haven't supported pressure or distance, this is enough
* information to override invalid values in the wacom_features table.
+ *
+ * 3rd gen Bamboo Touch no longer define a Digitizer-Finger Pysical
+ * Collection. Instead they define a Logical Collection with a single
+ * Logical Maximum for both X and Y.
*/
static int wacom_parse_hid(struct usb_interface *intf,
struct hid_descriptor *hid_desc,
@@ -354,10 +388,20 @@ static int wacom_parse_hid(struct usb_interface *intf,
}
break;
- case HID_COLLECTION:
+ case HID_COLLECTION_END:
/* reset UsagePage and Finger */
finger = usage = 0;
break;
+
+ case HID_COLLECTION:
+ i++;
+ switch (report[i]) {
+ case HID_COLLECTION_LOGICAL:
+ i += wacom_parse_logical_collection(&report[i],
+ features);
+ break;
+ }
+ break;
}
}
diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
index 53eb71b..af94e6d 100644
--- a/drivers/input/tablet/wacom_wac.h
+++ b/drivers/input/tablet/wacom_wac.h
@@ -22,6 +22,7 @@
#define WACOM_PKGLEN_TPC1FG 5
#define WACOM_PKGLEN_TPC2FG 14
#define WACOM_PKGLEN_BBTOUCH 20
+#define WACOM_PKGLEN_BBTOUCH3 64
/* device IDs */
#define STYLUS_DEVICE_ID 0x02
--
1.7.6.4
^ permalink raw reply related
* [PATCH v3 4/6] Input: wacom - relax Bamboo stylus ID check
From: chris @ 2011-10-23 22:28 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pinglinux, rydberg; +Cc: Chris Bagwell
In-Reply-To: <1319408940-2345-1-git-send-email-chris@cnpbagwell.com>
From: Chris Bagwell <chris@cnpbagwell.com>
Bit 0x02 always means tip versus eraser. Bit 0x01 is something related
to version of stylus and different values are starting to be used.
Relaxing proximity check is required to be used with 3rd generation Bamboo
Pen and Touch tablets.
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Acked-by: Ping Cheng <pingc@wacom.com>
---
drivers/input/tablet/wacom_wac.c | 7 +------
1 files changed, 1 insertions(+), 6 deletions(-)
diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
index 7fefd93..d1ced32 100644
--- a/drivers/input/tablet/wacom_wac.c
+++ b/drivers/input/tablet/wacom_wac.c
@@ -842,12 +842,7 @@ static int wacom_bpt_pen(struct wacom_wac *wacom)
unsigned char *data = wacom->data;
int prox = 0, x = 0, y = 0, p = 0, d = 0, pen = 0, btn1 = 0, btn2 = 0;
- /*
- * Similar to Graphire protocol, data[1] & 0x20 is proximity and
- * data[1] & 0x18 is tool ID. 0x30 is safety check to ignore
- * 2 unused tool ID's.
- */
- prox = (data[1] & 0x30) == 0x30;
+ prox = (data[1] & 0x20) == 0x20;
/*
* All reports shared between PEN and RUBBER tool must be
--
1.7.6.4
^ permalink raw reply related
* [PATCH v3 3/6] Input: wacom - add some comments to wacom_parse_hid
From: chris @ 2011-10-23 22:28 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pinglinux, rydberg; +Cc: Chris Bagwell
In-Reply-To: <1319408940-2345-1-git-send-email-chris@cnpbagwell.com>
From: Chris Bagwell <chris@cnpbagwell.com>
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Acked-by: Ping Cheng <pingc@wacom.com>
---
drivers/input/tablet/wacom_sys.c | 36 +++++++++++++++++++++++++++++++++++-
1 files changed, 35 insertions(+), 1 deletions(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index 620f0c3..5e1539c 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -165,7 +165,36 @@ static void wacom_close(struct input_dev *dev)
usb_autopm_put_interface(wacom->intf);
}
-static int wacom_parse_hid(struct usb_interface *intf, struct hid_descriptor *hid_desc,
+/* Interface Descriptor of wacom devices can be incomplete and
+ * inconsistent so wacom_features table is used to store stylus
+ * device's packet lengths, various maximum values, and tablet
+ * resolution based on product ID's.
+ *
+ * For devices that contain 2 interfaces, wacom_features table is
+ * inaccurate for the touch interface. Since the Interface Descriptor
+ * for touch interfaces has pretty complete data, this function exists
+ * to query tablet for this missing information instead of hard coding in
+ * an additional table.
+ *
+ * A typical Interface Descriptor for a stylus will contain a
+ * boot mouse application collection that is not of interest and this
+ * function will ignore it.
+ *
+ * It also contains a digitizer application collection that also is not
+ * of interest since any information it contains would be duplicate
+ * of what is in wacom_features. Usually it defines a report of an array
+ * of bytes that could be used as max length of the stylus packet returned.
+ * If it happens to define a Digitizer-Stylus Physical Collection then
+ * the X and Y logical values contain valid data but it is ignored.
+ *
+ * A typical Interface Descriptor for a touch interface will contain a
+ * Digitizer-Finger Physical Collection which will define both logical
+ * X/Y maximum as well as the physical size of tablet. Since touch
+ * interfaces haven't supported pressure or distance, this is enough
+ * information to override invalid values in the wacom_features table.
+ */
+static int wacom_parse_hid(struct usb_interface *intf,
+ struct hid_descriptor *hid_desc,
struct wacom_features *features)
{
struct usb_device *dev = interface_to_usbdev(intf);
@@ -306,6 +335,11 @@ static int wacom_parse_hid(struct usb_interface *intf, struct hid_descriptor *hi
i++;
break;
+ /*
+ * Requiring Stylus Usage will ignore boot mouse
+ * X/Y values and some cases of invalid Digitizer X/Y
+ * values commonly reported.
+ */
case HID_USAGE_STYLUS:
pen = 1;
i++;
--
1.7.6.4
^ permalink raw reply related
* [PATCH v3 2/6] Input: wacom - remove unused bamboo HID parsing
From: chris @ 2011-10-23 22:28 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pinglinux, rydberg; +Cc: Chris Bagwell
In-Reply-To: <1319408940-2345-1-git-send-email-chris@cnpbagwell.com>
From: Chris Bagwell <chris@cnpbagwell.com>
Bamboo's do not declared a Digitizer-Stylus so the if() was
never executed. wacom_features already contains correct stylus
packet length.
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Acked-by: Ping Cheng <pingc@wacom.com>
---
drivers/input/tablet/wacom_sys.c | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index 4f35473..620f0c3 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -245,8 +245,6 @@ static int wacom_parse_hid(struct usb_interface *intf, struct hid_descriptor *hi
/* penabled only accepts exact bytes of data */
if (features->type == TABLETPC2FG)
features->pktlen = WACOM_PKGLEN_GRAPHIRE;
- if (features->type == BAMBOO_PT)
- features->pktlen = WACOM_PKGLEN_BBFUN;
features->device_type = BTN_TOOL_PEN;
features->x_max =
get_unaligned_le16(&report[i + 3]);
@@ -295,8 +293,6 @@ static int wacom_parse_hid(struct usb_interface *intf, struct hid_descriptor *hi
/* penabled only accepts exact bytes of data */
if (features->type == TABLETPC2FG)
features->pktlen = WACOM_PKGLEN_GRAPHIRE;
- if (features->type == BAMBOO_PT)
- features->pktlen = WACOM_PKGLEN_BBFUN;
features->device_type = BTN_TOOL_PEN;
features->y_max =
get_unaligned_le16(&report[i + 3]);
--
1.7.6.4
^ permalink raw reply related
* [PATCH v3 1/6] Input: wacom - cleanup feature report for bamboos
From: chris @ 2011-10-23 22:28 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pinglinux, rydberg; +Cc: Chris Bagwell
In-Reply-To: <1319408940-2345-1-git-send-email-chris@cnpbagwell.com>
From: Chris Bagwell <chris@cnpbagwell.com>
Only the stylus interface on Bamboo's has a feature report that can
be used to set to wacom mode. The touch interface only has 1 report mode
and will return errors for those get/sets requests.
The get request was always erroring out because it was not marked as
an input request. Only down side of error was needlessly resending the
set request 5 times.
Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
Acked-by: Ping Cheng <pingc@wacom.com>
---
drivers/input/tablet/wacom_sys.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/input/tablet/wacom_sys.c b/drivers/input/tablet/wacom_sys.c
index a205055..4f35473 100644
--- a/drivers/input/tablet/wacom_sys.c
+++ b/drivers/input/tablet/wacom_sys.c
@@ -66,7 +66,8 @@ static int wacom_get_report(struct usb_interface *intf, u8 type, u8 id,
do {
retval = usb_control_msg(dev, usb_rcvctrlpipe(dev, 0),
USB_REQ_GET_REPORT,
- USB_TYPE_CLASS | USB_RECIP_INTERFACE,
+ USB_DIR_IN | USB_TYPE_CLASS |
+ USB_RECIP_INTERFACE,
(type << 8) + id,
intf->altsetting[0].desc.bInterfaceNumber,
buf, size, 100);
@@ -362,7 +363,8 @@ static int wacom_query_tablet_data(struct usb_interface *intf, struct wacom_feat
WAC_HID_FEATURE_REPORT,
report_id, rep_data, 4, 1);
} while ((error < 0 || rep_data[1] != 4) && limit++ < WAC_MSG_RETRIES);
- } else if (features->type != TABLETPC) {
+ } else if (features->type != TABLETPC &&
+ features->device_type == BTN_TOOL_PEN) {
do {
rep_data[0] = 2;
rep_data[1] = 2;
--
1.7.6.4
^ permalink raw reply related
* [PATCH v3 0/6] Add support for new (3rd generation) Bambbo P&Ts
From: chris @ 2011-10-23 22:28 UTC (permalink / raw)
To: linux-input, dmitry.torokhov, pinglinux, rydberg; +Cc: Chris Bagwell
From: Chris Bagwell <chris@cnpbagwell.com>
New in v3: Minor style and comment updates based on Henrik's
feedback in patch 6. Moved packet size definition to patch 5
to make compilable/bisectable without patch 6.
New in v2: Indentation fixes in patch 6.
Wacom has released in the last month a 3rd generation of their
Bamboo Pen and Touch line and this patch series adds support
for them all. There are 3 new models. 2 include stylus and touch
support and can track up to 16 touches. 1 is a stylus only tablet.
A squashed version of this patch series has been tested by 1 user
for each tablet type over at linuxwacom-discuss mailing list.
Chris Bagwell (6):
Input: wacom - cleanup feature report for bamboos
Input: wacom - remove unused bamboo HID parsing
Input: wacom - add some comments to wacom_parse_hid
Input: wacom - relax Bamboo stylus ID check
Input: wacom - read 3rd gen Bamboo Touch HID data
Input: wacom - 3rd gen Bamboo P&Touch packet support
drivers/input/tablet/wacom_sys.c | 94 ++++++++++++++++++++++++++++++++---
drivers/input/tablet/wacom_wac.c | 101 ++++++++++++++++++++++++++++++++++----
drivers/input/tablet/wacom_wac.h | 4 +-
3 files changed, 179 insertions(+), 20 deletions(-)
--
1.7.6.4
^ permalink raw reply
* [PATCH] serial/8250_pci: add a quirk for the kt serial controller
From: Dan Williams @ 2011-10-23 22:27 UTC (permalink / raw)
To: gregkh; +Cc: Nhan H Mai, linux-kernel, linux-serial, alan
Workaround dropped notifications in the iir register. Prevent reads
coincident with new interrupt notifications by reading the iir at most
once per interrupt.
Reported-by: Nhan H Mai <nhan.h.mai@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
---
drivers/tty/serial/8250.c | 6 +++++-
drivers/tty/serial/8250_pci.c | 15 +++++++++++++++
include/linux/pci_ids.h | 1 +
include/linux/serial_core.h | 1 +
4 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/8250.c b/drivers/tty/serial/8250.c
index 7f50999..513e728 100644
--- a/drivers/tty/serial/8250.c
+++ b/drivers/tty/serial/8250.c
@@ -1652,7 +1652,11 @@ static irqreturn_t serial8250_interrupt(int irq, void *dev_id)
up = list_entry(l, struct uart_8250_port, list);
- iir = serial_in(up, UART_IIR);
+ if (pass_counter && up->port.flags & UPF_IIR_ONCE)
+ iir = UART_IIR_NO_INT;
+ else
+ iir = serial_in(up, UART_IIR);
+
if (!(iir & UART_IIR_NO_INT)) {
serial8250_handle_port(up);
diff --git a/drivers/tty/serial/8250_pci.c b/drivers/tty/serial/8250_pci.c
index 3abeca2..4ad2fb4 100644
--- a/drivers/tty/serial/8250_pci.c
+++ b/drivers/tty/serial/8250_pci.c
@@ -1092,6 +1092,14 @@ static int skip_tx_en_setup(struct serial_private *priv,
return pci_default_setup(priv, board, port, idx);
}
+static int kt_serial_setup(struct serial_private *priv,
+ const struct pciserial_board *board,
+ struct uart_port *port, int idx)
+{
+ port->flags |= UPF_IIR_ONCE;
+ return skip_tx_en_setup(priv, board, port, idx);
+}
+
static int pci_eg20t_init(struct pci_dev *dev)
{
#if defined(CONFIG_SERIAL_PCH_UART) || defined(CONFIG_SERIAL_PCH_UART_MODULE)
@@ -1211,6 +1219,13 @@ static struct pci_serial_quirk pci_serial_quirks[] __refdata = {
.subdevice = PCI_ANY_ID,
.setup = ce4100_serial_setup,
},
+ {
+ .vendor = PCI_VENDOR_ID_INTEL,
+ .device = PCI_DEVICE_ID_INTEL_PATSBURG_KT,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = kt_serial_setup,
+ },
/*
* ITE
*/
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index ae96bbe..ed80d75 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2492,6 +2492,7 @@
#define PCI_DEVICE_ID_INTEL_IOAT 0x1a38
#define PCI_DEVICE_ID_INTEL_COUGARPOINT_LPC_MIN 0x1c41
#define PCI_DEVICE_ID_INTEL_COUGARPOINT_LPC_MAX 0x1c5f
+#define PCI_DEVICE_ID_INTEL_PATSBURG_KT 0x1d3d
#define PCI_DEVICE_ID_INTEL_PATSBURG_LPC_0 0x1d40
#define PCI_DEVICE_ID_INTEL_PATSBURG_LPC_1 0x1d41
#define PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI 0x1e31
diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h
index a5c3114..a66484b3 100644
--- a/include/linux/serial_core.h
+++ b/include/linux/serial_core.h
@@ -350,6 +350,7 @@ struct uart_port {
#define UPF_MAGIC_MULTIPLIER ((__force upf_t) (1 << 16))
#define UPF_CONS_FLOW ((__force upf_t) (1 << 23))
#define UPF_SHARE_IRQ ((__force upf_t) (1 << 24))
+#define UPF_IIR_ONCE ((__force upf_t) (1 << 25))
/* The exact UART type is known and should not be probed. */
#define UPF_FIXED_TYPE ((__force upf_t) (1 << 27))
#define UPF_BOOT_AUTOCONF ((__force upf_t) (1 << 28))
^ permalink raw reply related
* broadcom 43224 signal strength
From: Pedro Batista @ 2011-10-23 22:25 UTC (permalink / raw)
To: b43-dev
In-Reply-To: <CA+02P4YM3JTecCddRY6j4nCMRFtLmrNfPtfmzScsUoWB__uw-A@mail.gmail.com>
Hello, I'm having the same problem with BCM43225. If there is any way
I could help in the development of the driver, please tell me where to
start.
Thanks
--
Pedro Batista
http://www.laps.ufpa.br/pedro
Estudante de Engenharia de Computa??o - UFPA
Pesquisador Laborat?rio de Processamento de Sinais - UFPA
On Sun, Oct 23, 2011 at 19:10, Mat?j Gr?gr <matej.gregr@gmail.com> wrote:
> Hello,
> ?recently, I noticed, that my wireless card 14e4:4353 should be
> supported by b43 driver. I was able to get it work with 3.1r10 kernel
> and associate with my AP (great work guys!). However, I have a serious
> problem with signal strength. If I move my laptop to another room, the
> signal is lost (I still see the signal with wl driver). When I?am
> scanning for wifi networks, I see 10 wifi networks with wl driver,
> however only 1 network with b43 driver. Is there some workaround, how
> to improve the quality of the signal?
> Thanks,
> ? M.
>
> _______________________________________________
> b43-dev mailing list
> b43-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/b43-dev
>
^ permalink raw reply
* Re: [PATCH RFC V2 1/5] debugfs: Add support to print u32 array in debugfs
From: Greg KH @ 2011-10-23 22:20 UTC (permalink / raw)
To: Raghavendra K T
Cc: Virtualization, Gleb Natapov, H. Peter Anvin, Jeremy Fitzhardinge,
x86, KVM, Dave Jiang, Thomas Gleixner, Stefano Stabellini, LKML,
Sedat Dilek, Yinghai Lu, Marcelo Tosatti, Ingo Molnar, Avi Kivity,
Rik van Riel, Xen, Konrad Rzeszutek Wilk, Suzuki Poulose,
Srivatsa Vaddagiri, Peter Zijlstra
In-Reply-To: <20111023190403.16364.30897.sendpatchset@oc5400248562.ibm.com>
On Mon, Oct 24, 2011 at 12:34:04AM +0530, Raghavendra K T wrote:
> Add debugfs support to print u32-arrays in debugfs. Move the code from Xen to debugfs
> to make the code common for other users as well.
You forgot the kerneldoc for the function explaining what it is and how
to use it, and the EXPORT_SYMBOL_GPL() marking for the global function
as that's the only way it will be able to be used, right?
thanks,
greg k-h
^ permalink raw reply
* Re: [PATCH RFC V2 2/5] debugfs: Renaming of xen functions and change unsigned to u32
From: Greg KH @ 2011-10-23 22:19 UTC (permalink / raw)
To: Raghavendra K T
Cc: KVM, Konrad Rzeszutek Wilk, Sedat Dilek, Virtualization,
Jeremy Fitzhardinge, x86, H. Peter Anvin, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Gleb Natapov, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Avi Kivity, Rik van Riel, Xen, LKML,
Suzuki Poulose, Srivatsa Vaddagiri, Peter Zijlstra
In-Reply-To: <20111023190459.16364.98151.sendpatchset@oc5400248562.ibm.com>
On Mon, Oct 24, 2011 at 12:34:59AM +0530, Raghavendra K T wrote:
> Renaming of xen functions and change unsigned to u32.
Why not just rename when you move the functions? Why the extra step?
greg k-h
^ permalink raw reply
* [U-Boot] [PATCH v2] NS16550: buffer reads
From: Wolfgang Denk @ 2011-10-23 22:18 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CALButCJH8BVzfVh14D83WR2JOV89O9jvJO9VzzB7r_ZgKzZqeg@mail.gmail.com>
Dear Graeme Russ,
In message <CALButCJH8BVzfVh14D83WR2JOV89O9jvJO9VzzB7r_ZgKzZqeg@mail.gmail.com> you wrote:
>
> > Problems happen only with multi-line input, so it is perfectly fine
> > to handle just that - at the root cause, i. e. when input turns into
> > multi-line input.
>
> Can the U-Boot command line handle multiple commands per line (delimited by
> ; for example)
Yes, it can.
> If so, could it not be possible that a Kermit/ymodem command followed by a
> time consuming command on the same line cause lost input?
I don't think so. All serial transfers use a protocol - and when the
transfer is complete, it does not matter any more, because no more
data are flowing.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
History tends to exaggerate.
-- Col. Green, "The Savage Curtain", stardate 5906.4
^ permalink raw reply
* Re: [PATCH 1/3] drm/i915: Ivybridge still has fences!
From: Daniel Vetter @ 2011-10-23 22:16 UTC (permalink / raw)
To: Kenneth Graunke; +Cc: Daniel Vetter, intel-gfx
In-Reply-To: <4EA47CE1.7020102@whitecape.org>
On Sun, Oct 23, 2011 at 01:45:21PM -0700, Kenneth Graunke wrote:
> On 10/23/2011 04:23 AM, Chris Wilson wrote:
> > Regardless of the outcome of Jesse's request for an if-ladder, the
> > substance of the patches look sound.
> >
> > However, I remain unconvinced that there are 32 fence registers on IVB.
> > Daniel's evidence is based upon the size of the register map (and not
> > on the BSPEC explicitly stating a change to 32 ;-), but most tellingly
> > the bitfields for fence-number in other registers have not been updated -
> > so we can only safely allocated the first 16 anyway...
> > (For instance, FBC_CTL).
> > -Chris
>
> It sure looks like it has 32 fence registers: BSpec vol1g GT Interface
> Register [DevIVB] / GT Interface Register DevIVB / System Agent Config
> Space lists FENCE0 through FENCE31. The simulator seems to indicate
> this as well.
>
> You're right that FBC_CTL still only has 4 bits for selecting a fence,
> but notably, in the latest (WIP) version of the BSpec, it says "This
> field must be programmed to 0000b." I'm not sure how it's supposed to
> work now, but likely something has changed.
See my other mail. The cpu fence is specified in DPCF_CONTROL_SA, which
has again 4 bits on snb, but enough free room for 5 bits. Now on some
future hw I'm not allowed to talk about, these 5 bits exist (see
MPGFXTRK_CR_DPFC_CONTROL_SA_0_2_0_GTTMMADR in bspec), but unfortunately
not on ivb. So if you could hunt around in the sim code and check whether
that is already implemented on ivb, that'd be awesome.
Thanks, Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* Re: [PATCH v2 6/6] Input: wacom - 3rd gen Bamboo P&Touch packet support
From: Chris Bagwell @ 2011-10-23 22:14 UTC (permalink / raw)
To: Henrik Rydberg; +Cc: linux-input, dmitry.torokhov, pinglinux
In-Reply-To: <20111022122654.GA2368@polaris.bitmath.org>
On Sat, Oct 22, 2011 at 7:26 AM, Henrik Rydberg <rydberg@euromail.se> wrote:
> Hi Chris,
>
> looks like a neat device, please find some comments below.
Yep, its a very nice tablet for multitouch work.
>
>> 3rd generation Bamboo Pen and Touch tablets reuse the older
>> stylus packet but add an extra fixed zero pad byte to end.
>>
>> The touch packets are quite different since it supports tracking
>> of up to 16 touches. The packet is 64-byte fixed size but contains
>> up to 15 smaller messages indicating data for a single touch or
>> for tablet button presses.
>>
>> Signed-off-by: Chris Bagwell <chris@cnpbagwell.com>
>> ---
>>
>> New in v2. There were 2 sets of indentation errors that were fixed.
>> No code change. No changes in other 5 patches so only resending this
>> one.
>>
>> drivers/input/tablet/wacom_wac.c | 94 ++++++++++++++++++++++++++++++++++++--
>> drivers/input/tablet/wacom_wac.h | 4 +-
>> 2 files changed, 93 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/input/tablet/wacom_wac.c b/drivers/input/tablet/wacom_wac.c
>> index d1ced32..13d86c5 100644
>> --- a/drivers/input/tablet/wacom_wac.c
>> +++ b/drivers/input/tablet/wacom_wac.c
>> @@ -836,6 +836,64 @@ static int wacom_bpt_touch(struct wacom_wac *wacom)
>> return 0;
>> }
>>
>> +static void wacom_bpt3_touch_msg(struct wacom_wac *wacom, unsigned char *data)
>> +{
>> + struct input_dev *input = wacom->input;
>> + int slot_id = data[0] - 2;
>
> Are we sure slot_id < 0 cannot happen?
Good point. That looks suspicious to casual review. I'll add a comment there.
It can't be < 0 because the if() that calls this function makes sure
msg_id in between values 2 and 17.
>
>> + bool touch = data[1] & 0x80;
>> +
>> + touch = touch && !wacom->shared->stylus_in_proximity;
>> +
>> + input_mt_slot(input, slot_id);
>> + input_mt_report_slot_state(input, MT_TOOL_FINGER, touch);
>> +
>> + if (touch) {
>> + int x = (data[2] << 4) | (data[4] >> 4);
>> + int y = (data[3] << 4) | (data[4] & 0x0f);
>> + int w = data[6];
>> +
>> + input_report_abs(input, ABS_MT_POSITION_X, x);
>> + input_report_abs(input, ABS_MT_POSITION_Y, y);
>> + input_report_abs(input, ABS_MT_TOUCH_MAJOR, w);
>> + }
>> +}
>> +
>> +static void wacom_bpt3_button_msg(struct wacom_wac *wacom, unsigned char *data)
>> +{
>> + struct input_dev *input = wacom->input;
>> +
>> + input_report_key(input, BTN_LEFT, (data[1] & 0x08) != 0);
>> + input_report_key(input, BTN_FORWARD, (data[1] & 0x04) != 0);
>> + input_report_key(input, BTN_BACK, (data[1] & 0x02) != 0);
>> + input_report_key(input, BTN_RIGHT, (data[1] & 0x01) != 0);
>> +}
>> +
>> +static int wacom_bpt3_touch(struct wacom_wac *wacom)
>> +{
>> + struct input_dev *input = wacom->input;
>> + unsigned char *data = wacom->data;
>> + int count = data[1] & 0x03;
>> + int i;
>> +
>> + /* data has up to 7 fixed sized 8-byte messages starting at data[2] */
>> + for (i = 0; i < count && i < 8; i++) {
>
> The definition of count seems to imply that the test "i < 8" is unnecessary.
True. I'll remove that. Thanks.
>
>> + int offset = (8 * i)+2;
>
> style problem: please use ") + 2"
>
>> + int msg_id = data[offset];
>> +
>> + if (msg_id >= 2 && msg_id <= 17)
>> + wacom_bpt3_touch_msg(wacom, data+offset);
>
> ditto
>
>> + else if (msg_id == 128)
>> + wacom_bpt3_button_msg(wacom, data+offset);
>
> ditto
OK. I'll fix style issues.
Chris
>
>> +
>> + }
>> +
>> + input_mt_report_pointer_emulation(input, true);
>> +
>> + input_sync(input);
>> +
>> + return 0;
>> +}
>> +
>> static int wacom_bpt_pen(struct wacom_wac *wacom)
>> {
>> struct input_dev *input = wacom->input;
>> @@ -906,7 +964,9 @@ static int wacom_bpt_irq(struct wacom_wac *wacom, size_t len)
>> {
>> if (len == WACOM_PKGLEN_BBTOUCH)
>> return wacom_bpt_touch(wacom);
>> - else if (len == WACOM_PKGLEN_BBFUN)
>> + else if (len == WACOM_PKGLEN_BBTOUCH3)
>> + return wacom_bpt3_touch(wacom);
>> + else if (len == WACOM_PKGLEN_BBFUN || len == WACOM_PKGLEN_BBPEN)
>> return wacom_bpt_pen(wacom);
>>
>> return 0;
>> @@ -1025,9 +1085,9 @@ void wacom_setup_device_quirks(struct wacom_features *features)
>> features->type == BAMBOO_PT)
>> features->quirks |= WACOM_QUIRK_MULTI_INPUT;
>>
>> - /* quirks for bamboo touch */
>> + /* quirk for bamboo touch with 2 low res touches */
>> if (features->type == BAMBOO_PT &&
>> - features->device_type == BTN_TOOL_DOUBLETAP) {
>> + features->pktlen == WACOM_PKGLEN_BBTOUCH) {
>> features->x_max <<= 5;
>> features->y_max <<= 5;
>> features->x_fuzz <<= 5;
>> @@ -1213,7 +1273,21 @@ void wacom_setup_input_capabilities(struct input_dev *input_dev,
>> __set_bit(BTN_TOOL_FINGER, input_dev->keybit);
>> __set_bit(BTN_TOOL_DOUBLETAP, input_dev->keybit);
>>
>> - input_mt_init_slots(input_dev, 2);
>> + if (features->pktlen == WACOM_PKGLEN_BBTOUCH3) {
>> + __set_bit(BTN_TOOL_TRIPLETAP,
>> + input_dev->keybit);
>> + __set_bit(BTN_TOOL_QUADTAP,
>> + input_dev->keybit);
>> +
>> + input_mt_init_slots(input_dev, 16);
>> +
>> + input_set_abs_params(input_dev,
>> + ABS_MT_TOUCH_MAJOR,
>> + 0, 255, 0, 0);
>> + } else {
>> + input_mt_init_slots(input_dev, 2);
>> + }
>> +
>> input_set_abs_params(input_dev, ABS_MT_POSITION_X,
>> 0, features->x_max,
>> features->x_fuzz, 0);
>> @@ -1479,6 +1553,15 @@ static const struct wacom_features wacom_features_0xDA =
>> static struct wacom_features wacom_features_0xDB =
>> { "Wacom Bamboo 2FG 6x8 SE", WACOM_PKGLEN_BBFUN, 21648, 13700, 1023,
>> 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
>> +static const struct wacom_features wacom_features_0xDD =
>> + { "Wacom Bamboo Connect", WACOM_PKGLEN_BBPEN, 14720, 9200, 1023,
>> + 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
>> +static const struct wacom_features wacom_features_0xDE =
>> + { "Wacom Bamboo 16FG 4x5", WACOM_PKGLEN_BBPEN, 14720, 9200, 1023,
>> + 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
>> +static const struct wacom_features wacom_features_0xDF =
>> + { "Wacom Bamboo 16FG 6x8", WACOM_PKGLEN_BBPEN, 21648, 13700, 1023,
>> + 31, BAMBOO_PT, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
>> static const struct wacom_features wacom_features_0x6004 =
>> { "ISD-V4", WACOM_PKGLEN_GRAPHIRE, 12800, 8000, 255,
>> 0, TABLETPC, WACOM_INTUOS_RES, WACOM_INTUOS_RES };
>> @@ -1574,6 +1657,9 @@ const struct usb_device_id wacom_ids[] = {
>> { USB_DEVICE_WACOM(0xD8) },
>> { USB_DEVICE_WACOM(0xDA) },
>> { USB_DEVICE_WACOM(0xDB) },
>> + { USB_DEVICE_WACOM(0xDD) },
>> + { USB_DEVICE_WACOM(0xDE) },
>> + { USB_DEVICE_WACOM(0xDF) },
>> { USB_DEVICE_WACOM(0xF0) },
>> { USB_DEVICE_WACOM(0xCC) },
>> { USB_DEVICE_WACOM(0x90) },
>> diff --git a/drivers/input/tablet/wacom_wac.h b/drivers/input/tablet/wacom_wac.h
>> index 53eb71b..d54ffcb 100644
>> --- a/drivers/input/tablet/wacom_wac.h
>> +++ b/drivers/input/tablet/wacom_wac.h
>> @@ -12,7 +12,7 @@
>> #include <linux/types.h>
>>
>> /* maximum packet length for USB devices */
>> -#define WACOM_PKGLEN_MAX 32
>> +#define WACOM_PKGLEN_MAX 64
>>
>> /* packet length for individual models */
>> #define WACOM_PKGLEN_PENPRTN 7
>> @@ -22,6 +22,8 @@
>> #define WACOM_PKGLEN_TPC1FG 5
>> #define WACOM_PKGLEN_TPC2FG 14
>> #define WACOM_PKGLEN_BBTOUCH 20
>> +#define WACOM_PKGLEN_BBPEN 10
>> +#define WACOM_PKGLEN_BBTOUCH3 64
>>
>> /* device IDs */
>> #define STYLUS_DEVICE_ID 0x02
>> --
>> 1.7.6.4
>
> Thanks,
> Henrik
>
--
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 2/2] drm/i915: properly prefault for pread/pwrite
From: Daniel Vetter @ 2011-10-23 22:11 UTC (permalink / raw)
To: Keith Packard; +Cc: Daniel Vetter, intel-gfx, stable
In-Reply-To: <yun7h3vbjgc.fsf@aiko.keithp.com>
On Sun, Oct 23, 2011 at 12:23:47PM -0700, Keith Packard wrote:
> On Sun, 23 Oct 2011 12:18:30 +0200, Daniel Vetter <daniel@ffwll.ch> wrote:
> > Hi Keith,
> >
> > This patch isn't in your -next pull. This papers over a spurious -EFAULT
> > in the pwrite/pread paths that actually gets hit in the wild. The real fix
> > in the form of a almost complete rewrite of the pwrite/pread paths won't
> > be ready for 3.2.
>
> We had several comments wondering whether writing zeros was OK as this
> occurs before some potential error returns that should leave the buffer
> unmodified. I didn't have a better suggestion, but that seems pretty
> sketchy to me.
This patch only fixes things up so that we prefault the entire page range
and not just the first PAGE_SIZE bytes (i.e. at most 2 pages). So I don't
see the risk of extending the current behaviour to all pages. Userspace
can already see these zero writes, but only when doing something stupid.
-Daniel
--
Daniel Vetter
Mail: daniel@ffwll.ch
Mobile: +41 (0)79 365 57 48
^ permalink raw reply
* broadcom 43224 signal strength
From: Matěj Grégr @ 2011-10-23 22:10 UTC (permalink / raw)
To: b43-dev
Hello,
recently, I noticed, that my wireless card 14e4:4353 should be
supported by b43 driver. I was able to get it work with 3.1r10 kernel
and associate with my AP (great work guys!). However, I have a serious
problem with signal strength. If I move my laptop to another room, the
signal is lost (I still see the signal with wl driver). When I?am
scanning for wifi networks, I see 10 wifi networks with wl driver,
however only 1 network with b43 driver. Is there some workaround, how
to improve the quality of the signal?
Thanks,
M.
^ permalink raw reply
* Re: [stable] 2.6.32.21 - uptime related crashes?
From: Greg KH @ 2011-10-23 22:07 UTC (permalink / raw)
To: Ruben Kerkhof
Cc: linux-kernel, seto.hidetoshi, Peter Zijlstra, MINOURA Makoto,
Ingo Molnar, stable, Hervé Commowick, john stultz, Rand,
Andrew Morton, Willy Tarreau, Faidon Liambotis
In-Reply-To: <CAPed3OHzO5usHfyeD_rK8dDhcGakZF+ByzEyZZb_Tdh3U00vOg@mail.gmail.com>
On Sun, Oct 23, 2011 at 08:31:32PM +0200, Ruben Kerkhof wrote:
> On Mon, Sep 5, 2011 at 01:26, Faidon Liambotis <paravoid@debian.org> wrote:
> > On Tue, Aug 30, 2011 at 03:38:29PM -0700, Greg KH wrote:
> >> On Thu, Aug 25, 2011 at 09:56:16PM +0300, Faidon Liambotis wrote:
> >> > On Thu, Jul 21, 2011 at 08:45:25PM +0200, Ingo Molnar wrote:
> >> > > * Peter Zijlstra <peterz@infradead.org> wrote:
> >> > >
> >> > > > On Thu, 2011-07-21 at 14:50 +0200, Nikola Ciprich wrote:
> >> > > > > thanks for the patch! I'll put this on our testing boxes...
> >> > > >
> >> > > > With a patch that frobs the starting value close to overflowing I hope,
> >> > > > otherwise we'll not hear from you in like 7 months ;-)
> >> > > >
> >> > > > > Are You going to push this upstream so we can ask Greg to push this to
> >> > > > > -stable?
> >> > > >
> >> > > > Yeah, I think we want to commit this with a -stable tag, Ingo?
> >> > >
> >> > > yeah - and we also want a Reported-by tag and an explanation of how
> >> > > it can crash and why it matters in practice. I can then stick it into
> >> > > the urgent branch for Linus. (probably will only hit upstream in the
> >> > > merge window though.)
> >> >
> >> > Has this been pushed or has the problem been solved somehow? Time is
> >> > against us on this bug as more boxes will crash as they reach 200 days
> >> > of uptime...
> >> >
> >> > In any case, feel free to use me as a Reported-by, my full report of the
> >> > problem being <20110430173905.GA25641@tty.gr>.
> >> >
> >> > FWIW and if I understand correctly, my symptoms were caused by *two*
> >> > different bugs:
> >> > a) the 54 bits wraparound at 208 days that Peter fixed above,
> >> > b) a kernel crash at ~215 days related to RT tasks, fixed by
> >> > 305e6835e05513406fa12820e40e4a8ecb63743c (already in -stable).
> >>
> >> So, what do I do here as part of the .32-longterm kernel? Is there a
> >> fix that is in Linus's tree that I need to apply here?
> >>
> >> confused,
> >
> > Is this even pushed upstream? I checked Linus' tree and the proposed
> > patch is *not* merged there. I'm not really sure if it was fixed some
> > other way, though. I thought this was intended to be an "urgent" fix or
> > something?
> >
> > Regards,
> > Faidon
>
> I just had two crashes on two different machines, both with an uptime
> of 208 days.
> Both were 5520's running 2.6.34.8, but with a CONFIG_HZ of 1000
>
> 2011-10-23T16:49:18.618029+02:00 phy001 kernel: BUG: soft lockup -
> CPU#0 stuck for 17163091968s! [qemu-kvm:16949]
> 2011-10-23T16:49:18.618054+02:00 phy001 kernel: Modules linked in:
> xt_limit ebt_log ebt_limit ebt_arp ebtable_filter ebtable_nat ebtables
> ufs nls_utf8 tun ipmi_devintf ipmi_si ipmi_msghandler bridge 8021q
> garp stp llc bonding xt_comment xt_recent ip6t_REJECT
> nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm
> ioatdma i2c_i801 igb iTCO_wdt dca iTCO_vendor_support serio_raw
> i2c_core 3w_9xxx [last unloaded: scsi_wait_scan]
> 2011-10-23T16:49:18.618060+02:00 phy001 kernel: CPU 0
> 2011-10-23T16:49:18.618068+02:00 phy001 kernel: Modules linked in:
> xt_limit ebt_log ebt_limit ebt_arp ebtable_filter ebtable_nat ebtables
> ufs nls_utf8 tun ipmi_devintf ipmi_si ipmi_msghandler bridge 8021q
> garp stp llc bonding xt_comment xt_recent ip6t_REJECT
> nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 kvm_intel kvm
> ioatdma i2c_i801 igb iTCO_wdt dca iTCO_vendor_support serio_raw
> i2c_core 3w_9xxx [last unloaded: scsi_wait_scan]
> 2011-10-23T16:49:18.618072+02:00 phy001 kernel:
> 2011-10-23T16:49:18.618077+02:00 phy001 kernel: Pid: 16949, comm:
> qemu-kvm Tainted: G M 2.6.34.8-68.local.fc13.x86_64 #1
> X8DTU/X8DTU
> 2011-10-23T16:49:18.618083+02:00 phy001 kernel: RIP:
> 0010:[<ffffffffa007f92f>] [<ffffffffa007f92f>]
> kvm_arch_vcpu_ioctl_run+0x764/0xa74 [kvm]
> 2011-10-23T16:49:18.618086+02:00 phy001 kernel: RSP:
> 0018:ffff880bafa29d18 EFLAGS: 00000202
> 2011-10-23T16:49:18.618088+02:00 phy001 kernel: RAX: ffff880002000000
> RBX: ffff880bafa29dc8 RCX: ffff8805e45128a0
> 2011-10-23T16:49:18.618091+02:00 phy001 kernel: RDX: 000000000000cb80
> RSI: 0000000004b2a3a0 RDI: 000000000b630000
> 2011-10-23T16:49:18.618093+02:00 phy001 kernel: RBP: ffffffff8100a60e
> R08: 000000000000002b R09: 00000000760d0735
> 2011-10-23T16:49:18.618095+02:00 phy001 kernel: R10: 0000000000000000
> R11: 0000000000000000 R12: 0000000000000001
> 2011-10-23T16:49:18.618097+02:00 phy001 kernel: R13: ffff880bafa29cc8
> R14: ffffffffa007b536 R15: ffff880bafa29ca8
> 2011-10-23T16:49:18.618100+02:00 phy001 kernel: FS:
> 00007fe92cd38700(0000) GS:ffff880002000000(0000)
> knlGS:fffff880009b8000
> 2011-10-23T16:49:18.618102+02:00 phy001 kernel: CS: 0010 DS: 002b ES:
> 002b CR0: 0000000080050033
> 2011-10-23T16:49:18.618104+02:00 phy001 kernel: CR2: 00000000c1a00044
> CR3: 00000006b3f2e000 CR4: 00000000000026e0
> 2011-10-23T16:49:18.618107+02:00 phy001 kernel: DR0: 0000000000000000
> DR1: 0000000000000000 DR2: 0000000000000000
> 2011-10-23T16:49:18.618109+02:00 phy001 kernel: DR3: 0000000000000000
> DR6: 00000000ffff0ff0 DR7: 0000000000000400
> 2011-10-23T16:49:18.618112+02:00 phy001 kernel: Process qemu-kvm (pid:
> 16949, threadinfo ffff880bafa28000, task ffff880c242e0000)
> 2011-10-23T16:49:18.618114+02:00 phy001 kernel: Stack:
> 2011-10-23T16:49:18.618116+02:00 phy001 kernel: ffff88077b1a3ca8
> ffffffff81d3cf38 ffff8805e4513f00 ffff880c242e0000
> 2011-10-23T16:49:18.618119+02:00 phy001 kernel: <0> ffff880c242e0000
> ffff880bafa29fd8 ffff8805e4513ef8 0000000000015fd0
> 2011-10-23T16:49:18.618121+02:00 phy001 kernel: <0> 000000000000cb80
> ffff880c242e0000 ffff880bafa28000 ffff880ab43f4038
> 2011-10-23T16:49:18.618123+02:00 phy001 kernel: Call Trace:
> 2011-10-23T16:49:18.618126+02:00 phy001 kernel: [<ffffffffa006e5ba>] ?
> kvm_vcpu_ioctl+0xfd/0x56e [kvm]
> 2011-10-23T16:49:18.618129+02:00 phy001 kernel: [<ffffffff81011252>] ?
> __switch_to_xtra+0x121/0x141
> 2011-10-23T16:49:18.618131+02:00 phy001 kernel: [<ffffffff8111ad5f>] ?
> vfs_ioctl+0x32/0xa6
> 2011-10-23T16:49:18.618134+02:00 phy001 kernel: [<ffffffff8111b2d2>] ?
> do_vfs_ioctl+0x483/0x4c9
> 2011-10-23T16:49:18.618137+02:00 phy001 kernel: [<ffffffff8111b36e>] ?
> sys_ioctl+0x56/0x79
> 2011-10-23T16:49:18.618139+02:00 phy001 kernel: [<ffffffff81009c72>] ?
> system_call_fastpath+0x16/0x1b
> 2011-10-23T16:49:18.618142+02:00 phy001 kernel: Code: df ff 90 48 01
> 00 00 48 8b 55 90 65 48 8b 04 25 90 e8 00 00 f6 04 10 aa 74 05 e8 05
> 06 f9 e0 f0 41 80 0f 02 fb 66 0f 1f 44 00 00 <ff> 83 b0 00 00 00 48 8b
> b5 68 ff ff ff 83 66 14 ef 48 8b 3b 48
>
> Can the necessary fix please be pushed upstream?
I agree, again, can someone please do this?
greg k-h
^ permalink raw reply
* Re: [dm-crypt] Data recovery
From: Anna @ 2011-10-23 22:03 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <20111009175130.GA20378@tansi.org>
> >
> > Incidentally, is there any way to recover deleted files from an encrypted
> > drive.
> Arno
Well, i guess you can try this free program: http://undeletedeletedfiles.com/
it helps to restore all missing info
^ permalink raw reply
* [U-Boot] [PATCH] arch/powerpc/lib/board.c: fix build warning
From: Wolfgang Denk @ 2011-10-23 21:58 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318552994-6653-9-git-send-email-sjg@chromium.org>
Commit 1272592 "powerpc: Use getenv_ulong() in place of getenv(),
strtoul" instroduced a build warning for some PPC systems:
board.c: In function 'board_init_r':
board.c:626: warning: unused variable 's'
Fix it.
Signed-off-by: Wolfgang Denk <wd@denx.de>
---
arch/powerpc/lib/board.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index 6cb0ed6..aff1a0c 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -623,10 +623,11 @@ void board_init_f (ulong bootflag)
*/
void board_init_r (gd_t *id, ulong dest_addr)
{
- char *s;
bd_t *bd;
ulong malloc_start;
-
+#if defined(CONFIG_SYS_FLASH_CHECKSUM) || defined(CONFIG_CMD_NET)
+ char *s;
+#endif
#ifndef CONFIG_SYS_NO_FLASH
ulong flash_size;
#endif
--
1.7.6.2
^ permalink raw reply related
* Re: Performance measurement: Building openembedded-core with and without overclocking on C-i7 2600K
From: Ulf Samuelsson @ 2011-10-23 21:50 UTC (permalink / raw)
To: openembedded-devel
In-Reply-To: <201110232150.53072.roman@khimov.ru>
2011-10-23 19:50, Roman Khimov skrev:
> ? ????????? ?? 18 ??????? 2011 10:03:25 ????? Ulf Samuelsson ???????:
>> Also what happens if it it built on a fast SSD, or even a RAMdisk?
> Our main build server has two Xeons X5670 with 96 GB of RAM. It's running 24×7
> cyclicly doing clean isolated builds of all our OE projects (currently five).
> "Isolated" means that the the actual build is done inside a container (LXC)
> with no network available at all, that is a requirement for all our builds, to
> be able to take one tarball of sources, one tarball of OE tree and build the
> project somewhere in a nuclear bunker.
>
> The system is configured in such way that container is located on tmpfs (with
> size of 50 GB). The most complex build takes about hour and a half on this
> system occupying about 45 GB of space in a ramdisk.
>
> So today I tried to get some RAM vs. Linux cache statistics and switched this
> mount point over to newly created 60 GB LVM partition with ext4 on RAID0 array
> consisting of two SAS 15K drives.
>
> The system made builds for three projects is this configuration and I see no
> difference at all, usual 1-2 minutes deviation. Granted, the system has quite
> powerful disks (RAID array gives about 380 MB/sec on hdparm) and things might
> be a little different on plain SATA drives, but frankly I'd expected to see
> the difference anyway since there are lots of small files involved in a build.
>
> Maybe I should try to further degrade the disk system by creating some
> encrypted volume inside LVM, but still from what I see Linux caching and
> buffering works good enough, just give it as much RAM as you can.
>
> But then also what you'll get from RAM or disk or even CPU upgrade depends on
> what type of build you have. Upgrading developers build servers from pair of
> 4-core Opterons (don't remember exact model) with 8 GB of RAM to pair of Xeons
> E5620 with 24 GB of RAM with comparable disks gave about 20-30% of build time
> reduction for one project and 50% for another. But that builds are not
> isolated and use icecc cluster with all build servers available to the
> cluster, maybe that helps also in our situation.
>
Thanks,
I tried installing 32 bit Ubuntu 11.10 on a HDD and got results,
which are very close to the results of 64 bit ubuntu 11.10, but when I tried
hdparm the 32 bit system had 50 MB/s and the 64 bit system
had 100-110 MB/s so they are not comparable.
Also tried putting tmp/sysroots on a 3 GB tmpfs, and that only
made the build a couple of minutes faster on a 1 hour build.
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
--
Best Regards
Ulf Samuelsson
^ permalink raw reply
* [U-Boot] [PATCH] arch/arm/lib/board.c: fix build error
From: Wolfgang Denk @ 2011-10-23 21:51 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318552994-6653-3-git-send-email-sjg@chromium.org>
Commit dc8bbea "arm: Use getenv_ulong() in place of getenv(), strtoul"
introduced a build error for all ARM boards with network support:
board.c: In function 'board_init_r':
board.c:569: error: 's' undeclared (first use in this function)
board.c:569: error: (Each undeclared identifier is reported only once
board.c:569: error: for each function it appears in.)
Fix it.
Signed-off-by: Wolfgang Denk <wd@denx.de>
---
arch/arm/lib/board.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index c764844..367cf6b 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -441,6 +441,9 @@ void board_init_r(gd_t *id, ulong dest_addr)
#if !defined(CONFIG_SYS_NO_FLASH)
ulong flash_size;
#endif
+#if defined(CONFIG_CMD_NET)
+ char *s;
+#endif
gd = id;
--
1.7.6.2
^ permalink raw reply related
* [U-Boot] [PATCH 02/10] arm: Use getenv_ulong() in place of getenv(), strtoul
From: Wolfgang Denk @ 2011-10-23 21:49 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1318552994-6653-3-git-send-email-sjg@chromium.org>
Dear Simon Glass,
In message <1318552994-6653-3-git-send-email-sjg@chromium.org> you wrote:
> This changes the board code to use the new getenv_ulong() function.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> arch/arm/lib/board.c | 36 +++++++++++-------------------------
> 1 files changed, 11 insertions(+), 25 deletions(-)
Urgh...
This breaks almost all ARM boards like this:
Configuring for a320evb board...
board.c: In function 'board_init_r':
board.c:569: error: 's' undeclared (first use in this function)
board.c:569: error: (Each undeclared identifier is reported only once
board.c:569: error: for each function it appears in.)
make[1]: *** [/work/wd/tmp-arm/arch/arm/lib/board.o] Error 1
make: *** [/work/wd/tmp-arm/arch/arm/lib/libarm.o] Error 2
Didn't you run MAKELL?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
ADVISORY: There is an Extremely Small but Nonzero Chance That,
Through a Process Know as "Tunneling," This Product May Spontaneously
Disappear from Its Present Location and Reappear at Any Random Place
in the Universe, Including Your Neighbor's Domicile. The Manufacturer
Will Not Be Responsible for Any Damages or Inconvenience That May
Result.
^ permalink raw reply
* [PATCH v2 1/5] ARM: SPMP8000: Add machine base files
From: Zoltan Devai @ 2011-10-23 21:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111021225405.GK21648@n2100.arm.linux.org.uk>
2011/10/22 Russell King - ARM Linux <linux@arm.linux.org.uk>:
> On Wed, Oct 19, 2011 at 09:15:35PM +0200, Arnd Bergmann wrote:
>> > +#define SERIAL_BASE ? ? ? ?((volatile unsigned char *)SPMP8000_UARTC0_BASE)
>>
>> drop this, then
>>
>> > +static void putc(const char c)
>> > +{
>> > + ? volatile unsigned char *base = SERIAL_BASE;
>>
>> make this a "unsigned char __iomem *".
>>
>> > + ? int i;
>> > +
>> > + ? for (i = 0; i < 0x1000; i++) {
>> > + ? ? ? ? ? if (base[UART_LSR << 2] & UART_LSR_THRE)
>> > + ? ? ? ? ? ? ? ? ? break;
>> > + ? ? ? ? ? barrier();
>> > + ? }
>> > +
>> > + ? base[UART_TX << 2] = c;
>> > +}
>>
>> and use readb_relaxed/writeb_relaxed to do the access. You should
>> never just dereference volatile pointers to do an MMIO access.
>
> Note that uncompress.h isn't part of the kernel proper, and so the
> MMIO accessors may not work (depends whether the arch out-of-lines
> them.) ?Moreover, as the MMU is setup with 1:1 mappings, arguably
> it's not IOMEM anyway.
What's the preferred method then ?
The current uncompress.h files use all possible methods.
This is certainly also a question for the uncompress.h cleanup series.
Z
^ permalink raw reply
* Re: [PATCH] KVM: booke: Do Not start decrementer when SPRN_DEC set 0
From: Alexander Graf @ 2011-10-23 21:46 UTC (permalink / raw)
To: kvm-ppc
In-Reply-To: <1318909023-31003-1-git-send-email-bharat.bhushan@freescale.com>
On 20.10.2011, at 17:55, Bhushan Bharat-R65777 <R65777@freescale.com> wrote:
>
>
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf@suse.de]
>> Sent: Thursday, October 20, 2011 11:15 PM
>> To: Bhushan Bharat-R65777
>> Cc: kvm-ppc@vger.kernel.org; bharatb.yadav@gmail.com
>> Subject: Re: [PATCH] KVM: booke: Do Not start decrementer when SPRN_DEC
>> set 0
>>
>>
>> On 20.10.2011, at 10:43, Bhushan Bharat-R65777 wrote:
>>
>>>
>>>
>>>> -----Original Message-----
>>>> From: kvm-ppc-owner@vger.kernel.org [mailto:kvm-ppc-
>>>> owner@vger.kernel.org] On Behalf Of Alexander Graf
>>>> Sent: Thursday, October 20, 2011 10:40 PM
>>>> To: Bhushan Bharat-R65777
>>>> Cc: kvm-ppc@vger.kernel.org; bharatb.yadav@gmail.com; Bhushan Bharat-
>>>> R65777
>>>> Subject: Re: [PATCH] KVM: booke: Do Not start decrementer when
>>>> SPRN_DEC set 0
>>>>
>>>>
>>>> On 17.10.2011, at 20:37, Bharat Bhushan wrote:
>>>>
>>>>> As per specification the decrementer interrupt not happen when DEC
>>>>> is
>>>> written with 0. So we should not start hrtimer with timeout = 0 as
>> well.
>>>>>
>>>>> Signed-off-by: Bharat Bhushan <bharat.bhushan@freescale.com>
>>>>> ---
>>>>> arch/powerpc/kvm/emulate.c | 8 ++++----
>>>>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
>>>>> index 141dce3..8af3bad 100644
>>>>> --- a/arch/powerpc/kvm/emulate.c
>>>>> +++ b/arch/powerpc/kvm/emulate.c
>>>>> @@ -70,14 +70,14 @@
>>>>> #define OP_STHU 45
>>>>>
>>>>> #ifdef CONFIG_PPC_BOOK3S
>>>>> -static int kvmppc_dec_enabled(struct kvm_vcpu *vcpu)
>>>>> +static bool kvmppc_dec_enabled(struct kvm_vcpu *vcpu)
>>>>> {
>>>>> - return 1;
>>>>> + return true;
>>>>
>>>> It's not necessary to change it to bool. The function will be inlined
>>>> anyways.
>>>>
>>>>> }
>>>>> #else
>>>>> -static int kvmppc_dec_enabled(struct kvm_vcpu *vcpu)
>>>>> +static bool kvmppc_dec_enabled(struct kvm_vcpu *vcpu)
>>>>> {
>>>>> - return vcpu->arch.tcr & TCR_DIE;
>>>>> + return (vcpu->arch.tcr & TCR_DIE) && !vcpu->arch.dec;
>>>>
>>>> This means we declare the dec as enabled only when dec=0, no?
>>>
>>> I think we can change the name of this function as
>> kvmppc_dec_runnable() ?
>>
>> It'd still be wrong. You're declaring the DEC as running when dec = 0,
>> not when dec != 0.
>
> That I have to anyway fix,
> I mean like this:
>
> bool kvmppc_dec_runnable(struct kvm_vcpu *vcpu)
Sorry for the late reply. Please keep your patch as little intrusive as possible. Changing the name doesn't quite buy us anything atm, so please limit your patch to the actual fix :)
Alex
> {
> return (vcpu->arch.tcr & TCR_DIE) && vcpu->arch.dec;
> }
>
> Thanks
> -Bharat
>
> --
> To unsubscribe from this list: send the line "unsubscribe kvm-ppc" 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
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.