* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: Lee Jones @ 2018-12-05 9:36 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <5C069C47.6080305@st.com>
On Tue, 04 Dec 2018, Pascal PAILLET-LME wrote:
> Le 12/03/2018 08:11 AM, Lee Jones a écrit :
> > On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
> >
> >> The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from
> >> STMicroelectronics.
> >> The STPMIC1 regulators supply power to an application processor as well as
> >> to external system peripherals such as DDR, Flash memories and system
> >> devices. It also features onkey button input and an hardware watchdog.
> >> The STPMIC1 is controlled via I2C.
> >>
> >> Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and
> >> irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd
> >> as parent.
> >>
> >> STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
> >>
> >> Pascal Paillet (7):
> >> changes in v7:
> >> * rebase on regul/for-next
> >>
> >> dt-bindings: mfd: document stpmic1
> >> mfd: stpmic1: add stpmic1 driver
> >> dt-bindings: input: document stpmic1 pmic onkey
> >> input: stpmic1: add stpmic1 onkey driver
> >> dt-bindings: watchdog: document stpmic1 pmic watchdog
> >> watchdog: stpmic1: add stpmic1 watchdog driver
> >> regulator: stpmic1: fix regulator_lock usage
> >>
> >> .../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 +++
> >> .../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++++++
> >> .../bindings/watchdog/st,stpmic1-wdt.txt | 11 ++
> >> drivers/input/misc/Kconfig | 11 ++
> >> drivers/input/misc/Makefile | 2 +
> >> drivers/input/misc/stpmic1_onkey.c | 198 +++++++++++++++++++
> >> drivers/mfd/Kconfig | 16 ++
> >> drivers/mfd/Makefile | 1 +
> >> drivers/mfd/stpmic1.c | 213 +++++++++++++++++++++
> >> drivers/regulator/stpmic1_regulator.c | 2 +-
> > Is it just Mark you're waiting on now?
> It is ok now, Mark has applied the patch.
> Evrey thing has been acked now. What is the nex step ?
Mark has applied patch 7?
Why don't I see that? Should you have removed it from this set?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH AUTOSEL 4.14 16/69] iio/hid-sensors: Fix IIO_CHAN_INFO_RAW returning wrong values for signed numbers
From: Sasha Levin @ 2018-12-05 9:41 UTC (permalink / raw)
To: stable, linux-kernel
Cc: Hans de Goede, Stable, Jonathan Cameron, Sasha Levin, linux-input,
linux-iio, linux-rtc
In-Reply-To: <20181205094247.6556-1-sashal@kernel.org>
From: Hans de Goede <hdegoede@redhat.com>
[ Upstream commit 0145b50566e7de5637e80ecba96c7f0e6fff1aad ]
Before this commit sensor_hub_input_attr_get_raw_value() failed to take
the signedness of 16 and 8 bit values into account, returning e.g.
65436 instead of -100 for the z-axis reading of an accelerometer.
This commit adds a new is_signed parameter to the function and makes all
callers pass the appropriate value for this.
While at it, this commit also fixes up some neighboring lines where
statements were needlessly split over 2 lines to improve readability.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
drivers/hid/hid-sensor-custom.c | 2 +-
drivers/hid/hid-sensor-hub.c | 13 ++++++++++---
drivers/iio/accel/hid-sensor-accel-3d.c | 5 ++++-
drivers/iio/gyro/hid-sensor-gyro-3d.c | 5 ++++-
drivers/iio/humidity/hid-sensor-humidity.c | 3 ++-
drivers/iio/light/hid-sensor-als.c | 8 +++++---
drivers/iio/light/hid-sensor-prox.c | 8 +++++---
drivers/iio/magnetometer/hid-sensor-magn-3d.c | 8 +++++---
drivers/iio/orientation/hid-sensor-incl-3d.c | 8 +++++---
drivers/iio/pressure/hid-sensor-press.c | 8 +++++---
drivers/iio/temperature/hid-sensor-temperature.c | 3 ++-
drivers/rtc/rtc-hid-sensor-time.c | 2 +-
include/linux/hid-sensor-hub.h | 4 +++-
13 files changed, 52 insertions(+), 25 deletions(-)
diff --git a/drivers/hid/hid-sensor-custom.c b/drivers/hid/hid-sensor-custom.c
index 0bcf041368c7..574126b649e9 100644
--- a/drivers/hid/hid-sensor-custom.c
+++ b/drivers/hid/hid-sensor-custom.c
@@ -358,7 +358,7 @@ static ssize_t show_value(struct device *dev, struct device_attribute *attr,
sensor_inst->hsdev,
sensor_inst->hsdev->usage,
usage, report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC, false);
} else if (!strncmp(name, "units", strlen("units")))
value = sensor_inst->fields[field_index].attribute.units;
else if (!strncmp(name, "unit-expo", strlen("unit-expo")))
diff --git a/drivers/hid/hid-sensor-hub.c b/drivers/hid/hid-sensor-hub.c
index faba542d1b07..b5bd5cb7d532 100644
--- a/drivers/hid/hid-sensor-hub.c
+++ b/drivers/hid/hid-sensor-hub.c
@@ -299,7 +299,8 @@ EXPORT_SYMBOL_GPL(sensor_hub_get_feature);
int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
u32 usage_id,
u32 attr_usage_id, u32 report_id,
- enum sensor_hub_read_flags flag)
+ enum sensor_hub_read_flags flag,
+ bool is_signed)
{
struct sensor_hub_data *data = hid_get_drvdata(hsdev->hdev);
unsigned long flags;
@@ -331,10 +332,16 @@ int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
&hsdev->pending.ready, HZ*5);
switch (hsdev->pending.raw_size) {
case 1:
- ret_val = *(u8 *)hsdev->pending.raw_data;
+ if (is_signed)
+ ret_val = *(s8 *)hsdev->pending.raw_data;
+ else
+ ret_val = *(u8 *)hsdev->pending.raw_data;
break;
case 2:
- ret_val = *(u16 *)hsdev->pending.raw_data;
+ if (is_signed)
+ ret_val = *(s16 *)hsdev->pending.raw_data;
+ else
+ ret_val = *(u16 *)hsdev->pending.raw_data;
break;
case 4:
ret_val = *(u32 *)hsdev->pending.raw_data;
diff --git a/drivers/iio/accel/hid-sensor-accel-3d.c b/drivers/iio/accel/hid-sensor-accel-3d.c
index 2238a26aba63..f573d9c61fc3 100644
--- a/drivers/iio/accel/hid-sensor-accel-3d.c
+++ b/drivers/iio/accel/hid-sensor-accel-3d.c
@@ -149,6 +149,7 @@ static int accel_3d_read_raw(struct iio_dev *indio_dev,
int report_id = -1;
u32 address;
int ret_type;
+ s32 min;
struct hid_sensor_hub_device *hsdev =
accel_state->common_attributes.hsdev;
@@ -158,12 +159,14 @@ static int accel_3d_read_raw(struct iio_dev *indio_dev,
case 0:
hid_sensor_power_state(&accel_state->common_attributes, true);
report_id = accel_state->accel[chan->scan_index].report_id;
+ min = accel_state->accel[chan->scan_index].logical_minimum;
address = accel_3d_addresses[chan->scan_index];
if (report_id >= 0)
*val = sensor_hub_input_attr_get_raw_value(
accel_state->common_attributes.hsdev,
hsdev->usage, address, report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ min < 0);
else {
*val = 0;
hid_sensor_power_state(&accel_state->common_attributes,
diff --git a/drivers/iio/gyro/hid-sensor-gyro-3d.c b/drivers/iio/gyro/hid-sensor-gyro-3d.c
index c67ce2ac4715..d9192eb41131 100644
--- a/drivers/iio/gyro/hid-sensor-gyro-3d.c
+++ b/drivers/iio/gyro/hid-sensor-gyro-3d.c
@@ -111,6 +111,7 @@ static int gyro_3d_read_raw(struct iio_dev *indio_dev,
int report_id = -1;
u32 address;
int ret_type;
+ s32 min;
*val = 0;
*val2 = 0;
@@ -118,13 +119,15 @@ static int gyro_3d_read_raw(struct iio_dev *indio_dev,
case 0:
hid_sensor_power_state(&gyro_state->common_attributes, true);
report_id = gyro_state->gyro[chan->scan_index].report_id;
+ min = gyro_state->gyro[chan->scan_index].logical_minimum;
address = gyro_3d_addresses[chan->scan_index];
if (report_id >= 0)
*val = sensor_hub_input_attr_get_raw_value(
gyro_state->common_attributes.hsdev,
HID_USAGE_SENSOR_GYRO_3D, address,
report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ min < 0);
else {
*val = 0;
hid_sensor_power_state(&gyro_state->common_attributes,
diff --git a/drivers/iio/humidity/hid-sensor-humidity.c b/drivers/iio/humidity/hid-sensor-humidity.c
index 6e09c1acfe51..e53914d51ec3 100644
--- a/drivers/iio/humidity/hid-sensor-humidity.c
+++ b/drivers/iio/humidity/hid-sensor-humidity.c
@@ -75,7 +75,8 @@ static int humidity_read_raw(struct iio_dev *indio_dev,
HID_USAGE_SENSOR_HUMIDITY,
HID_USAGE_SENSOR_ATMOSPHERIC_HUMIDITY,
humid_st->humidity_attr.report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ humid_st->humidity_attr.logical_minimum < 0);
hid_sensor_power_state(&humid_st->common_attributes, false);
return IIO_VAL_INT;
diff --git a/drivers/iio/light/hid-sensor-als.c b/drivers/iio/light/hid-sensor-als.c
index 059d964772c7..95ca86f50434 100644
--- a/drivers/iio/light/hid-sensor-als.c
+++ b/drivers/iio/light/hid-sensor-als.c
@@ -93,6 +93,7 @@ static int als_read_raw(struct iio_dev *indio_dev,
int report_id = -1;
u32 address;
int ret_type;
+ s32 min;
*val = 0;
*val2 = 0;
@@ -102,8 +103,8 @@ static int als_read_raw(struct iio_dev *indio_dev,
case CHANNEL_SCAN_INDEX_INTENSITY:
case CHANNEL_SCAN_INDEX_ILLUM:
report_id = als_state->als_illum.report_id;
- address =
- HID_USAGE_SENSOR_LIGHT_ILLUM;
+ min = als_state->als_illum.logical_minimum;
+ address = HID_USAGE_SENSOR_LIGHT_ILLUM;
break;
default:
report_id = -1;
@@ -116,7 +117,8 @@ static int als_read_raw(struct iio_dev *indio_dev,
als_state->common_attributes.hsdev,
HID_USAGE_SENSOR_ALS, address,
report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ min < 0);
hid_sensor_power_state(&als_state->common_attributes,
false);
} else {
diff --git a/drivers/iio/light/hid-sensor-prox.c b/drivers/iio/light/hid-sensor-prox.c
index 73fced8a63b7..8c017abc4ee2 100644
--- a/drivers/iio/light/hid-sensor-prox.c
+++ b/drivers/iio/light/hid-sensor-prox.c
@@ -73,6 +73,7 @@ static int prox_read_raw(struct iio_dev *indio_dev,
int report_id = -1;
u32 address;
int ret_type;
+ s32 min;
*val = 0;
*val2 = 0;
@@ -81,8 +82,8 @@ static int prox_read_raw(struct iio_dev *indio_dev,
switch (chan->scan_index) {
case CHANNEL_SCAN_INDEX_PRESENCE:
report_id = prox_state->prox_attr.report_id;
- address =
- HID_USAGE_SENSOR_HUMAN_PRESENCE;
+ min = prox_state->prox_attr.logical_minimum;
+ address = HID_USAGE_SENSOR_HUMAN_PRESENCE;
break;
default:
report_id = -1;
@@ -95,7 +96,8 @@ static int prox_read_raw(struct iio_dev *indio_dev,
prox_state->common_attributes.hsdev,
HID_USAGE_SENSOR_PROX, address,
report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ min < 0);
hid_sensor_power_state(&prox_state->common_attributes,
false);
} else {
diff --git a/drivers/iio/magnetometer/hid-sensor-magn-3d.c b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
index 0e791b02ed4a..b495107bd173 100644
--- a/drivers/iio/magnetometer/hid-sensor-magn-3d.c
+++ b/drivers/iio/magnetometer/hid-sensor-magn-3d.c
@@ -163,21 +163,23 @@ static int magn_3d_read_raw(struct iio_dev *indio_dev,
int report_id = -1;
u32 address;
int ret_type;
+ s32 min;
*val = 0;
*val2 = 0;
switch (mask) {
case 0:
hid_sensor_power_state(&magn_state->magn_flux_attributes, true);
- report_id =
- magn_state->magn[chan->address].report_id;
+ report_id = magn_state->magn[chan->address].report_id;
+ min = magn_state->magn[chan->address].logical_minimum;
address = magn_3d_addresses[chan->address];
if (report_id >= 0)
*val = sensor_hub_input_attr_get_raw_value(
magn_state->magn_flux_attributes.hsdev,
HID_USAGE_SENSOR_COMPASS_3D, address,
report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ min < 0);
else {
*val = 0;
hid_sensor_power_state(
diff --git a/drivers/iio/orientation/hid-sensor-incl-3d.c b/drivers/iio/orientation/hid-sensor-incl-3d.c
index fd1b3696ee42..16c744bef021 100644
--- a/drivers/iio/orientation/hid-sensor-incl-3d.c
+++ b/drivers/iio/orientation/hid-sensor-incl-3d.c
@@ -111,21 +111,23 @@ static int incl_3d_read_raw(struct iio_dev *indio_dev,
int report_id = -1;
u32 address;
int ret_type;
+ s32 min;
*val = 0;
*val2 = 0;
switch (mask) {
case IIO_CHAN_INFO_RAW:
hid_sensor_power_state(&incl_state->common_attributes, true);
- report_id =
- incl_state->incl[chan->scan_index].report_id;
+ report_id = incl_state->incl[chan->scan_index].report_id;
+ min = incl_state->incl[chan->scan_index].logical_minimum;
address = incl_3d_addresses[chan->scan_index];
if (report_id >= 0)
*val = sensor_hub_input_attr_get_raw_value(
incl_state->common_attributes.hsdev,
HID_USAGE_SENSOR_INCLINOMETER_3D, address,
report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ min < 0);
else {
hid_sensor_power_state(&incl_state->common_attributes,
false);
diff --git a/drivers/iio/pressure/hid-sensor-press.c b/drivers/iio/pressure/hid-sensor-press.c
index 6848d8c80eff..1c49ef78f888 100644
--- a/drivers/iio/pressure/hid-sensor-press.c
+++ b/drivers/iio/pressure/hid-sensor-press.c
@@ -77,6 +77,7 @@ static int press_read_raw(struct iio_dev *indio_dev,
int report_id = -1;
u32 address;
int ret_type;
+ s32 min;
*val = 0;
*val2 = 0;
@@ -85,8 +86,8 @@ static int press_read_raw(struct iio_dev *indio_dev,
switch (chan->scan_index) {
case CHANNEL_SCAN_INDEX_PRESSURE:
report_id = press_state->press_attr.report_id;
- address =
- HID_USAGE_SENSOR_ATMOSPHERIC_PRESSURE;
+ min = press_state->press_attr.logical_minimum;
+ address = HID_USAGE_SENSOR_ATMOSPHERIC_PRESSURE;
break;
default:
report_id = -1;
@@ -99,7 +100,8 @@ static int press_read_raw(struct iio_dev *indio_dev,
press_state->common_attributes.hsdev,
HID_USAGE_SENSOR_PRESSURE, address,
report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ min < 0);
hid_sensor_power_state(&press_state->common_attributes,
false);
} else {
diff --git a/drivers/iio/temperature/hid-sensor-temperature.c b/drivers/iio/temperature/hid-sensor-temperature.c
index c01efeca4002..6ed5cd5742f1 100644
--- a/drivers/iio/temperature/hid-sensor-temperature.c
+++ b/drivers/iio/temperature/hid-sensor-temperature.c
@@ -76,7 +76,8 @@ static int temperature_read_raw(struct iio_dev *indio_dev,
HID_USAGE_SENSOR_TEMPERATURE,
HID_USAGE_SENSOR_DATA_ENVIRONMENTAL_TEMPERATURE,
temp_st->temperature_attr.report_id,
- SENSOR_HUB_SYNC);
+ SENSOR_HUB_SYNC,
+ temp_st->temperature_attr.logical_minimum < 0);
hid_sensor_power_state(
&temp_st->common_attributes,
false);
diff --git a/drivers/rtc/rtc-hid-sensor-time.c b/drivers/rtc/rtc-hid-sensor-time.c
index 2751dba850c6..3e1abb455472 100644
--- a/drivers/rtc/rtc-hid-sensor-time.c
+++ b/drivers/rtc/rtc-hid-sensor-time.c
@@ -213,7 +213,7 @@ static int hid_rtc_read_time(struct device *dev, struct rtc_time *tm)
/* get a report with all values through requesting one value */
sensor_hub_input_attr_get_raw_value(time_state->common_attributes.hsdev,
HID_USAGE_SENSOR_TIME, hid_time_addresses[0],
- time_state->info[0].report_id, SENSOR_HUB_SYNC);
+ time_state->info[0].report_id, SENSOR_HUB_SYNC, false);
/* wait for all values (event) */
ret = wait_for_completion_killable_timeout(
&time_state->comp_last_time, HZ*6);
diff --git a/include/linux/hid-sensor-hub.h b/include/linux/hid-sensor-hub.h
index fc7aae64dcde..000de6da3b1b 100644
--- a/include/linux/hid-sensor-hub.h
+++ b/include/linux/hid-sensor-hub.h
@@ -177,6 +177,7 @@ int sensor_hub_input_get_attribute_info(struct hid_sensor_hub_device *hsdev,
* @attr_usage_id: Attribute usage id as per spec
* @report_id: Report id to look for
* @flag: Synchronous or asynchronous read
+* @is_signed: If true then fields < 32 bits will be sign-extended
*
* Issues a synchronous or asynchronous read request for an input attribute.
* Returns data upto 32 bits.
@@ -190,7 +191,8 @@ enum sensor_hub_read_flags {
int sensor_hub_input_attr_get_raw_value(struct hid_sensor_hub_device *hsdev,
u32 usage_id,
u32 attr_usage_id, u32 report_id,
- enum sensor_hub_read_flags flag
+ enum sensor_hub_read_flags flag,
+ bool is_signed
);
/**
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: Pascal PAILLET-LME @ 2018-12-05 15:36 UTC (permalink / raw)
To: Lee Jones
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <20181205093604.GZ26661@dell>
pascal paillet (p.paillet@st.com) Le Mans / France
Microcontrollers and Digital ICs Group | Application Development
TEL: +33.(0)2.44.02.74.69 | TINA: 166 7469
Le 12/05/2018 10:36 AM, Lee Jones a écrit :
> On Tue, 04 Dec 2018, Pascal PAILLET-LME wrote:
>> Le 12/03/2018 08:11 AM, Lee Jones a écrit :
>>> On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
>>>
>>>> The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from
>>>> STMicroelectronics.
>>>> The STPMIC1 regulators supply power to an application processor as well as
>>>> to external system peripherals such as DDR, Flash memories and system
>>>> devices. It also features onkey button input and an hardware watchdog.
>>>> The STPMIC1 is controlled via I2C.
>>>>
>>>> Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and
>>>> irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd
>>>> as parent.
>>>>
>>>> STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
>>>>
>>>> Pascal Paillet (7):
>>>> changes in v7:
>>>> * rebase on regul/for-next
>>>>
>>>> dt-bindings: mfd: document stpmic1
>>>> mfd: stpmic1: add stpmic1 driver
>>>> dt-bindings: input: document stpmic1 pmic onkey
>>>> input: stpmic1: add stpmic1 onkey driver
>>>> dt-bindings: watchdog: document stpmic1 pmic watchdog
>>>> watchdog: stpmic1: add stpmic1 watchdog driver
>>>> regulator: stpmic1: fix regulator_lock usage
>>>>
>>>> .../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 +++
>>>> .../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++++++
>>>> .../bindings/watchdog/st,stpmic1-wdt.txt | 11 ++
>>>> drivers/input/misc/Kconfig | 11 ++
>>>> drivers/input/misc/Makefile | 2 +
>>>> drivers/input/misc/stpmic1_onkey.c | 198 +++++++++++++++++++
>>>> drivers/mfd/Kconfig | 16 ++
>>>> drivers/mfd/Makefile | 1 +
>>>> drivers/mfd/stpmic1.c | 213 +++++++++++++++++++++
>>>> drivers/regulator/stpmic1_regulator.c | 2 +-
>>> Is it just Mark you're waiting on now?
>> It is ok now, Mark has applied the patch.
>> Evrey thing has been acked now. What is the nex step ?
> Mark has applied patch 7?
>
> Why don't I see that? Should you have removed it from this set?
Hi Lee, I have received an email from Mark telliing that the regulator
patch is applied on
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
I can see it on the branch regul/for-next.
thank you,
pascal
>
^ permalink raw reply
* Re: [git pull] Input updates for v4.20-rc5
From: pr-tracker-bot @ 2018-12-05 18:20 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <20181204033746.GA235290@dtor-ws>
The pull request you sent on Mon, 3 Dec 2018 19:37:46 -0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/adac0753c25217a2365b132c87cb2540b51fa89b
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.wiki.kernel.org/userdoc/prtracker
^ permalink raw reply
* Re: [PATCH 5/9] dt-bindings: input: touchscreen: goodix: Document vcc-supply property
From: Jagan Teki @ 2018-12-05 19:56 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Rob Herring, Dmitry Torokhov, linux-input,
devicetree, linux-arm-kernel, linux-kernel, Lee Jones,
linux-sunxi
In-Reply-To: <CAGb2v67ocaKL05yt68F+juBeAq8BRQ49mB4uoHWijGRy8duamw@mail.gmail.com>
On Mon, Dec 3, 2018 at 4:11 PM Chen-Yu Tsai <wens@csie.org> wrote:
>
> On Mon, Dec 3, 2018 at 6:16 PM Jagan Teki <jagan@amarulasolutions.com> wrote:
> >
> > vcc-supply property is need for some Goodix CTP controller like GT5663
> > where 3.3V external pull-up regulator connected via controller VCC pin.
>
> "External pull-up regulator" sounds fishy. Chips have power supply
> pins, either combined, or separate rails for analog, digital, and I/O.
> For Goodix chips these are AVDD28, AVDD22, DVDD12, amd VDDIO. The name
> and description you provide match none of these.
We have vcc pin in the connector to supply vcc-ctp, but indeed it is
AVDD28 supply as per the reference schematic design[1] Page 23. Host
interface has AVDD pin which is connected to ADVDD28 on goodix chip,
so I can name this as avdd28-supply. is that OK?
[1] https://www.crystalfontz.com/controllers/GOODIX/GT5663/459/
^ permalink raw reply
* Re: [PATCH v3 7/8] HID: logitech: Enable high-resolution scrolling on Logitech mice
From: Harry Cutts @ 2018-12-05 21:52 UTC (permalink / raw)
To: Peter Hutterer
Cc: linux-input, Dmitry Torokhov, jikos, torvalds,
Nestor Lopez Casado, linux-kernel, benjamin.tissoires
In-Reply-To: <20181205004228.10714-8-peter.hutterer@who-t.net>
Hi Peter,
On Tue, 4 Dec 2018 at 16:43, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> Changes to v2:
> - m560 now has REL_HWHEEL_HI_RES (untested, I don't have the device)
I just tested with my M560, and it now reports REL_HWHEEL_HI_RES correctly.
Verified-by: Harry Cutts <hcutts@chromium.org>
Thanks,
Harry Cutts
Chrome OS Touch/Input team
^ permalink raw reply
* Re: [PATCH v3 0/8] HID: MS and Logitech high-resolution scroll wheel support
From: Harry Cutts @ 2018-12-05 21:56 UTC (permalink / raw)
To: Peter Hutterer
Cc: linux-input, Dmitry Torokhov, jikos, torvalds,
Nestor Lopez Casado, linux-kernel, benjamin.tissoires
In-Reply-To: <20181205004228.10714-1-peter.hutterer@who-t.net>
On Tue, 4 Dec 2018 at 16:42, Peter Hutterer <peter.hutterer@who-t.net> wrote:
>
> A full explanation of why and what is in the v1, v2 patch thread here:
> https://lkml.org/lkml/2018/11/22/625
>
> v3 adds a better commit messages, m560 REL_HWHEEL_HI_RES support and a patch
> moved in the ordering. This is a full patch sequence because Benjamin's
> magic scripts struggle with singular updates ;)
I've retested with the same Logitech mice as before, except for the MX
Anywhere 2S, which is currently not available to me. So, for
reference, that's the MX Master 2S, Performance MX, M560, Anywhere MX,
and the M325 (to check low-resolution scrolling).
Verified-by: Harry Cutts <hcutts@chromium.org>
Harry Cutts
Chrome OS Touch/Input team
^ permalink raw reply
* [PATCH RFC 0/2] input: driver for RPi's official 7" touchscreen
From: Nicolas Saenz Julienne @ 2018-12-05 22:09 UTC (permalink / raw)
To: linux-input
Cc: linux-rpi-kernel, stefan.wahren, eric, agraf,
Nicolas Saenz Julienne, Dmitry Torokhov, Rob Herring,
Eugen Hristev, Hans de Goede, Jonathan Cameron, Masanari Iida,
Zhu Yi, Corentin Labbe, devicetree, linux-kernel
This small series adds support for Raspberry pi's 7" touchscreen. Which
alongside with the backlight driver are the last devices needed to have
a functional touchscreen upstream.
With this setup the board's VC4 firmware takes care of communicating
with the touch chip and provides data though a shared memory area
provided by the driver. The driver takes care of polling the firmware
whenever at around 60Hz since there is no interrupt line available.
The 1.0 revision of the touchscreen is based on the ft5426 chip.
Technically, with some changes in edt-ft54x4.c we should be able to
access the data directly through I2C. Yet this bus is meant to be owned
by RPi's firmware and might access it anytime. For example, to
configure RPi's camera device. As sharing the bus master interface is
not possible a series of alternatives have been tested unsuccessfully
[1]. It seems that we'll be unable to access the chip directly in a
"clean" way which leaves us with this firmware based solution.
The driver was rewritten based on the one available on the downstream
Raspberry Pi kernel tree: https://github.com/raspberrypi/linux/.
This series is based on v4.20-rc5 and was tested on a RPi 3 B+.
[1] https://lists.infradead.org/pipermail/linux-rpi-kernel/2018-December/008444.html
===
Nicolas Saenz Julienne (2):
input: add official Raspberry Pi's 7" touchscreen driver
Input: raspberrypi-ts - add devicetree binding documentation
.../touchscreen/raspberrypi,firmware-ts.txt | 25 ++
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/raspberrypi-ts.c | 252 ++++++++++++++++++
4 files changed, 290 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
create mode 100644 drivers/input/touchscreen/raspberrypi-ts.c
--
2.19.2
^ permalink raw reply
* [PATCH RFC 1/2] input: add official Raspberry Pi's 7" touchscreen driver
From: Nicolas Saenz Julienne @ 2018-12-05 22:09 UTC (permalink / raw)
To: Henrik Rydberg
Cc: linux-rpi-kernel, stefan.wahren, eric, agraf,
Nicolas Saenz Julienne, Dmitry Torokhov, Corentin Labbe,
Rob Herring, Hans de Goede, Masanari Iida, Zhu Yi, Eugen Hristev,
Jonathan Cameron, Hans-Christian Noren Egtvedt, Heiko Schocher,
linux-kernel, linux-input
In-Reply-To: <20181205220902.27682-1-nsaenzjulienne@suse.de>
Adds support to Raspberry Pi's 7" touchscreen device. Instead of using
a conventional bus all information is copied into a memory mapped area
by RPi's VC4 firmware.
Based on the driver found in RPi's downstream kernel repository.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
drivers/input/touchscreen/Kconfig | 12 +
drivers/input/touchscreen/Makefile | 1 +
drivers/input/touchscreen/raspberrypi-ts.c | 252 +++++++++++++++++++++
3 files changed, 265 insertions(+)
create mode 100644 drivers/input/touchscreen/raspberrypi-ts.c
diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
index 2a80675cfd94..8d0fcb3dc8a8 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -696,6 +696,18 @@ config TOUCHSCREEN_EDT_FT5X06
To compile this driver as a module, choose M here: the
module will be called edt-ft5x06.
+config TOUCHSCREEN_RASPBERRYPI_TS
+ tristate "Raspberry Pi's firmware base touch screen support"
+ depends on OF
+ help
+ Say Y here if you have the official Raspberry Pi 7' touchscren
+ connected on your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called raspberrypi-ts.
+
config TOUCHSCREEN_MIGOR
tristate "Renesas MIGO-R touchscreen"
depends on (SH_MIGOR || COMPILE_TEST) && I2C
diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
index 5911a4190cd2..3eccb1925e89 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -109,3 +109,4 @@ obj-$(CONFIG_TOUCHSCREEN_ZET6223) += zet6223.o
obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
obj-$(CONFIG_TOUCHSCREEN_COLIBRI_VF50) += colibri-vf50-ts.o
obj-$(CONFIG_TOUCHSCREEN_ROHM_BU21023) += rohm_bu21023.o
+obj-$(CONFIG_TOUCHSCREEN_RASPBERRYPI_TS) += raspberrypi-ts.o
diff --git a/drivers/input/touchscreen/raspberrypi-ts.c b/drivers/input/touchscreen/raspberrypi-ts.c
new file mode 100644
index 000000000000..9d29411a5674
--- /dev/null
+++ b/drivers/input/touchscreen/raspberrypi-ts.c
@@ -0,0 +1,252 @@
+/*
+ * Raspberry Pi 3 firmware based touchscreen driver
+ *
+ * Copyright (C) 2015, 2017 Raspberry Pi
+ * Copyright (C) 2018 Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <linux/io.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/bitops.h>
+#include <linux/dma-mapping.h>
+#include <linux/platform_device.h>
+#include <linux/input.h>
+#include <linux/input/mt.h>
+#include <linux/input/touchscreen.h>
+#include <soc/bcm2835/raspberrypi-firmware.h>
+
+#define RPI_TS_DEFAULT_WIDTH 800
+#define RPI_TS_DEFAULT_HEIGHT 480
+
+#define RPI_TS_MAX_SUPPORTED_POINTS 10
+
+#define RPI_TS_FTS_TOUCH_DOWN 0
+#define RPI_TS_FTS_TOUCH_CONTACT 2
+
+struct rpi_ts {
+ struct input_dev *input;
+ struct touchscreen_properties prop;
+
+ void __iomem *ts_base;
+ dma_addr_t bus_addr;
+
+ struct delayed_work work;
+ int known_ids;
+};
+
+struct rpi_ts_regs {
+ uint8_t device_mode;
+ uint8_t gesture_id;
+ uint8_t num_points;
+ struct rpi_ts_touch {
+ uint8_t xh;
+ uint8_t xl;
+ uint8_t yh;
+ uint8_t yl;
+ uint8_t pressure; /* Not supported */
+ uint8_t area; /* Not supported */
+ } point[RPI_TS_MAX_SUPPORTED_POINTS];
+};
+
+/*
+ * This process polls the memory based register copy of the touch screen chip
+ * registers using the number of points register to know whether the copy has
+ * been updated (we write 99 to the memory copy, the GPU will write between 0 -
+ * 10 points)
+ */
+static void rpi_ts_work(struct work_struct *work)
+{
+ struct rpi_ts *ts = container_of(work, struct rpi_ts, work.work);
+ struct input_dev *input = ts->input;
+ struct rpi_ts_regs regs;
+ int modified_ids = 0;
+ int released_ids;
+ int event_type;
+ int touchid;
+ int x, y;
+ int i;
+
+ memcpy_fromio(®s, ts->ts_base, sizeof(struct rpi_ts_regs));
+ iowrite8(99, ts->ts_base + offsetof(struct rpi_ts_regs, num_points));
+
+ if (regs.num_points == 99 ||
+ (regs.num_points == 0 && ts->known_ids == 0))
+ goto out;
+
+ for (i = 0; i < regs.num_points; i++) {
+ x = (((int)regs.point[i].xh & 0xf) << 8) + regs.point[i].xl;
+ y = (((int)regs.point[i].yh & 0xf) << 8) + regs.point[i].yl;
+ touchid = (regs.point[i].yh >> 4) & 0xf;
+ event_type = (regs.point[i].xh >> 6) & 0x03;
+
+ modified_ids |= BIT(touchid);
+
+ if (event_type == RPI_TS_FTS_TOUCH_DOWN ||
+ event_type == RPI_TS_FTS_TOUCH_CONTACT) {
+ input_mt_slot(input, touchid);
+ input_mt_report_slot_state(input, MT_TOOL_FINGER, 1);
+ touchscreen_report_pos(input, &ts->prop, x, y, true);
+ }
+ }
+
+ released_ids = ts->known_ids & ~modified_ids;
+ for (i = 0; released_ids && i < RPI_TS_MAX_SUPPORTED_POINTS; i++) {
+ if (released_ids & BIT(i)) {
+ input_mt_slot(input, i);
+ input_mt_report_slot_state(input, MT_TOOL_FINGER, 0);
+ modified_ids &= ~(BIT(i));
+ }
+ }
+ ts->known_ids = modified_ids;
+
+ input_mt_report_pointer_emulation(ts->input, true);
+ input_sync(ts->input);
+
+out:
+ schedule_delayed_work(&ts->work, msecs_to_jiffies(17)); /* 60 fps */
+}
+
+static int rpi_ts_open(struct input_dev *dev)
+{
+ struct rpi_ts *ts = input_get_drvdata(dev);
+
+ schedule_delayed_work(&ts->work, 0);
+
+ return 0;
+}
+
+static void rpi_ts_close(struct input_dev *dev)
+{
+ struct rpi_ts *ts = input_get_drvdata(dev);
+
+ cancel_delayed_work_sync(&ts->work);
+}
+
+static int rpi_ts_probe(struct platform_device *pdev)
+{
+ struct device *dev = &pdev->dev;
+ struct device_node *np = dev->of_node;
+ struct device_node *fw_node;
+ struct input_dev *input;
+ struct rpi_firmware *fw;
+ struct rpi_ts *ts;
+ u32 touchbuf;
+ int err = 0;
+
+ fw_node = of_get_parent(np);
+ if (!fw_node) {
+ dev_err(dev, "Missing firmware node\n");
+ return -ENOENT;
+ }
+
+ fw = rpi_firmware_get(fw_node);
+ if (!fw)
+ return -EPROBE_DEFER;
+
+ ts = devm_kzalloc(dev, sizeof(struct rpi_ts), GFP_KERNEL);
+ if (!ts) {
+ dev_err(dev, "Failed to allocate memory\n");
+ return -ENOMEM;
+ }
+
+ input = input_allocate_device();
+ if (!input) {
+ dev_err(dev, "Failed to allocate input device\n");
+ return -ENOMEM;
+ }
+ ts->input = input;
+
+ ts->ts_base = dma_zalloc_coherent(dev, PAGE_SIZE, &ts->bus_addr,
+ GFP_KERNEL);
+ if (!ts->ts_base) {
+ dev_err(dev, "failed to dma_alloc_coherent\n");
+ err = -ENOMEM;
+ goto undegister_input_device;
+ }
+
+ touchbuf = (u32)ts->bus_addr;
+ err = rpi_firmware_property(fw, RPI_FIRMWARE_FRAMEBUFFER_SET_TOUCHBUF,
+ &touchbuf, sizeof(touchbuf));
+
+ if (err || touchbuf != 0) {
+ dev_warn(dev, "Failed to set touchbuf, trying to get err:%x\n",
+ err);
+ goto clean_dma_buf;
+ }
+
+ INIT_DELAYED_WORK(&ts->work, rpi_ts_work);
+ platform_set_drvdata(pdev, ts);
+
+ input->name = "raspberrypi-ts";
+ input->id.bustype = BUS_HOST;
+ input->open = rpi_ts_open;
+ input->close = rpi_ts_close;
+ input->dev.parent = &pdev->dev;
+
+ __set_bit(EV_KEY, input->evbit);
+ __set_bit(EV_SYN, input->evbit);
+ __set_bit(EV_ABS, input->evbit);
+
+ input_set_abs_params(input, ABS_MT_POSITION_X, 0,
+ RPI_TS_DEFAULT_WIDTH, 0, 0);
+ input_set_abs_params(input, ABS_MT_POSITION_Y, 0,
+ RPI_TS_DEFAULT_HEIGHT, 0, 0);
+ touchscreen_parse_properties(input, true, &ts->prop);
+
+ input_mt_init_slots(input, RPI_TS_MAX_SUPPORTED_POINTS,
+ INPUT_MT_DIRECT);
+
+ input_set_drvdata(input, ts);
+
+ err = input_register_device(input);
+ if (err) {
+ dev_err(dev, "could not register input device, %d\n",
+ err);
+ goto clean_dma_buf;
+ }
+ return 0;
+
+clean_dma_buf:
+ dma_free_coherent(dev, PAGE_SIZE, ts->ts_base, ts->bus_addr);
+undegister_input_device:
+ input_unregister_device(ts->input);
+
+ return err;
+}
+
+static int rpi_ts_remove(struct platform_device *pdev)
+{
+ struct rpi_ts *ts = (struct rpi_ts *)platform_get_drvdata(pdev);
+
+ input_unregister_device(ts->input);
+ dma_free_coherent(&pdev->dev, PAGE_SIZE, ts->ts_base, ts->bus_addr);
+ return 0;
+}
+
+static const struct of_device_id rpi_ts_match[] = {
+ { .compatible = "raspberrypi,firmware-ts", },
+ {},
+};
+MODULE_DEVICE_TABLE(of, rpi_ts_match);
+
+static struct platform_driver rpi_ts_driver = {
+ .driver = {
+ .name = "raspberrypi-ts",
+ .owner = THIS_MODULE,
+ .of_match_table = rpi_ts_match,
+ },
+ .probe = rpi_ts_probe,
+ .remove = rpi_ts_remove,
+};
+
+module_platform_driver(rpi_ts_driver);
+
+MODULE_AUTHOR("Gordon Hollingworth");
+MODULE_AUTHOR("Nicolas Saenz Julienne <nsaenzjulienne@suse.de>");
+MODULE_DESCRIPTION("Raspberry Pi 3 firmware based touchscreen driver");
+MODULE_LICENSE("GPL");
--
2.19.2
^ permalink raw reply related
* [PATCH RFC 2/2] Input: raspberrypi-ts - add devicetree binding documentation
From: Nicolas Saenz Julienne @ 2018-12-05 22:09 UTC (permalink / raw)
To: linux-kernel
Cc: linux-rpi-kernel, stefan.wahren, eric, agraf,
Nicolas Saenz Julienne, Dmitry Torokhov, Rob Herring,
Mark Rutland, linux-input, devicetree
In-Reply-To: <20181205220902.27682-1-nsaenzjulienne@suse.de>
Adds device tree documentation for Raspberry Pi's official 7"
touchscreen. The firmware mailbox interface allows the ARM core to
control the device.
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
---
.../touchscreen/raspberrypi,firmware-ts.txt | 25 +++++++++++++++++++
1 file changed, 25 insertions(+)
create mode 100644 Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
diff --git a/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt b/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
new file mode 100644
index 000000000000..d28189476279
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/touchscreen/raspberrypi,firmware-ts.txt
@@ -0,0 +1,25 @@
+Raspberry Pi 3 firmware based 7" touchscreen
+=====================================
+
+Required properties:
+ - compatible: "raspberrypi,firmware-ts"
+
+Optional properties:
+ - touchscreen-size-x: See touchscreen.txt
+ - touchscreen-size-y: See touchscreen.txt
+ - touchscreen-inverted-x: See touchscreen.txt
+ - touchscreen-inverted-y: See touchscreen.txt
+ - touchscreen-swapped-x-y: See touchscreen.txt
+
+Example:
+
+firmware: firmware-rpi {
+ compatible = "raspberrypi,bcm2835-firmware", "simple-bus";
+ mboxes = <&mailbox>;
+
+ ts: touchscreen {
+ compatible = "raspberrypi,firmware-ts";
+ touchscreen-size-x = <800>;
+ touchscreen-size-y = <480>;
+ };
+};
--
2.19.2
^ permalink raw reply related
* [PATCH] Input: restore EV_ABS ABS_RESERVED
From: Peter Hutterer @ 2018-12-05 23:03 UTC (permalink / raw)
To: Benjamin Tissoires, linux-input; +Cc: Dmitry Torokhov, linux-kernel
ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
include/uapi/linux/input-event-codes.h | 9 +++++++++
1 file changed, 9 insertions(+)
diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
index 3eb5a4c3d60a..ae366b87426a 100644
--- a/include/uapi/linux/input-event-codes.h
+++ b/include/uapi/linux/input-event-codes.h
@@ -752,6 +752,15 @@
#define ABS_MISC 0x28
+/*
+ * 0x2e is reserved and should not be used in input drivers.
+ * It was used by HID as ABS_MISC+6 and userspace needs to detect if
+ * the next ABS_* event is correct or is just ABS_MISC + n.
+ * We define here ABS_RESERVED so userspace can rely on it and detect
+ * the situation described above.
+ */
+#define ABS_RESERVED 0x2e
+
#define ABS_MT_SLOT 0x2f /* MT slot being modified */
#define ABS_MT_TOUCH_MAJOR 0x30 /* Major axis of touching ellipse */
#define ABS_MT_TOUCH_MINOR 0x31 /* Minor axis (omit if circular) */
--
2.19.2
^ permalink raw reply related
* [PATCH v2 1/4] dt-bindings: input: touchscreen: goodix: Document AVDD28-supply property
From: Jagan Teki @ 2018-12-05 23:52 UTC (permalink / raw)
To: Dmitry Torokhov, Chen-Yu Tsai, linux-input, linux-kernel,
Michael Trimarchi, linux-amarula
Cc: Jagan Teki
Most of the Goodix CTP controllers are supply with AVDD28 pin.
which need to supply for controllers like GT5663 on some boards
to trigger the power.
So, document the supply property so-that the required board
that used on GT5663 can enable it via device tree.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- Rename vcc-supply with AVDD28-supply
Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index f7e95c52f3c7..c4622c983e08 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -23,6 +23,7 @@ Optional properties:
- touchscreen-inverted-y : Y axis is inverted (boolean)
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
(swapping is done after inverting the axis)
+ - AVDD28-supply : Analog power supply regulator on AVDD28 pin
Example:
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v2 2/4] Input: goodix - Add ADVV28-supply regulator support
From: Jagan Teki @ 2018-12-05 23:52 UTC (permalink / raw)
To: Dmitry Torokhov, Chen-Yu Tsai, linux-input, linux-kernel,
Michael Trimarchi, linux-amarula
Cc: Jagan Teki
In-Reply-To: <20181205235220.3461-1-jagan@amarulasolutions.com>
Goodix CTP controllers have AVDD28 pin connected to voltage
regulator which may not be turned on by default, like for GT5663.
Add support for such ctp used boards by adding voltage regulator
handling code to goodix ctp driver.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- disable regulator in remove
- fix to setup regulator in probe code
drivers/input/touchscreen/goodix.c | 33 +++++++++++++++++++++++++-----
1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index f2d9c2c41885..7371f6946098 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -27,6 +27,7 @@
#include <linux/delay.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
+#include <linux/regulator/consumer.h>
#include <linux/slab.h>
#include <linux/acpi.h>
#include <linux/of.h>
@@ -47,6 +48,7 @@ struct goodix_ts_data {
struct touchscreen_properties prop;
unsigned int max_touch_num;
unsigned int int_trigger_type;
+ struct regulator *avdd28;
struct gpio_desc *gpiod_int;
struct gpio_desc *gpiod_rst;
u16 id;
@@ -786,25 +788,41 @@ static int goodix_ts_probe(struct i2c_client *client,
if (error)
return error;
+ ts->avdd28 = devm_regulator_get(&client->dev, "AVDD28");
+ if (IS_ERR(ts->avdd28)) {
+ error = PTR_ERR(ts->avdd28);
+ if (error != -EPROBE_DEFER)
+ dev_err(&client->dev,
+ "Failed to get AVDD28 regulator: %d\n", error);
+ return error;
+ }
+
+ /* power the controller */
+ error = regulator_enable(ts->avdd28);
+ if (error) {
+ dev_err(&client->dev, "Controller fail to enable AVDD28\n");
+ return error;
+ }
+
if (ts->gpiod_int && ts->gpiod_rst) {
/* reset the controller */
error = goodix_reset(ts);
if (error) {
dev_err(&client->dev, "Controller reset failed.\n");
- return error;
+ goto error;
}
}
error = goodix_i2c_test(client);
if (error) {
dev_err(&client->dev, "I2C communication failure: %d\n", error);
- return error;
+ goto error;
}
error = goodix_read_version(ts);
if (error) {
dev_err(&client->dev, "Read version failed.\n");
- return error;
+ goto error;
}
ts->chip = goodix_get_chip_data(ts->id);
@@ -823,23 +841,28 @@ static int goodix_ts_probe(struct i2c_client *client,
dev_err(&client->dev,
"Failed to invoke firmware loader: %d\n",
error);
- return error;
+ goto error;
}
return 0;
} else {
error = goodix_configure_dev(ts);
if (error)
- return error;
+ goto error;
}
return 0;
+
+error:
+ regulator_disable(ts->avdd28);
+ return error;
}
static int goodix_ts_remove(struct i2c_client *client)
{
struct goodix_ts_data *ts = i2c_get_clientdata(client);
+ regulator_disable(ts->avdd28);
if (ts->gpiod_int && ts->gpiod_rst)
wait_for_completion(&ts->firmware_loading_complete);
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v2 3/4] dt-bindings: input: touchscreen: goodix: Add GT5663 compatible
From: Jagan Teki @ 2018-12-05 23:52 UTC (permalink / raw)
To: Dmitry Torokhov, Chen-Yu Tsai, linux-input, linux-kernel,
Michael Trimarchi, linux-amarula
Cc: Jagan Teki
In-Reply-To: <20181205235220.3461-1-jagan@amarulasolutions.com>
GT5663 is capacitive touch controller with customized smart
wakeup gestures, it support chipdata which is similar to
existing GT1151 and require AVDD28 supply for some boards.
Document the compatible for the same.
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- drop example node
Documentation/devicetree/bindings/input/touchscreen/goodix.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
index c4622c983e08..59c89276e6bb 100644
--- a/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
+++ b/Documentation/devicetree/bindings/input/touchscreen/goodix.txt
@@ -3,6 +3,7 @@ Device tree bindings for Goodix GT9xx series touchscreen controller
Required properties:
- compatible : Should be "goodix,gt1151"
+ or "goodix,gt5663"
or "goodix,gt911"
or "goodix,gt9110"
or "goodix,gt912"
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* [PATCH v2 4/4] Input: goodix - Add GT5663 CTP support
From: Jagan Teki @ 2018-12-05 23:52 UTC (permalink / raw)
To: Dmitry Torokhov, Chen-Yu Tsai, linux-input, linux-kernel,
Michael Trimarchi, linux-amarula
Cc: Jagan Teki
In-Reply-To: <20181205235220.3461-1-jagan@amarulasolutions.com>
GT5663 is capacitive touch controller with customized smart
wakeup gestures.
Add support for it by adding compatible and supported chip data.
The chip data on GT5663 is similar to GT1151, like
- config data register has 0x8050 address
- config data register max len is 240
- config data checksum has 16-bit
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
---
Changes for v2:
- add chipdata
drivers/input/touchscreen/goodix.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/input/touchscreen/goodix.c b/drivers/input/touchscreen/goodix.c
index 7371f6946098..735ab8e246b6 100644
--- a/drivers/input/touchscreen/goodix.c
+++ b/drivers/input/touchscreen/goodix.c
@@ -218,6 +218,7 @@ static const struct goodix_chip_data *goodix_get_chip_data(u16 id)
{
switch (id) {
case 1151:
+ case 5663:
return >1x_chip_data;
case 911:
@@ -965,6 +966,7 @@ MODULE_DEVICE_TABLE(acpi, goodix_acpi_match);
#ifdef CONFIG_OF
static const struct of_device_id goodix_of_match[] = {
{ .compatible = "goodix,gt1151" },
+ { .compatible = "goodix,gt5663" },
{ .compatible = "goodix,gt911" },
{ .compatible = "goodix,gt9110" },
{ .compatible = "goodix,gt912" },
--
2.18.0.321.gffc6fa0e3
^ permalink raw reply related
* Re: [PATCH 5/9] dt-bindings: input: touchscreen: goodix: Document vcc-supply property
From: Chen-Yu Tsai @ 2018-12-06 3:01 UTC (permalink / raw)
To: Jagan Teki
Cc: Maxime Ripard, Rob Herring, Dmitry Torokhov,
linux-input-u79uwXL29TY76Z2rM5mHXA, devicetree, linux-arm-kernel,
linux-kernel, Lee Jones, linux-sunxi
In-Reply-To: <CAMty3ZAd9eZRkBM2Pitp_B+kVLsGjufL6ALMCJ=f7iUL=7SfsQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, Dec 6, 2018 at 3:56 AM Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
>
> On Mon, Dec 3, 2018 at 4:11 PM Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org> wrote:
> >
> > On Mon, Dec 3, 2018 at 6:16 PM Jagan Teki <jagan-dyjBcgdgk7Pe9wHmmfpqLFaTQe2KTcn/@public.gmane.org> wrote:
> > >
> > > vcc-supply property is need for some Goodix CTP controller like GT5663
> > > where 3.3V external pull-up regulator connected via controller VCC pin.
> >
> > "External pull-up regulator" sounds fishy. Chips have power supply
> > pins, either combined, or separate rails for analog, digital, and I/O.
> > For Goodix chips these are AVDD28, AVDD22, DVDD12, amd VDDIO. The name
> > and description you provide match none of these.
>
> We have vcc pin in the connector to supply vcc-ctp, but indeed it is
> AVDD28 supply as per the reference schematic design[1] Page 23. Host
> interface has AVDD pin which is connected to ADVDD28 on goodix chip,
> so I can name this as avdd28-supply. is that OK?
Yeah. That's better. It's always best to be precise with hardware
descriptions. If you simplify it, the reason should be given in
detail. And it should be a good one.
ChenYu
^ permalink raw reply
* Re: [PATCH] Input: restore EV_ABS ABS_RESERVED
From: Martin Kepplinger @ 2018-12-06 8:36 UTC (permalink / raw)
To: Peter Hutterer, Benjamin Tissoires, linux-input
Cc: Dmitry Torokhov, linux-kernel
In-Reply-To: <20181205230336.GA23462@jelly>
[-- Attachment #1: Type: text/plain, Size: 316 bytes --]
On 06.12.18 00:03, Peter Hutterer wrote:
> ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
> ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.
>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 3616 bytes --]
^ permalink raw reply
* Re: [PATCH] Input: restore EV_ABS ABS_RESERVED
From: Benjamin Tissoires @ 2018-12-06 9:24 UTC (permalink / raw)
To: Martin Kepplinger
Cc: Peter Hutterer, linux-input, Dmitry Torokhov, linux-kernel
In-Reply-To: <82d624a7-349b-c706-cda9-81a22f2473e0@ginzinger.com>
On Thu, Dec 6, 2018 at 9:36 AM Martin Kepplinger
<martin.kepplinger@ginzinger.com> wrote:
>
> On 06.12.18 00:03, Peter Hutterer wrote:
> > ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
> > ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.
> >
> > Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
>
> Reviewed-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Dmitry, I do not think this one will conflict with the high res wheel
patches, so I think it should be safe to take it through your tree.
If you think it'll be an issue, I can also take it through the HID one.
Cheers,
Benjamin
^ permalink raw reply
* Re: [PATCH v2 2/4] Input: goodix - Add ADVV28-supply regulator support
From: Jagan Teki @ 2018-12-06 11:02 UTC (permalink / raw)
To: Dmitry Torokhov, Chen-Yu Tsai, linux-input, linux-kernel,
Michael Trimarchi, linux-amarula
In-Reply-To: <20181205235220.3461-2-jagan@amarulasolutions.com>
On Thu, Dec 6, 2018 at 5:22 AM Jagan Teki <jagan@amarulasolutions.com> wrote:
>
> Goodix CTP controllers have AVDD28 pin connected to voltage
> regulator which may not be turned on by default, like for GT5663.
>
> Add support for such ctp used boards by adding voltage regulator
> handling code to goodix ctp driver.
s/ADVV28/AVDD28 on commit head, let me know if you need another
version to update that or is it OK to you to change while applying.
sorry.
^ permalink raw reply
* Re: [PATCH v3 3/4] iio: adc: add STMPE ADC devicetree bindings
From: Philippe Schenker @ 2018-12-06 15:49 UTC (permalink / raw)
To: Jonathan Cameron
Cc: marcel.ziswiler, stefan, Max Krummenacher, devicetree, linux-iio,
Hartmut Knaack, Alexandre Torgue, linux-input, linux-kernel,
Rob Herring, Dmitry Torokhov, Lee Jones, Maxime Coquelin,
Mark Rutland, Peter Meerwald-Stadler, linux-stm32,
linux-arm-kernel, Lars-Peter Clausen
In-Reply-To: <20181125100413.73bc729f@archlinux>
On Sun, 2018-11-25 at 10:04 +0000, Jonathan Cameron wrote:
> On Fri, 23 Nov 2018 15:24:10 +0100
> Philippe Schenker <dev@pschenker.ch> wrote:
>
> > From: Stefan Agner <stefan@agner.ch>
> >
> > This adds the devicetree bindings for the STMPE ADC.
> >
> > Signed-off-by: Stefan Agner <stefan@agner.ch>
> > Signed-off-by: Max Krummenacher <max.krummenacher@toradex.com>
> > Signed-off-by: Philippe Schenker <philippe.schenker@toradex.com>
> Clearly this will need review from input and mfd.
>
> I've suggested inline that you split the realignment out to a
> separate patch for reviewability reasons.
Thank you again Jonathan for your feedback, and of course also all the others!
I will split it much more so everything will be much more readable in v4. You
suggested again, to use the naming 'adc {'. I know that this is standard naming,
but unfortunately, this naming is given by drivers/mfd/stmpe.c (line 1311).
What do you suggest to do? break the naming scheme in mfd, or just use
'stmpe_adc {' ?
>
> > ---
> >
> > Changes in v3:
> > - Reformatted documentation for touchscreen to use tabs and have a better
> > overview of the settings.
> > - Added note which adc-settings will take precedence.
> > - changed typo in sample-time setting from 144 clocks to 124 clocks, as
> > stated
> > in the datasheet.
> >
> > Changes in v2:
> > - Moved the bindings for ADC to the overlying mfd.
> > - Reformatted for better readability
> >
> > .../devicetree/bindings/iio/adc/stmpe-adc.txt | 21 +++++++
> > .../bindings/input/touchscreen/stmpe.txt | 60 ++++++++++++-------
> > .../devicetree/bindings/mfd/stmpe.txt | 28 ++++++---
> > 3 files changed, 80 insertions(+), 29 deletions(-)
> > create mode 100644 Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> >
> > diff --git a/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > new file mode 100644
> > index 000000000000..480e66422625
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/iio/adc/stmpe-adc.txt
> > @@ -0,0 +1,21 @@
> > +STMPE ADC driver
> > +----------------
> > +
> > +Required properties:
> > + - compatible: "st,stmpe-adc"
> > +
> > +Optional properties:
> > +Note that the ADC is shared with the STMPE touchscreen. ADC related
> > settings
> > +have to be done in the mfd.
> > +- st,norequest-mask: bitmask specifying which ADC channels should _not_ be
> > + requestable due to different usage (e.g. touch)
> > +
> > +Node name must be stmpe_adc and should be child node of stmpe node to
> > +which it belongs.
> > +
> > +Example:
> > +
> > + stmpe_adc {
>
> Can we use adc { here to match standard naming?
>
> > + compatible = "st,stmpe-adc";
> > + st,norequest-mask = <0x0F>; /* dont use ADC CH3-0 */
> > + };
> > diff --git a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > index 127baa31a77a..414586513a02 100644
> > --- a/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > +++ b/Documentation/devicetree/bindings/input/touchscreen/stmpe.txt
> > @@ -5,36 +5,52 @@ Required properties:
> > - compatible: "st,stmpe-ts"
> >
> > Optional properties:
> > -- st,sample-time: ADC converstion time in number of clock. (0 -> 36
> > clocks, 1 ->
> > - 44 clocks, 2 -> 56 clocks, 3 -> 64 clocks, 4 -> 80 clocks, 5 -> 96
> > clocks, 6
> > - -> 144 clocks), recommended is 4.
> > -- st,mod-12b: ADC Bit mode (0 -> 10bit ADC, 1 -> 12bit ADC)
> > -- st,ref-sel: ADC reference source (0 -> internal reference, 1 -> external
> > - reference)
> > -- st,adc-freq: ADC Clock speed (0 -> 1.625 MHz, 1 -> 3.25 MHz, 2 || 3 ->
> > 6.5 MHz)
> > -- st,ave-ctrl: Sample average control (0 -> 1 sample, 1 -> 2 samples, 2 ->
> > 4
> > - samples, 3 -> 8 samples)
> > -- st,touch-det-delay: Touch detect interrupt delay (0 -> 10 us, 1 -> 50 us,
> > 2 ->
> > - 100 us, 3 -> 500 us, 4-> 1 ms, 5 -> 5 ms, 6 -> 10 ms, 7 -> 50 ms)
> > recommended
> > - is 3
> > -- st,settling: Panel driver settling time (0 -> 10 us, 1 -> 100 us, 2 ->
> > 500 us, 3
> > - -> 1 ms, 4 -> 5 ms, 5 -> 10 ms, 6 for 50 ms, 7 -> 100 ms) recommended is
> > 2
> > -- st,fraction-z: Length of the fractional part in z (fraction-z ([0..7]) =
> > Count of
> > - the fractional part) recommended is 7
> > -- st,i-drive: current limit value of the touchscreen drivers (0 -> 20 mA
> > typical 35
> > - mA max, 1 -> 50 mA typical 80 mA max)
> > +- st,ave-ctrl : Sample average control
> > + 0 -> 1 sample
> > + 1 -> 2 samples
> > + 2 -> 4 samples
> > + 3 -> 8 samples
> > +- st,touch-det-delay : Touch detect interrupt delay (recommended is
> > 3)
> > + 0 -> 10 us 5 -> 5 ms
> > + 1 -> 50 us 6 -> 10 ms
> > + 2 -> 100 us 7 -> 50 ms
> > + 3 -> 500 us
> > + 4-> 1 ms
> > +- st,settling : Panel driver settling time (recommended is 2)
> > + 0 -> 10 us 5 -> 10 ms
> > + 1 -> 100 us 6 for 50 ms
> > + 2 -> 500 us 7 -> 100 ms
> > + 3 -> 1 ms
> > + 4 -> 5 ms
> > +- st,fraction-z : Length of the fractional part in z
> > (recommended is 7)
> > + (fraction-z ([0..7]) = Count of the fractional part)
> > +- st,i-drive : current limit value of the touchscreen drivers
> > + 0 -> 20 mA (typical 35mA max)
> > + 1 -> 50 mA (typical 80 mA max)
> > +
> > +Optional properties common with MFD (deprecated):
> > + - st,sample-time : ADC conversion time in number of clock.
> > + 0 -> 36 clocks 4 -> 80 clocks
> > (recommended)
> > + 1 -> 44 clocks 5 -> 96 clocks
> > + 2 -> 56 clocks 6 -> 124 clocks
> > + 3 -> 64 clocks
> > + - st,mod-12b : ADC Bit mode
> > + 0 -> 10bit ADC 1 -> 12bit ADC
> > + - st,ref-sel : ADC reference source
> > + 0 -> internal 1 -> external
> > + - st,adc-freq : ADC Clock speed
> > + 0 -> 1.625 MHz 2 || 3 -> 6.5 MHz
> > + 1 -> 3.25 MHz
> >
> > Node name must be stmpe_touchscreen and should be child node of stmpe node
> > to
> > which it belongs.
> >
> > +Note that common ADC settings of stmpe_touchscreen will take precedence.
> > +
> > Example:
> >
> > stmpe_touchscreen {
> > compatible = "st,stmpe-ts";
> > - st,sample-time = <4>;
> > - st,mod-12b = <1>;
> > - st,ref-sel = <0>;
> > - st,adc-freq = <1>;
> > st,ave-ctrl = <1>;
> > st,touch-det-delay = <2>;
> > st,settling = <2>;
> > diff --git a/Documentation/devicetree/bindings/mfd/stmpe.txt
> > b/Documentation/devicetree/bindings/mfd/stmpe.txt
> > index c797c05cd3c2..d4408a417193 100644
> > --- a/Documentation/devicetree/bindings/mfd/stmpe.txt
> > +++ b/Documentation/devicetree/bindings/mfd/stmpe.txt
> > @@ -4,15 +4,29 @@ STMPE is an MFD device which may expose the following
> > inbuilt devices: gpio,
> > keypad, touchscreen, adc, pwm, rotator.
> >
> > Required properties:
> > - - compatible :
> > "st,stmpe[610|801|811|1600|1601|2401|2403]"
> > - - reg : I2C/SPI address of the device
> > + - compatible :
> > "st,stmpe[610|801|811|1600|1601|2401|2403]"
> > + - reg : I2C/SPI address of the device
>
> Nothing wrong with correcting alignment, but it shouldn't be in the same patch
> as a fundamental change lie this. Just adds noise.
>
> If that means you first have to introduce the new block missaligned, then
> fix up the alignment in a follow up patch, then do that as we can then
> effectively ignore the realignment as obviously correct and focus on
> the real changes.
>
> >
> > Optional properties:
> > - - interrupts : The interrupt outputs from the controller
> > - - interrupt-controller : Marks the device node as an interrupt
> > controller
> > - - wakeup-source : Marks the input device as wakable
> > - - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64, 128,
> > 256, 512 and 1024
> > - - irq-gpio : If present, which GPIO to use for event
> > IRQ
> > + - interrupts : The interrupt outputs from the
> > controller
> > + - interrupt-controller : Marks the device node as an interrupt
> > controller
> > + - wakeup-source : Marks the input device as wakable
> > + - st,autosleep-timeout : Valid entries (ms); 4, 16, 32, 64,
> > 128, 256, 512 and 1024
> > + - irq-gpio : If present, which GPIO to use for
> > event IRQ
> > +
> > +Optional properties for devices with touch and ADC (STMPE811|STMPE610):
> > + - st,sample-time : ADC conversion time in number of clock.
> > + 0 -> 36 clocks 4 -> 80
> > clocks (recommended)
> > + 1 -> 44 clocks 5 -> 96
> > clocks
> > + 2 -> 56 clocks 6 -> 124
> > clocks
> > + 3 -> 64 clocks
> > + - st,mod-12b : ADC Bit mode
> > + 0 -> 10bit ADC 1 -> 12bit
> > ADC
> > + - st,ref-sel : ADC reference source
> > + 0 -> internal 1 ->
> > external
> > + - st,adc-freq : ADC Clock speed
> > + 0 -> 1.625 MHz 2 || 3 ->
> > 6.5 MHz
> > + 1 -> 3.25 MHz
> >
> > Example:
> >
^ permalink raw reply
* Re: [PATCH] Input: restore EV_ABS ABS_RESERVED
From: Peter Hutterer @ 2018-12-06 22:46 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Martin Kepplinger, linux-input, Dmitry Torokhov, linux-kernel
In-Reply-To: <CAN+gG=FVvUFcYYcBnaOaj-YRQCgu4-FYFuJGccHhK+u31EjuvQ@mail.gmail.com>
On Thu, Dec 06, 2018 at 10:24:11AM +0100, Benjamin Tissoires wrote:
> On Thu, Dec 6, 2018 at 9:36 AM Martin Kepplinger
> <martin.kepplinger@ginzinger.com> wrote:
> >
> > On 06.12.18 00:03, Peter Hutterer wrote:
> > > ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
> > > ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.
> > >
> > > Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> >
> > Reviewed-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
>
> Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>
> Dmitry, I do not think this one will conflict with the high res wheel
> patches, so I think it should be safe to take it through your tree.
> If you think it'll be an issue, I can also take it through the HID one.
fwiw, patch was made on top of v4.20-rc5, so it shouldn't conflict.
Cheers,
Peter
^ permalink raw reply
* Re: [PATCH] Input: restore EV_ABS ABS_RESERVED
From: Dmitry Torokhov @ 2018-12-06 22:56 UTC (permalink / raw)
To: Peter Hutterer
Cc: Benjamin Tissoires, Martin Kepplinger, linux-input, linux-kernel
In-Reply-To: <20181206224605.GA27899@jelly>
On Fri, Dec 07, 2018 at 08:46:05AM +1000, Peter Hutterer wrote:
> On Thu, Dec 06, 2018 at 10:24:11AM +0100, Benjamin Tissoires wrote:
> > On Thu, Dec 6, 2018 at 9:36 AM Martin Kepplinger
> > <martin.kepplinger@ginzinger.com> wrote:
> > >
> > > On 06.12.18 00:03, Peter Hutterer wrote:
> > > > ABS_RESERVED was added in d9ca1c990a7 and accidentally removed as part of
> > > > ffe0e7cf290f5c9 when the high-resolution scrolling code was removed.
> > > >
> > > > Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> > >
> > > Reviewed-by: Martin Kepplinger <martin.kepplinger@ginzinger.com>
> >
> > Acked-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
> >
> > Dmitry, I do not think this one will conflict with the high res wheel
> > patches, so I think it should be safe to take it through your tree.
> > If you think it'll be an issue, I can also take it through the HID one.
>
> fwiw, patch was made on top of v4.20-rc5, so it shouldn't conflict.
My tree is behind that ;) so I would actually prefer if Benjamin/Jiri
would take it through their tree with my:
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v3 1/8] Input: add `REL_WHEEL_HI_RES` and `REL_HWHEEL_HI_RES`
From: Dmitry Torokhov @ 2018-12-06 22:56 UTC (permalink / raw)
To: Peter Hutterer
Cc: linux-input, Jiri Kosina, Harry Cutts, torvalds,
Nestor Lopez Casado, linux-kernel, Benjamin Tissoires
In-Reply-To: <20181205004228.10714-2-peter.hutterer@who-t.net>
On Wed, Dec 05, 2018 at 10:42:21AM +1000, Peter Hutterer wrote:
> This event code represents scroll reports from high-resolution wheels and
> is modelled after the approach Windows uses. The value 120 is one detent
> (wheel click) of movement. Mice with higher-resolution scrolling can send
> fractions of 120 which must be accumulated in userspace. Userspace can either
> wait for a full 120 to accumulate or scroll by fractions of one logical scroll
> movement as the events come in. 120 was picked as magic number because it has
> a high number of integer fractions that can be used by high-resolution wheels.
>
> For more information see
> https://docs.microsoft.com/en-us/previous-versions/windows/hardware/design/dn613912(v=vs.85)
>
> These new axes obsolete REL_WHEEL and REL_HWHEEL. The legacy axes are emulated
> by the kernel but the most accurate (and most granular) data is available
> through the new axes.
>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> ---
> No changes since v1
>
> Documentation/input/event-codes.rst | 21 ++++++++++++++++++++-
> include/uapi/linux/input-event-codes.h | 2 ++
> 2 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst
> index a8c0873beb95..b24b5343f5eb 100644
> --- a/Documentation/input/event-codes.rst
> +++ b/Documentation/input/event-codes.rst
> @@ -190,7 +190,26 @@ A few EV_REL codes have special meanings:
> * REL_WHEEL, REL_HWHEEL:
>
> - These codes are used for vertical and horizontal scroll wheels,
> - respectively.
> + respectively. The value is the number of detents moved on the wheel, the
> + physical size of which varies by device. For high-resolution wheels
> + this may be an approximation based on the high-resolution scroll events,
> + see REL_WHEEL_HI_RES. These event codes are legacy codes and
> + REL_WHEEL_HI_RES and REL_HWHEEL_HI_RES should be preferred where
> + available.
> +
> +* REL_WHEEL_HI_RES, REL_HWHEEL_HI_RES:
> +
> + - High-resolution scroll wheel data. The accumulated value 120 represents
> + movement by one detent. For devices that do not provide high-resolution
> + scrolling, the value is always a multiple of 120. For devices with
> + high-resolution scrolling, the value may be a fraction of 120.
> +
> + If a vertical scroll wheel supports high-resolution scrolling, this code
> + will be emitted in addition to REL_WHEEL or REL_HWHEEL. The REL_WHEEL
> + and REL_HWHEEL may be an approximation based on the high-resolution
> + scroll events. There is no guarantee that the high-resolution data
> + is a multiple of 120 at the time of an emulated REL_WHEEL or REL_HWHEEL
> + event.
>
> EV_ABS
> ------
> diff --git a/include/uapi/linux/input-event-codes.h b/include/uapi/linux/input-event-codes.h
> index 3eb5a4c3d60a..265ef2028660 100644
> --- a/include/uapi/linux/input-event-codes.h
> +++ b/include/uapi/linux/input-event-codes.h
> @@ -716,6 +716,8 @@
> * the situation described above.
> */
> #define REL_RESERVED 0x0a
> +#define REL_WHEEL_HI_RES 0x0b
> +#define REL_HWHEEL_HI_RES 0x0c
> #define REL_MAX 0x0f
> #define REL_CNT (REL_MAX+1)
>
> --
> 2.19.2
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: input: support Microsoft wireless radio control hotkey
From: Chris Chiu @ 2018-12-07 4:07 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Jiri Kosina, rydberg, linux-input, Linux Kernel,
Linux Upstreaming Team
In-Reply-To: <CAB4CAwfOBuAutaQdObyfrOg5Yo2M9NJGww1Ffc7o2YrAYDObEA@mail.gmail.com>
On Wed, Dec 5, 2018 at 8:56 AM Chris Chiu <chiu@endlessm.com> wrote:
>
> On Fri, Nov 30, 2018 at 7:18 PM Benjamin Tissoires
> <benjamin.tissoires@redhat.com> wrote:
> >
> > On Fri, Nov 30, 2018 at 7:46 AM Chris Chiu <chiu@endlessm.com> wrote:
> > >
> > > The ASUS laptops start to support the airplane mode radio management
> > > to replace the original machanism of airplane mode toggle hotkey.
> > > On the ASUS P5440FF, it presents as a HID device connecting via
> > > I2C, name i2c-AMPD0001. When pressing hotkey, the Embedded Controller
> > > send hid report up via I2C and switch the airplane mode indicator
> > > LED based on the status.
> > >
> > > However, it's not working because it fails to be identified as a
> > > hidinput device. It fails in hidinput_connect() due to the macro
> > > IS_INPUT_APPLICATION doesn't identify HID_GD_WIRELESS_RADIO_CTLS
> > > as a legit application code.
> > >
> > > It's easy to add the HID I2C vendor and product id to the quirk
> > > list and apply HID_QUIRK_HIDINPUT_FORCE to make it work. But it
> > > can be more generic to support such kind of application on PC.
> >
> > Sounds good, but while you are at it, can you please:
> > - fix the kbuild warning
> > - rewrite the whole line to use macros,
> > - make the macro prettier by inserting new lines were required
> > - and define the missing macro:
> > 0x000d0006 -> HID_DG_WHITEBOARD
> >
> > Maybe we should keep the ranges definitions with raw values and put a
> > comment on the side with the names.
> >
> > Cheers,
> > Benjamin
> >
>
> Hi Bejamin,
> Thanks for your comment, I've submitted other patches which may
> fulfill your suggestion.
> https://lore.kernel.org/patchwork/patch/1020373/
> https://lore.kernel.org/patchwork/patch/1020374/
>
> Please help me review and correct me if there's any modification
> required. Thanks & Regards.
>
> Chris
>
Gentle ping. Any comment for the new patch? Thanks and Regards.
Chris
> > >
> > > Signed-off-by: Chris Chiu <chiu@endlessm.com>
> > > ---
> > > include/linux/hid.h | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/include/linux/hid.h b/include/linux/hid.h
> > > index d44a78362942..f4805f605fed 100644
> > > --- a/include/linux/hid.h
> > > +++ b/include/linux/hid.h
> > > @@ -836,7 +836,7 @@ static inline bool hid_is_using_ll_driver(struct hid_device *hdev,
> > >
> > > /* Applications from HID Usage Tables 4/8/99 Version 1.1 */
> > > /* We ignore a few input applications that are not widely used */
> > > -#define IS_INPUT_APPLICATION(a) (((a >= 0x00010000) && (a <= 0x00010008)) || (a == 0x00010080) || (a == 0x000c0001) || ((a >= 0x000d0002) && (a <= 0x000d0006)))
> > > +#define IS_INPUT_APPLICATION(a) (((a >= 0x00010000) && (a <= 0x00010008)) || (a == 0x00010080) || || (a == 0x0001000c) || (a == 0x000c0001) || ((a >= 0x000d0002) && (a <= 0x000d0006)))
> > >
> > > /* HID core API */
> > >
> > > --
> > > 2.11.0
> > >
^ permalink raw reply
* Re: [PATCH v7 0/7] Introduce STPMIC1 PMIC Driver
From: Lee Jones @ 2018-12-07 7:31 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lgirdwood@gmail.com, broonie@kernel.org,
wim@linux-watchdog.org, linux@roeck-us.net,
linux-input@vger.kernel.org, devicetree@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-watchdog@vger.kernel.org,
benjamin.gaignard@linaro.org, eballetbo@gmail.com,
axel.lin@ingics.com
In-Reply-To: <5C07F08B.2010701@st.com>
On Wed, 05 Dec 2018, Pascal PAILLET-LME wrote:
>
> pascal paillet (p.paillet@st.com) Le Mans / France
> Microcontrollers and Digital ICs Group | Application Development
> TEL: +33.(0)2.44.02.74.69 | TINA: 166 7469
>
> Le 12/05/2018 10:36 AM, Lee Jones a écrit :
> > On Tue, 04 Dec 2018, Pascal PAILLET-LME wrote:
> >> Le 12/03/2018 08:11 AM, Lee Jones a écrit :
> >>> On Fri, 30 Nov 2018, Pascal PAILLET-LME wrote:
> >>>
> >>>> The goal of this patch-set is to propose a driver for the STPMIC1 PMIC from
> >>>> STMicroelectronics.
> >>>> The STPMIC1 regulators supply power to an application processor as well as
> >>>> to external system peripherals such as DDR, Flash memories and system
> >>>> devices. It also features onkey button input and an hardware watchdog.
> >>>> The STPMIC1 is controlled via I2C.
> >>>>
> >>>> Main driver is drivers/mfd/stpmic1 that handle I2C regmap configuration and
> >>>> irqchip. stpmic1_regulator, stpmic1_onkey and stpmic1_wdt need stpmic1 mfd
> >>>> as parent.
> >>>>
> >>>> STPMIC1 MFD and regulator drivers maybe mandatory at boot time.
> >>>>
> >>>> Pascal Paillet (7):
> >>>> changes in v7:
> >>>> * rebase on regul/for-next
> >>>>
> >>>> dt-bindings: mfd: document stpmic1
> >>>> mfd: stpmic1: add stpmic1 driver
> >>>> dt-bindings: input: document stpmic1 pmic onkey
> >>>> input: stpmic1: add stpmic1 onkey driver
> >>>> dt-bindings: watchdog: document stpmic1 pmic watchdog
> >>>> watchdog: stpmic1: add stpmic1 watchdog driver
> >>>> regulator: stpmic1: fix regulator_lock usage
> >>>>
> >>>> .../devicetree/bindings/input/st,stpmic1-onkey.txt | 28 +++
> >>>> .../devicetree/bindings/mfd/st,stpmic1.txt | 61 ++++++
> >>>> .../bindings/watchdog/st,stpmic1-wdt.txt | 11 ++
> >>>> drivers/input/misc/Kconfig | 11 ++
> >>>> drivers/input/misc/Makefile | 2 +
> >>>> drivers/input/misc/stpmic1_onkey.c | 198 +++++++++++++++++++
> >>>> drivers/mfd/Kconfig | 16 ++
> >>>> drivers/mfd/Makefile | 1 +
> >>>> drivers/mfd/stpmic1.c | 213 +++++++++++++++++++++
> >>>> drivers/regulator/stpmic1_regulator.c | 2 +-
> >>> Is it just Mark you're waiting on now?
> >> It is ok now, Mark has applied the patch.
> >> Evrey thing has been acked now. What is the nex step ?
> > Mark has applied patch 7?
> >
> > Why don't I see that? Should you have removed it from this set?
> Hi Lee, I have received an email from Mark telliing that the regulator
> patch is applied on
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git
>
> I can see it on the branch regul/for-next.
Mark,
Does your patch tracker only reply to the author?
Any reason why I don't see it?
--
Lee Jones [李琼斯]
Linaro Services Technical Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ 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