* Re: [PATCH 1/2] input: synaptics - make image sensors report ABS_MT_TOUCH_MAJOR
From: Dmitry Torokhov @ 2015-01-07 7:49 UTC (permalink / raw)
To: Benjamin Tissoires
Cc: Gabriele Mazzotta, Peter Hutterer, Hans de Goede, Henrik Rydberg,
linux-input, linux-kernel@vger.kernel.org, Maxwell Anselm
In-Reply-To: <CAN+gG=FQY4V8K6k-mVrYRNSLoJDZW5bX1T=rD04MkEedQRdfUg@mail.gmail.com>
On Mon, Jan 05, 2015 at 05:04:55PM -0500, Benjamin Tissoires wrote:
> On Mon, Jan 5, 2015 at 5:00 PM, Gabriele Mazzotta
> <gabriele.mzt@gmail.com> wrote:
> > On Monday 05 January 2015 14:24:30 Benjamin Tissoires wrote:
> >> Hi Gabriele,
> >>
> >> [Adding Peter and Hans as this change will impact both
> >> xf86-input-synaptics and libinput]
> >>
> >> On Sat, Dec 27, 2014 at 6:31 AM, Gabriele Mazzotta
> >> <gabriele.mzt@gmail.com> wrote:
> >> > Despite claiming to be able to report ABS_TOOL_WIDTH, image sensors
> >> > were not doing it. Make them report widths and use ABS_MT_TOUCH_MAJOR
> >> > instead ABS_TOOL_WIDTH.
> >>
> >> It looks like the current xorg-synaptics code already handles
> >> ABS_MT_TOUCH_MAJOR as finger_width. So I think we should be good in
> >> replacing the ABS_TOOL_WIDTH event. However, I'd prefer having Peter
> >> confirm this because xorg-synaptics still relies a lot on the single
> >> touch emulation.
> >>
> >> >
> >> > Since the 'w' slot is used to report the finger count when two or more
> >> > fingers are on the touchpad, make sure that only meaningful values are
> >> > emitted, i.e. values greater than or equal to 4, and assign the correct
> >> > range to ABS_MT_TOUCH_MAJOR.
> >> >
> >> > Link: https://bugzilla.kernel.org/show_bug.cgi?id=77161
> >> > Signed-off-by: Gabriele Mazzotta <gabriele.mzt@gmail.com>
> >> > ---
> >> > drivers/input/mouse/synaptics.c | 11 +++++++++--
> >> > 1 file changed, 9 insertions(+), 2 deletions(-)
> >> >
> >> > diff --git a/drivers/input/mouse/synaptics.c b/drivers/input/mouse/synaptics.c
> >> > index f947292..ea0563e 100644
> >> > --- a/drivers/input/mouse/synaptics.c
> >> > +++ b/drivers/input/mouse/synaptics.c
> >> > @@ -814,6 +814,8 @@ static void synaptics_report_slot(struct input_dev *dev, int slot,
> >>
> >> Just FYI, this does not apply anymore on top of Dmitry's tree.
> >> synaptics_report_slot() has been removed, and you should now report
> >> the slot state in synaptics_report_mt_data().
> >>
> >> > input_report_abs(dev, ABS_MT_POSITION_X, hw->x);
> >> > input_report_abs(dev, ABS_MT_POSITION_Y, synaptics_invert_y(hw->y));
> >> > input_report_abs(dev, ABS_MT_PRESSURE, hw->z);
> >> > + if (hw->w >= 4)
> >>
> >> That I don't like. IMO, at this point, .w should only contain the
> >> finger width, unconditionally.
> >> Also, with 2/2, .w is computed accurately for the second finger, but
> >> not for the first.
> >>
> >> I tried to figure out a way to properly extract the actual width
> >> information from the sgm packet when the w is 0 or 1, and the only way
> >> I found was to do the fix in synaptics_image_sensor_process(). I would
> >> have preferred dealing with that in synaptics_parse_hw_state()
> >> directly, but I think the final code would be more and more ugly.
> >> Dealing with the true finger width in synaptics_image_sensor_process()
> >> is not a problem for cr48 sensors, because they will not have the
> >> ABS_MT_TOUCH_MAJOR event exported.
> >
> > Regarding the last part on cr48 sensors.
> > Currently these sensors are not reporting widths through ABS_TOOL_WIDTH
> > and I don't see what could go wrong if they start reporting
> > ABS_MT_TOUCH_MAJOR. If I understood correctly, they can report widths
> > only when one finger is on the touchpad. This means that they will
> > report widths through slot 0, but they won't through slot 1. Nothing
> > bad should happen.
>
> I am not entirely sure. The entire purpose of having widht for palm
> detection is to filter palm from true finger events. So if we only
> have the width info on the first slot, it would be useless IMO.
> Still I agree with "nothing bad should happen" :)
>From conceptual perspective if device is not capable of reporting
contact size for each contact then it should not be sending
ABS_MT_TOUCH_MAJOR, same as we do not send ABS_MT_PRESSURE if we can't
provide per-contact pressure. For such devices we revert to ST-events
ABS_PRESSURE and I guess we'll have to continue with ABS_TOOL_WIDTH for
contact sizes in Synaptics.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1] input: make use of the input_set_capability helper
From: Dmitry Torokhov @ 2015-01-07 7:57 UTC (permalink / raw)
To: Olliver Schinagl
Cc: Wolfram Sang, Paul Gortmaker, Jingoo Han, David S. Miller,
Sam Ravnborg, Olliver Schinagl, linux-input, linux-kernel
In-Reply-To: <1420615866-3528-1-git-send-email-oliver+list@schinagl.nl>
Hi Olliver,
On Wed, Jan 07, 2015 at 08:31:06AM +0100, Olliver Schinagl wrote:
> From: Olliver Schinagl <oliver@schinagl.nl>
>
> Almost all of the speaker drivers under input manipulate the ev bits
> directly, which is not needed, as there is a helper available.
>
> This patch makes use of the helper for the speaker drivers.
>
> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
> ---
> drivers/input/misc/cm109.c | 4 ++--
> drivers/input/misc/ixp4xx-beeper.c | 5 ++---
> drivers/input/misc/m68kspkr.c | 5 ++---
> drivers/input/misc/pcspkr.c | 5 ++---
> drivers/input/misc/pwm-beeper.c | 5 +----
> drivers/input/misc/sparcspkr.c | 6 ++----
> 6 files changed, 11 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
> index 9365535..8e41070 100644
> --- a/drivers/input/misc/cm109.c
> +++ b/drivers/input/misc/cm109.c
> @@ -767,10 +767,10 @@ static int cm109_usb_probe(struct usb_interface *intf,
> input_dev->keycodesize = sizeof(unsigned char);
> input_dev->keycodemax = ARRAY_SIZE(dev->keymap);
>
> - input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_SND);
> - input_dev->sndbit[0] = BIT_MASK(SND_BELL) | BIT_MASK(SND_TONE);
> + input_set_capability(input_dev, EV_SND, SND_BELL | SND_TONE);
No, input_set_capability() takes single event code, not bitmask. The
fact that it works for these 2 values of SND events is pure coincidence
(the old code wasn't much better though).
>
> /* register available key events */
> + input_dev->evbit[0] = BIT_MASK(EV_KEY);
Would prefer __set_bit(EV_KEY, input_dev->evbit); here instead.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 1/2] Input: adxl34x - add OF support
From: Dmitry Torokhov @ 2015-01-07 8:01 UTC (permalink / raw)
To: Walter Lozano
Cc: michael.hennerich, robh+dt, pawel.moll, mark.rutland,
ijc+devicetree, galak, devicetree, linux-input, linux-kernel
In-Reply-To: <1420599537-28740-1-git-send-email-walter@vanguardiasur.com.ar>
Hi Walter,
On Tue, Jan 06, 2015 at 11:58:56PM -0300, Walter Lozano wrote:
> This patch adds the missing support for OF to the adxl34x digital
> accelerometer. This is a basic version which supports the main
> optional parameters. This implementation copies the default values
> to the adxl34x_platform_data structure and overrides the values
> that are passed from the device tree.
>
> Signed-off-by: Walter Lozano <walter@vanguardiasur.com.ar>
> ---
> drivers/input/misc/adxl34x.c | 108 +++++++++++++++++++++++++++++++++++++++++-
> 1 file changed, 107 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/input/misc/adxl34x.c b/drivers/input/misc/adxl34x.c
> index 2b2d02f..b3e06a3 100644
> --- a/drivers/input/misc/adxl34x.c
> +++ b/drivers/input/misc/adxl34x.c
> @@ -16,6 +16,8 @@
> #include <linux/workqueue.h>
> #include <linux/input/adxl34x.h>
> #include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_device.h>
>
> #include "adxl34x.h"
>
> @@ -688,13 +690,113 @@ static void adxl34x_input_close(struct input_dev *input)
> mutex_unlock(&ac->mutex);
> }
>
> +void adxl34x_parse_dt(struct device *dev, struct adxl34x_platform_data *pdata){
> + if (!dev->of_node)
> + return;
> +
> + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
> +
> + memcpy(pdata, &adxl34x_default_init, sizeof(struct adxl34x_platform_data));
> +
> + of_property_read_u8(dev->of_node, "adi,tap-axis-control",
> + &pdata->tap_axis_control);
> +
> + of_property_read_u8(dev->of_node, "adi,tap-threshold",
> + &pdata->tap_threshold);
> +
> + of_property_read_u8(dev->of_node, "adi,tap-duration",
> + &pdata->tap_duration);
> +
> + of_property_read_u8(dev->of_node, "adi,tap-latency",
> + &pdata->tap_latency);
> +
> + of_property_read_u8(dev->of_node, "adi,tap-window",
> + &pdata->tap_window);
> +
> + of_property_read_u8(dev->of_node, "adi,act-axis-control",
> + &pdata->act_axis_control);
> +
> + of_property_read_u8(dev->of_node, "adi,activity-threshold",
> + &pdata->activity_threshold);
> +
> + of_property_read_u8(dev->of_node, "adi,inactivity-threshold",
> + &pdata->inactivity_threshold);
> +
> + of_property_read_u8(dev->of_node, "adi,inactivity-time",
> + &pdata->inactivity_time);
> +
> + of_property_read_u8(dev->of_node, "adi,free-fall-threshold",
> + &pdata->free_fall_threshold);
> +
> + of_property_read_u8(dev->of_node, "adi,free-fall-time",
> + &pdata->free_fall_time);
> +
> + of_property_read_u8(dev->of_node, "adi,data-rate",
> + &pdata->data_rate);
> +
> + of_property_read_u8(dev->of_node, "adi,data-range",
> + &pdata->data_range);
> +
> + of_property_read_u8(dev->of_node, "adi,low-power-mode",
> + &pdata->low_power_mode);
> +
> + of_property_read_u8(dev->of_node, "adi,power-mode",
> + &pdata->power_mode);
> +
> + of_property_read_u8(dev->of_node, "adi,fifo-mode",
> + &pdata->fifo_mode);
> +
> + of_property_read_u8(dev->of_node, "adi,watermark",
> + &pdata->watermark);
> +
> + of_property_read_u8(dev->of_node, "adi,use-int2",
> + &pdata->use_int2);
> +
> + of_property_read_u8(dev->of_node, "adi,orientation-enable",
> + &pdata->orientation_enable);
> +
> + of_property_read_u8(dev->of_node, "adi,deadzone-angle",
> + &pdata->deadzone_angle);
> +
> + of_property_read_u8(dev->of_node, "adi,divisor-length",
> + &pdata->divisor_length);
> +
> + of_property_read_u32(dev->of_node, "adi,ev-type",
> + &pdata->ev_type);
All these ev* properties are Linux-specific so should have linux prefix
and not adi.
> +
> + of_property_read_u32(dev->of_node, "adi,ev-code-x",
> + &pdata->ev_code_x);
> +
> + of_property_read_u32(dev->of_node, "adi,ev-code-y",
> + &pdata->ev_code_y);
> +
> + of_property_read_u32(dev->of_node, "adi,ev-code-z",
> + &pdata->ev_code_z);
> +
> + of_property_read_u32_array(dev->of_node, "adi,ev-code-tap",
> + pdata->ev_code_tap, 3);
> +
> + of_property_read_u32(dev->of_node, "adi,ev-code-ff",
> + &pdata->ev_code_ff);
> +
> + of_property_read_u32(dev->of_node, "adi,ev-code-act-inactivity",
> + &pdata->ev_code_act_inactivity);
> +
> + of_property_read_u32_array(dev->of_node, "adi,ev-codes-orient-2d",
> + pdata->ev_codes_orient_2d, 4);
> +
> + of_property_read_u32_array(dev->of_node, "adi,ev-codes-orient-3d",
> + pdata->ev_codes_orient_3d, 6);
> +
> +}
> +
> struct adxl34x *adxl34x_probe(struct device *dev, int irq,
> bool fifo_delay_default,
> const struct adxl34x_bus_ops *bops)
> {
> struct adxl34x *ac;
> struct input_dev *input_dev;
> - const struct adxl34x_platform_data *pdata;
> + struct adxl34x_platform_data *pdata;
> int err, range, i;
> unsigned char revid;
>
> @@ -714,6 +816,10 @@ struct adxl34x *adxl34x_probe(struct device *dev, int irq,
> ac->fifo_delay = fifo_delay_default;
>
> pdata = dev_get_platdata(dev);
> +
> + if (!pdata && dev->of_node)
> + adxl34x_parse_dt(dev, pdata);
> +
> if (!pdata) {
Umm, what's changing data pointer? Was this tested?
> dev_dbg(dev,
> "No platform data: Using default initialization\n");
> --
> 1.7.10.4
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v1] input: make use of the input_set_capability helper
From: Olliver Schinagl @ 2015-01-07 8:19 UTC (permalink / raw)
To: Dmitry Torokhov, Olliver Schinagl
Cc: Wolfram Sang, Paul Gortmaker, Jingoo Han, David S. Miller,
Sam Ravnborg, linux-input, linux-kernel
In-Reply-To: <20150107075703.GE5256@dtor-ws>
Hey Dmitry,
On 07-01-15 08:57, Dmitry Torokhov wrote:
> Hi Olliver,
>
> On Wed, Jan 07, 2015 at 08:31:06AM +0100, Olliver Schinagl wrote:
>> From: Olliver Schinagl <oliver@schinagl.nl>
>>
>> Almost all of the speaker drivers under input manipulate the ev bits
>> directly, which is not needed, as there is a helper available.
>>
>> This patch makes use of the helper for the speaker drivers.
>>
>> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
>> ---
>> drivers/input/misc/cm109.c | 4 ++--
>> drivers/input/misc/ixp4xx-beeper.c | 5 ++---
>> drivers/input/misc/m68kspkr.c | 5 ++---
>> drivers/input/misc/pcspkr.c | 5 ++---
>> drivers/input/misc/pwm-beeper.c | 5 +----
>> drivers/input/misc/sparcspkr.c | 6 ++----
>> 6 files changed, 11 insertions(+), 19 deletions(-)
>>
>> diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
>> index 9365535..8e41070 100644
>> --- a/drivers/input/misc/cm109.c
>> +++ b/drivers/input/misc/cm109.c
>> @@ -767,10 +767,10 @@ static int cm109_usb_probe(struct usb_interface *intf,
>> input_dev->keycodesize = sizeof(unsigned char);
>> input_dev->keycodemax = ARRAY_SIZE(dev->keymap);
>>
>> - input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_SND);
>> - input_dev->sndbit[0] = BIT_MASK(SND_BELL) | BIT_MASK(SND_TONE);
>> + input_set_capability(input_dev, EV_SND, SND_BELL | SND_TONE);
> No, input_set_capability() takes single event code, not bitmask. The
> fact that it works for these 2 values of SND events is pure coincidence
> (the old code wasn't much better though).
What do you suggest we should do then? Fix input_set_capability to take
bit masks? or multiline events?
I'm not sure why __set_bits() wouldn't work for bitmasks, could you
educate me?
>
>>
>> /* register available key events */
>> + input_dev->evbit[0] = BIT_MASK(EV_KEY);
> Would prefer __set_bit(EV_KEY, input_dev->evbit); here instead.
I only moved the EV_KEY bit from above to its appropiate place here. I
can change this one (and others) to use __set_bit() for now for v2?
Olliver
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH 1/1] Elantech touchpad detection fix for laptops
From: Srihari Vijayaraghavan @ 2015-01-07 8:23 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Mateusz Jończyk, Zakariya Dehlawi,
Guillaume Bouchard
In-Reply-To: <20150107074433.GC5256@dtor-ws>
[-- Attachment #1: Type: text/plain, Size: 1551 bytes --]
On 7 January 2015 at 18:44, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
> Hi Srihari,
Hello Dimitry,
Thanks for your feedback. Much appreciated.
> On Mon, Jan 05, 2015 at 07:45:39PM +1100, Srihari Vijayaraghavan wrote:
>> Hello Folks & Dmitry,
>>
>> Further to the previous patch, here is the current version (against
>> mainline) updated with the DMI info of another laptop model where this
>> fix had helped a user.
>>
>> Can you please review it & give some feedback? If it looks good as it
>> is, then on behalf of all affected users (including yours truly), may
>> I request for it to be merged upstream (and possibly stable too)?
>>
>> (If the patch gets spoiled by gmail, please ref to this bugzilla URL,
>> where this patch is there as a file attachment:
>> https://bugzilla.kernel.org/show_bug.cgi?id=81331)
>
> I am not terribly happy with having fiddling with keyboard from i8042
> core, but I guess that's what we have to do unless someone has better
> idea...
Agreed 100%. Regrettably, seeing how psmouse_do_detect() doesn't even
get invoked, this heavy handed approach had to be taken at i8042 core.
However, as you've pointed out, if there is any better idea, we're all
ears.
> I'll drop mention of Elantech from the option though as it may well be
> needed for other devices in the future.
A version of the patch (against mainline) incorporating your ideas
(i.e., without too much Elantech bashing) is attached to this email
for your review.
> Thanks!
Much appreciated. Thank you.
> --
> Dmitry
Srihari Vijayaraghavan
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: touchpad_detection_fix_for_laptops_v5_against_mainline.patch --]
[-- Type: text/x-patch; charset=US-ASCII; name="touchpad_detection_fix_for_laptops_v5_against_mainline.patch", Size: 4194 bytes --]
commit 567400ceed4febf53fb676dd67b1d801f901f12c
Author: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Date: Wed Jan 7 19:04:21 2015 +1100
As reported in kernel bugzilla 81331, on some laptops keyboard needs to be reset
for the detection of touchpad (e.g., some Gigabyte laptop models containing Elantech)
Based on the original patch by Mateusz Jończyk this version has been expanded to include
DMI based detection & application of the fix automatically. This has been confirmed to
fix problem by three users already on three different models of laptops.
Signed-off-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Tested-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Tested by: Zakariya Dehlawi <zdehlawi@gmail.com>
Tested-by: Guillaum Bouchard <guillaum.bouchard@gmail.com>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4df73da..603fa10 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1277,6 +1277,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
i8042.notimeout [HW] Ignore timeout condition signalled by controller
i8042.reset [HW] Reset the controller during init and cleanup
i8042.unlock [HW] Unlock (ignore) the keylock
+ i8042.kbdreset [HW] Reset keyboard to detect touchpad on some laptops
i810= [HW,DRM]
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index c66d1b5..5e5edee 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -745,6 +745,35 @@ static const struct dmi_system_id __initconst i8042_dmi_dritek_table[] = {
{ }
};
+/*
+ * Just as per kernel bugzilla #81331, some laptops need keyboard reset before probing
+ * for the tochpad to get it detected, initialised & finally work.
+ */
+static const struct dmi_system_id __initconst i8042_dmi_elantech_kbdreset_table[] = {
+ {
+ /* Gigabyte P35 v2 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P35V2"),
+ },
+ },
+ {
+ /* Aorus branded Gigabyte X3 Plus */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X3"),
+ },
+ },
+ {
+ /* Gigabyte P34 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P34"),
+ },
+ },
+ { }
+};
+
#endif /* CONFIG_X86 */
#ifdef CONFIG_PNP
@@ -1040,6 +1069,9 @@ static int __init i8042_platform_init(void)
if (dmi_check_system(i8042_dmi_dritek_table))
i8042_dritek = true;
+ if (dmi_check_system(i8042_dmi_elantech_kbdreset_table))
+ i8042_kbdreset = true;
+
/*
* A20 was already enabled during early kernel init. But some buggy
* BIOSes (in MSI Laptops) require A20 to be enabled using 8042 to
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 924e4bf..1a6ff74 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -67,6 +67,10 @@ static bool i8042_notimeout;
module_param_named(notimeout, i8042_notimeout, bool, 0);
MODULE_PARM_DESC(notimeout, "Ignore timeouts signalled by i8042");
+static bool i8042_kbdreset;
+module_param_named(kbdreset, i8042_kbdreset, bool, 0);
+MODULE_PARM_DESC(kbdreset, "Reset keyboard to detect touchpad on some laptops");
+
#ifdef CONFIG_X86
static bool i8042_dritek;
module_param_named(dritek, i8042_dritek, bool, 0);
@@ -790,6 +794,15 @@ static int __init i8042_check_aux(void)
return -1;
/*
+ * Reset keyboard to detect touchpad on some laptops
+ * (e.g., some Gigabyte laptop models containing Elantech touchpad)
+ */
+ if (i8042_kbdreset) {
+ pr_warn("Resetting keyboard to detect touchpad on some laptops\n");
+ i8042_kbd_write(NULL, (unsigned char) 0xff);
+ }
+
+/*
* Test AUX IRQ delivery to make sure BIOS did not grab the IRQ and
* used it for a PCI card or somethig else.
*/
^ permalink raw reply related
* Re: [PATCH v1] input: make use of the input_set_capability helper
From: Dmitry Torokhov @ 2015-01-07 8:26 UTC (permalink / raw)
To: Olliver Schinagl
Cc: Olliver Schinagl, Wolfram Sang, Paul Gortmaker, Jingoo Han,
David S. Miller, Sam Ravnborg, linux-input, linux-kernel
In-Reply-To: <54ACEC10.5000508@schinagl.nl>
On Wed, Jan 07, 2015 at 09:19:28AM +0100, Olliver Schinagl wrote:
> Hey Dmitry,
>
> On 07-01-15 08:57, Dmitry Torokhov wrote:
> >Hi Olliver,
> >
> >On Wed, Jan 07, 2015 at 08:31:06AM +0100, Olliver Schinagl wrote:
> >>From: Olliver Schinagl <oliver@schinagl.nl>
> >>
> >>Almost all of the speaker drivers under input manipulate the ev bits
> >>directly, which is not needed, as there is a helper available.
> >>
> >>This patch makes use of the helper for the speaker drivers.
> >>
> >>Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
> >>---
> >> drivers/input/misc/cm109.c | 4 ++--
> >> drivers/input/misc/ixp4xx-beeper.c | 5 ++---
> >> drivers/input/misc/m68kspkr.c | 5 ++---
> >> drivers/input/misc/pcspkr.c | 5 ++---
> >> drivers/input/misc/pwm-beeper.c | 5 +----
> >> drivers/input/misc/sparcspkr.c | 6 ++----
> >> 6 files changed, 11 insertions(+), 19 deletions(-)
> >>
> >>diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
> >>index 9365535..8e41070 100644
> >>--- a/drivers/input/misc/cm109.c
> >>+++ b/drivers/input/misc/cm109.c
> >>@@ -767,10 +767,10 @@ static int cm109_usb_probe(struct usb_interface *intf,
> >> input_dev->keycodesize = sizeof(unsigned char);
> >> input_dev->keycodemax = ARRAY_SIZE(dev->keymap);
> >>- input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_SND);
> >>- input_dev->sndbit[0] = BIT_MASK(SND_BELL) | BIT_MASK(SND_TONE);
> >>+ input_set_capability(input_dev, EV_SND, SND_BELL | SND_TONE);
> >No, input_set_capability() takes single event code, not bitmask. The
> >fact that it works for these 2 values of SND events is pure coincidence
> >(the old code wasn't much better though).
Ah, not, it does not work at all. Instead of setting bits 1 and 2 your
code sets bit 3 in dev->sndbit.
> What do you suggest we should do then? Fix input_set_capability to
> take bit masks? or multiline events?
> I'm not sure why __set_bits() wouldn't work for bitmasks, could you
> educate me?
Call it once per event:
input_set_capability(input_dev, EV_SND, SND_BELL);
input_set_capability(input_dev, EV_SND, SND_TONE);
> >
> >> /* register available key events */
> >>+ input_dev->evbit[0] = BIT_MASK(EV_KEY);
> >Would prefer __set_bit(EV_KEY, input_dev->evbit); here instead.
> I only moved the EV_KEY bit from above to its appropiate place here.
The original code was setting combination of bits; here we set single
one and __set_bit() is cleaner IMO.
> I can change this one (and others) to use __set_bit() for now for
> v2?
Yes, please.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] HID: hid-sensor-hub: Correct documentation
From: Jiri Kosina @ 2015-01-07 8:48 UTC (permalink / raw)
To: Srinivas Pandruvada; +Cc: jic23, linux-iio, linux-input
In-Reply-To: <1420592328-9942-1-git-send-email-srinivas.pandruvada@linux.intel.com>
Srinivas,
the way you sent the patches are really confusing.
Most importantly, you seem to have inter-mixed three patch series (with
4,8 and 9 patches respectively) into one thread, plus there are 4 patches
which aren't marked by series numbering. All this is mixed together into
one thread without any particular ordering.
This way it makes it really difficult to review (and possibly apply
afterwards).
Could you please resend as proper independent series, with correct
threading etc?
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 01/17] ARM: sunxi: Register cpufreq-dt for sun[45678]i
From: Chen-Yu Tsai @ 2015-01-07 9:07 UTC (permalink / raw)
To: Maxime Ripard
Cc: Dmitry Torokhov, Zhang Rui, Eduardo Valentin, Hans de Goede,
linux-input@vger.kernel.org, linux-arm-kernel, linux-pm,
Viresh Kumar
In-Reply-To: <20150106155532.GR7853@lukather>
Hi,
On Tue, Jan 6, 2015 at 11:55 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Tue, Jan 06, 2015 at 10:35:11AM +0800, Chen-Yu Tsai wrote:
>> On sun[45678]i, we have one cluster of identical cores sharing a
>> clock, which is ideal for using cpufreq-dt. Register a platform
>> device for cpufreq-dt.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>
> While I don't have anything against this patch, I seem to recall that
> it was not necessary anymore, or that there was some work in the
> direction of removing that kind of code, have you looked into that?
I believe you are referring to the work done by Viresh Kumar (CCed),
specifically the 2 series "[RFC V1 0/8] CPUFreq: create platform-dev
for DT based cpufreq drivers" and "[RFC] OPP: Redefine bindings to
overcome shortcomings". So far the new code has not appeared in
linux-next. If it does, I will happily use it.
ChenYu
^ permalink raw reply
* [PATCH v1 3/4] leds: Let the binding document example for leds-gpio follow the gpio bindings
From: Olliver Schinagl @ 2015-01-07 9:08 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Linus Walleij, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie
Cc: Olliver Schinagl, Robin Gong, Rafael J. Wysocki, Aaron Lu,
Mika Westerberg, Grant Likely, Wolfram Sang, Alexander Shiyan,
Jingoo Han, devicetree, linux-kernel, linux-gpio, linux-input,
linux-leds
In-Reply-To: <1420621722-7428-1-git-send-email-oliver+list@schinagl.nl>
From: Olliver Schinagl <oliver@schinagl.nl>
In the gpio bindings documents it is requested to use the marco's in
include/dt-bindings/gpio/gpio.h whenever possible. The gpios in the led
drivers don't seem to form an exception, so update the example in the
document bindings.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
---
Documentation/devicetree/bindings/leds/leds-gpio.txt | 12 +++++++-----
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index f77148f..d544cf1 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -26,16 +26,18 @@ LED sub-node properties:
Examples:
+#include <dt-bindings/gpio/gpio.h>
+
leds {
compatible = "gpio-leds";
hdd {
label = "IDE Activity";
- gpios = <&mcu_pio 0 1>; /* Active low */
+ gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
linux,default-trigger = "ide-disk";
};
fault {
- gpios = <&mcu_pio 1 0>;
+ gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
/* Keep LED on if BIOS detected hardware fault */
default-state = "keep";
};
@@ -44,11 +46,11 @@ leds {
run-control {
compatible = "gpio-leds";
red {
- gpios = <&mpc8572 6 0>;
+ gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>;
default-state = "off";
};
green {
- gpios = <&mpc8572 7 0>;
+ gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
};
@@ -57,7 +59,7 @@ leds {
compatible = "gpio-leds";
charger-led {
- gpios = <&gpio1 2 0>;
+ gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "max8903-charger-charging";
retain-state-suspended;
};
--
2.1.4
^ permalink raw reply related
* [PATCH v1 4/4] leds: no longer use unnamed gpios
From: Olliver Schinagl @ 2015-01-07 9:08 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Linus Walleij, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie
Cc: Olliver Schinagl, Robin Gong, Rafael J. Wysocki, Aaron Lu,
Mika Westerberg, Grant Likely, Wolfram Sang, Alexander Shiyan,
Jingoo Han, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-gpio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-leds-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1420621722-7428-1-git-send-email-oliver+list-dxLnbx3+1qmEVqv0pETR8A@public.gmane.org>
From: Olliver Schinagl <oliver-dxLnbx3+1qmEVqv0pETR8A@public.gmane.org>
The gpio document says we should not use unnamed bindings for gpios.
This patch uses the 'led-' prefix to the gpios and updates code and
documents. Because the devm_get_gpiod_from_child() falls back to using
old-style unnamed gpios, we can update the code first, and update
dts files as time allows.
Signed-off-by: Olliver Schinagl <oliver-dxLnbx3+1qmEVqv0pETR8A@public.gmane.org>
---
Documentation/devicetree/bindings/leds/leds-gpio.txt | 12 ++++++------
drivers/leds/leds-gpio.c | 2 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-gpio.txt b/Documentation/devicetree/bindings/leds/leds-gpio.txt
index d544cf1..2c138cc 100644
--- a/Documentation/devicetree/bindings/leds/leds-gpio.txt
+++ b/Documentation/devicetree/bindings/leds/leds-gpio.txt
@@ -7,7 +7,7 @@ Each LED is represented as a sub-node of the gpio-leds device. Each
node's name represents the name of the corresponding LED.
LED sub-node properties:
-- gpios : Should specify the LED's GPIO, see "gpios property" in
+- led-gpios : Should specify the LED's GPIO, see "gpios property" in
Documentation/devicetree/bindings/gpio/gpio.txt. Active low LEDs should be
indicated using flags in the GPIO specifier.
- label : (optional)
@@ -32,12 +32,12 @@ leds {
compatible = "gpio-leds";
hdd {
label = "IDE Activity";
- gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
+ led-gpios = <&mcu_pio 0 GPIO_ACTIVE_LOW>;
linux,default-trigger = "ide-disk";
};
fault {
- gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
+ led-gpios = <&mcu_pio 1 GPIO_ACTIVE_HIGH>;
/* Keep LED on if BIOS detected hardware fault */
default-state = "keep";
};
@@ -46,11 +46,11 @@ leds {
run-control {
compatible = "gpio-leds";
red {
- gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>;
+ led-gpios = <&mpc8572 6 GPIO_ACTIVE_HIHG>;
default-state = "off";
};
green {
- gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
+ led-gpios = <&mpc8572 7 GPIO_ACTIVE_HIGH>;
default-state = "on";
};
};
@@ -59,7 +59,7 @@ leds {
compatible = "gpio-leds";
charger-led {
- gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
+ led-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "max8903-charger-charging";
retain-state-suspended;
};
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 8e5af69..5b7bc84 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev)
struct gpio_led led = {};
const char *state = NULL;
- led.gpiod = devm_get_gpiod_from_child(dev, NULL, child);
+ led.gpiod = devm_get_gpiod_from_child(dev, "led", child);
if (IS_ERR(led.gpiod)) {
fwnode_handle_put(child);
goto err;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [PATCH v1 0/4] Let leds use named gpios
From: Olliver Schinagl @ 2015-01-07 9:08 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Linus Walleij, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie
Cc: Olliver Schinagl, Robin Gong, Rafael J. Wysocki, Aaron Lu,
Mika Westerberg, Grant Likely, Wolfram Sang, Alexander Shiyan,
Jingoo Han, devicetree, linux-kernel, linux-gpio, linux-input,
linux-leds, Olliver Schinagl
From: Olliver Schinagl <o.schinagl@ultimaker.com>
The gpio binding docs ask to use named-gpios wherever possible, however 40b73183 probably forgot that. This patch makes the new devm_get_gpiod_from_child use named gpios.
Olliver Schinagl (4):
gpio:gpiolib: use static const char const * for a suffixes array
gpio: add parameter to allow the use named gpios
leds: Let the binding document example for leds-gpio follow the gpio
bindings
leds: no longer use unnamed gpios
Documentation/devicetree/bindings/leds/leds-gpio.txt | 14 ++++++++------
drivers/gpio/devres.c | 16 +++++++++++++++-
drivers/gpio/gpiolib.c | 2 +-
drivers/input/keyboard/gpio_keys_polled.c | 2 +-
drivers/leds/leds-gpio.c | 2 +-
include/linux/gpio/consumer.h | 1 +
6 files changed, 27 insertions(+), 10 deletions(-)
--
2.1.4
^ permalink raw reply
* [PATCH v1 1/4] gpio:gpiolib: use static const char const * for a suffixes array
From: Olliver Schinagl @ 2015-01-07 9:08 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Linus Walleij, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie
Cc: Olliver Schinagl, Robin Gong, Rafael J. Wysocki, Aaron Lu,
Mika Westerberg, Grant Likely, Wolfram Sang, Alexander Shiyan,
Jingoo Han, devicetree, linux-kernel, linux-gpio, linux-input,
linux-leds
In-Reply-To: <1420621722-7428-1-git-send-email-oliver+list@schinagl.nl>
From: Olliver Schinagl <oliver@schinagl.nl>
Checkpatch complains, and probably with good reason that we should use
const char const * for the static constant array that never gets
changed.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
---
drivers/gpio/gpiolib.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index 487afe6..9d2a371 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -1657,7 +1657,7 @@ static struct gpio_desc *of_find_gpio(struct device *dev, const char *con_id,
unsigned int idx,
enum gpio_lookup_flags *flags)
{
- static const char *suffixes[] = { "gpios", "gpio" };
+ static const char const *suffixes[] = { "gpios", "gpio" };
char prop_name[32]; /* 32 is max size of property name */
enum of_gpio_flags of_flags;
struct gpio_desc *desc;
--
2.1.4
^ permalink raw reply related
* [PATCH v1 2/4] gpio: add parameter to allow the use named gpios
From: Olliver Schinagl @ 2015-01-07 9:08 UTC (permalink / raw)
To: Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
Linus Walleij, Alexandre Courbot, Dmitry Torokhov, Bryan Wu,
Richard Purdie
Cc: Olliver Schinagl, Robin Gong, Rafael J. Wysocki, Aaron Lu,
Mika Westerberg, Grant Likely, Wolfram Sang, Alexander Shiyan,
Jingoo Han, devicetree, linux-kernel, linux-gpio, linux-input,
linux-leds
In-Reply-To: <1420621722-7428-1-git-send-email-oliver+list@schinagl.nl>
From: Olliver Schinagl <oliver@schinagl.nl>
The gpio binding document says that new code should always use named
gpios. Patch 40b73183 added support to parse a list of gpios from child
nodes, but does not make it possible to use named gpios. This patch adds
the con_id property and implements it is done in gpiolib.c, where the
old-style of using unnamed gpios still works.
Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
---
drivers/gpio/devres.c | 16 +++++++++++++++-
drivers/input/keyboard/gpio_keys_polled.c | 2 +-
drivers/leds/leds-gpio.c | 2 +-
include/linux/gpio/consumer.h | 1 +
4 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/devres.c b/drivers/gpio/devres.c
index 13dbd3d..b7fbe1c 100644
--- a/drivers/gpio/devres.c
+++ b/drivers/gpio/devres.c
@@ -111,23 +111,37 @@ EXPORT_SYMBOL(__devm_gpiod_get_index);
/**
* devm_get_gpiod_from_child - get a GPIO descriptor from a device's child node
* @dev: GPIO consumer
+ * @con_id: function within the GPIO consumer
* @child: firmware node (child of @dev)
*
* GPIO descriptors returned from this function are automatically disposed on
* driver detach.
*/
struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
+ const char *con_id,
struct fwnode_handle *child)
{
+ static const char const *suffixes[] = { "gpios", "gpio" };
+ char prop_name[32]; /* 32 is max size of property name */
struct gpio_desc **dr;
struct gpio_desc *desc;
+ unsigned int i;
dr = devres_alloc(devm_gpiod_release, sizeof(struct gpio_desc *),
GFP_KERNEL);
if (!dr)
return ERR_PTR(-ENOMEM);
- desc = fwnode_get_named_gpiod(child, "gpios");
+ for (i = 0; i < ARRAY_SIZE(suffixes); i++) {
+ if (con_id)
+ snprintf(prop_name, 32, "%s-%s", con_id, suffixes[i]);
+ else
+ snprintf(prop_name, 32, "%s", suffixes[i]);
+
+ desc = fwnode_get_named_gpiod(child, prop_name);
+ if (!IS_ERR(desc) || (PTR_ERR(desc) == -EPROBE_DEFER))
+ break;
+ }
if (IS_ERR(desc)) {
devres_free(dr);
return desc;
diff --git a/drivers/input/keyboard/gpio_keys_polled.c b/drivers/input/keyboard/gpio_keys_polled.c
index 90df4df..097d721 100644
--- a/drivers/input/keyboard/gpio_keys_polled.c
+++ b/drivers/input/keyboard/gpio_keys_polled.c
@@ -125,7 +125,7 @@ static struct gpio_keys_platform_data *gpio_keys_polled_get_devtree_pdata(struct
device_for_each_child_node(dev, child) {
struct gpio_desc *desc;
- desc = devm_get_gpiod_from_child(dev, child);
+ desc = devm_get_gpiod_from_child(dev, NULL, child);
if (IS_ERR(desc)) {
error = PTR_ERR(desc);
if (error != -EPROBE_DEFER)
diff --git a/drivers/leds/leds-gpio.c b/drivers/leds/leds-gpio.c
index 7ea1ea42..8e5af69 100644
--- a/drivers/leds/leds-gpio.c
+++ b/drivers/leds/leds-gpio.c
@@ -184,7 +184,7 @@ static struct gpio_leds_priv *gpio_leds_create(struct platform_device *pdev)
struct gpio_led led = {};
const char *state = NULL;
- led.gpiod = devm_get_gpiod_from_child(dev, child);
+ led.gpiod = devm_get_gpiod_from_child(dev, NULL, child);
if (IS_ERR(led.gpiod)) {
fwnode_handle_put(child);
goto err;
diff --git a/include/linux/gpio/consumer.h b/include/linux/gpio/consumer.h
index 45afc2d..ed20759 100644
--- a/include/linux/gpio/consumer.h
+++ b/include/linux/gpio/consumer.h
@@ -110,6 +110,7 @@ struct fwnode_handle;
struct gpio_desc *fwnode_get_named_gpiod(struct fwnode_handle *fwnode,
const char *propname);
struct gpio_desc *devm_get_gpiod_from_child(struct device *dev,
+ const char *con_id,
struct fwnode_handle *child);
#else /* CONFIG_GPIOLIB */
--
2.1.4
^ permalink raw reply related
* Re: [PATCH 1/1] Elantech touchpad detection fix for laptops
From: Srihari Vijayaraghavan @ 2015-01-07 9:11 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input, Mateusz Jończyk, Zakariya Dehlawi,
Guillaume Bouchard
In-Reply-To: <CAEK4c-_xcj2JrNEcnARSwWwNQxow+JO1F1hf_d1befApXKNegw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1735 bytes --]
On 7 January 2015 at 19:23, Srihari Vijayaraghavan
<linux.bug.reporting@gmail.com> wrote:
> On 7 January 2015 at 18:44, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:
>> Hi Srihari,
>
> Hello Dimitry,
>
> Thanks for your feedback. Much appreciated.
>
>> On Mon, Jan 05, 2015 at 07:45:39PM +1100, Srihari Vijayaraghavan wrote:
>>> Hello Folks & Dmitry,
>>>
>>> Further to the previous patch, here is the current version (against
>>> mainline) updated with the DMI info of another laptop model where this
>>> fix had helped a user.
>>>
>>> Can you please review it & give some feedback? If it looks good as it
>>> is, then on behalf of all affected users (including yours truly), may
>>> I request for it to be merged upstream (and possibly stable too)?
>>>
>>> (If the patch gets spoiled by gmail, please ref to this bugzilla URL,
>>> where this patch is there as a file attachment:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=81331)
>>
>> I am not terribly happy with having fiddling with keyboard from i8042
>> core, but I guess that's what we have to do unless someone has better
>> idea...
>
> Agreed 100%. Regrettably, seeing how psmouse_do_detect() doesn't even
> get invoked, this heavy handed approach had to be taken at i8042 core.
> However, as you've pointed out, if there is any better idea, we're all
> ears.
>
>> I'll drop mention of Elantech from the option though as it may well be
>> needed for other devices in the future.
>
> A version of the patch (against mainline) incorporating your ideas
> (i.e., without too much Elantech bashing) is attached to this email
> for your review.
>
>> Thanks!
[Sorry to respond to my own email.]
Here's a better version, removing Elantech ref from the table name.
Thanks
[-- Attachment #2: touchpad_detection_fix_for_laptops_v6_against_mainline.patch --]
[-- Type: text/x-patch, Size: 4277 bytes --]
commit 2b5d814d08d4dde95c5e82b1f37bc871801038da
Author: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Date: Wed Jan 7 20:00:51 2015 +1100
As reported in kernel bugzilla 81331, on some laptops, keyboard needs to be
reset for the detection of touchpad (e.g., some Gigabyte laptop models
containing Elantech).
Based on the original patch by Mateusz Jończyk this version has been expanded
to include DMI based detection & application of the fix automatically on the
affected models of laptops. This has been confirmed to fix problem by three
users already on three different models of laptops.
Signed-off-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Acked-by: Mateusz Jończyk <mat.jonczyk@o2.pl>
Tested-by: Srihari Vijayaraghavan <linux.bug.reporting@gmail.com>
Tested by: Zakariya Dehlawi <zdehlawi@gmail.com>
Tested-by: Guillaum Bouchard <guillaum.bouchard@gmail.com>
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 4df73da..603fa10 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1277,6 +1277,7 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
i8042.notimeout [HW] Ignore timeout condition signalled by controller
i8042.reset [HW] Reset the controller during init and cleanup
i8042.unlock [HW] Unlock (ignore) the keylock
+ i8042.kbdreset [HW] Reset keyboard to detect touchpad on some laptops
i810= [HW,DRM]
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index c66d1b5..3becf89 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -745,6 +745,36 @@ static const struct dmi_system_id __initconst i8042_dmi_dritek_table[] = {
{ }
};
+/*
+ * Some laptops need keyboard reset before probing for the trackpad to get it
+ * detected, initialised & finally work (e.g., some Gigabyte laptop models containing
+ * Elantech touchpad).
+ */
+static const struct dmi_system_id __initconst i8042_dmi_touchpad_kbdreset_table[] = {
+ {
+ /* Gigabyte P35 v2 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P35V2"),
+ },
+ },
+ {
+ /* Aorus branded Gigabyte X3 Plus */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X3"),
+ },
+ },
+ {
+ /* Gigabyte P34 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "P34"),
+ },
+ },
+ { }
+};
+
#endif /* CONFIG_X86 */
#ifdef CONFIG_PNP
@@ -1040,6 +1070,9 @@ static int __init i8042_platform_init(void)
if (dmi_check_system(i8042_dmi_dritek_table))
i8042_dritek = true;
+ if (dmi_check_system(i8042_dmi_touchpad_kbdreset_table))
+ i8042_kbdreset = true;
+
/*
* A20 was already enabled during early kernel init. But some buggy
* BIOSes (in MSI Laptops) require A20 to be enabled using 8042 to
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 924e4bf..1a6ff74 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -67,6 +67,10 @@ static bool i8042_notimeout;
module_param_named(notimeout, i8042_notimeout, bool, 0);
MODULE_PARM_DESC(notimeout, "Ignore timeouts signalled by i8042");
+static bool i8042_kbdreset;
+module_param_named(kbdreset, i8042_kbdreset, bool, 0);
+MODULE_PARM_DESC(kbdreset, "Reset keyboard to detect touchpad on some laptops");
+
#ifdef CONFIG_X86
static bool i8042_dritek;
module_param_named(dritek, i8042_dritek, bool, 0);
@@ -790,6 +794,15 @@ static int __init i8042_check_aux(void)
return -1;
/*
+ * Reset keyboard to detect touchpad on some laptops
+ * (e.g., some Gigabyte laptop models containing Elantech touchpad)
+ */
+ if (i8042_kbdreset) {
+ pr_warn("Resetting keyboard to detect touchpad on some laptops\n");
+ i8042_kbd_write(NULL, (unsigned char) 0xff);
+ }
+
+/*
* Test AUX IRQ delivery to make sure BIOS did not grab the IRQ and
* used it for a PCI card or somethig else.
*/
^ permalink raw reply related
* Re: [PATCH 1/1] x86: Added support for Japanese Surface Type Cover 3
From: Jiri Kosina @ 2015-01-07 9:14 UTC (permalink / raw)
To: Alan Wu
Cc: Karlis Dreizis, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1420597971-4438-1-git-send-email-alan.c.wu-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Tue, 6 Jan 2015, Alan Wu wrote:
> Based on code for the US Surface Type Cover 3
> from commit be3b16341d5cd8cf2a64fcc7a604a8efe6599ff0
> ("HID: add support for MS Surface Pro 3 Type Cover"):
Applied, thanks.
--
Jiri Kosina
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v1] input: make use of the input_set_capability helper
From: Olliver Schinagl @ 2015-01-07 9:41 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Olliver Schinagl, Wolfram Sang, Paul Gortmaker, Jingoo Han,
David S. Miller, Sam Ravnborg, linux-input, linux-kernel
In-Reply-To: <20150107082603.GG5256@dtor-ws>
HEy Dmitry,
On 07-01-15 09:26, Dmitry Torokhov wrote:
> On Wed, Jan 07, 2015 at 09:19:28AM +0100, Olliver Schinagl wrote:
>> Hey Dmitry,
>>
>> On 07-01-15 08:57, Dmitry Torokhov wrote:
>>> Hi Olliver,
>>>
>>> On Wed, Jan 07, 2015 at 08:31:06AM +0100, Olliver Schinagl wrote:
>>>> From: Olliver Schinagl <oliver@schinagl.nl>
>>>>
>>>> Almost all of the speaker drivers under input manipulate the ev bits
>>>> directly, which is not needed, as there is a helper available.
>>>>
>>>> This patch makes use of the helper for the speaker drivers.
>>>>
>>>> Signed-off-by: Olliver Schinagl <oliver@schinagl.nl>
>>>> ---
>>>> drivers/input/misc/cm109.c | 4 ++--
>>>> drivers/input/misc/ixp4xx-beeper.c | 5 ++---
>>>> drivers/input/misc/m68kspkr.c | 5 ++---
>>>> drivers/input/misc/pcspkr.c | 5 ++---
>>>> drivers/input/misc/pwm-beeper.c | 5 +----
>>>> drivers/input/misc/sparcspkr.c | 6 ++----
>>>> 6 files changed, 11 insertions(+), 19 deletions(-)
>>>>
>>>> diff --git a/drivers/input/misc/cm109.c b/drivers/input/misc/cm109.c
>>>> index 9365535..8e41070 100644
>>>> --- a/drivers/input/misc/cm109.c
>>>> +++ b/drivers/input/misc/cm109.c
>>>> @@ -767,10 +767,10 @@ static int cm109_usb_probe(struct usb_interface *intf,
>>>> input_dev->keycodesize = sizeof(unsigned char);
>>>> input_dev->keycodemax = ARRAY_SIZE(dev->keymap);
>>>> - input_dev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_SND);
>>>> - input_dev->sndbit[0] = BIT_MASK(SND_BELL) | BIT_MASK(SND_TONE);
>>>> + input_set_capability(input_dev, EV_SND, SND_BELL | SND_TONE);
>>> No, input_set_capability() takes single event code, not bitmask. The
>>> fact that it works for these 2 values of SND events is pure coincidence
>>> (the old code wasn't much better though).
> Ah, not, it does not work at all. Instead of setting bits 1 and 2 your
> code sets bit 3 in dev->sndbit.
>
>> What do you suggest we should do then? Fix input_set_capability to
>> take bit masks? or multiline events?
>> I'm not sure why __set_bits() wouldn't work for bitmasks, could you
>> educate me?
> Call it once per event:
>
> input_set_capability(input_dev, EV_SND, SND_BELL);
> input_set_capability(input_dev, EV_SND, SND_TONE);
roger, done
>
>>>> /* register available key events */
>>>> + input_dev->evbit[0] = BIT_MASK(EV_KEY);
>>> Would prefer __set_bit(EV_KEY, input_dev->evbit); here instead.
>> I only moved the EV_KEY bit from above to its appropiate place here.
> The original code was setting combination of bits; here we set single
> one and __set_bit() is cleaner IMO.
The documentation contradicts this actually, it says to use set_bit()
first, but favors the direct writing as above as it is 'shorter in some
cases'.
Furthermore, I'm a little confused as what the purpose of
input_set_capability() is, if we use set_bits (or __set_bits) here. It
appears we use set_bits here because it is manipulating several entries
in the array (well atleast index 0) and set_input_capability() doesn't
handle arrays? But when I look at struct input_dev, all those entries
are arrays, including sndbit. So we only use set_input_capabilities when
manipulating index 0 when its the only one? Feels a little strange to
me, but probably is my lack of knowledge herin, so appologies for that.
Olliver
>
>> I can change this one (and others) to use __set_bit() for now for
>> v2?
> Yes, please.
>
> Thanks.
>
^ permalink raw reply
* Re: [PATCH 2/2] Input: adxl34x - add device tree documentation
From: Geert Uytterhoeven @ 2015-01-07 9:42 UTC (permalink / raw)
To: Walter Lozano
Cc: michael.hennerich-OyLXuOCK7orQT0dZR+AlfA, Dmitry Torokhov,
Rob Herring, Pawel Moll, Mark Rutland, Ian Campbell, Kumar Gala,
devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-input-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <1420599537-28740-2-git-send-email-walter-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org>
On Wed, Jan 7, 2015 at 3:58 AM, Walter Lozano
<walter-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org> wrote:
> diff --git a/Documentation/devicetree/bindings/input/adxl34x.txt b/Documentation/devicetree/bindings/input/adxl34x.txt
> new file mode 100644
> index 0000000..0774f7e
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/adxl34x.txt
> @@ -0,0 +1,53 @@
> +Device Tree bindings for adxl34x digital accelerometer, both spi and i2c.
> +
> +Depending on the interface this node should be a child of a spi or i2c bus.
> +
> +Required properties:
> +- compatible: "adxl34x"
"adi,adxl34x"?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert-Td1EMuHUCqxL1ZNQvxDV9g@public.gmane.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 01/17] ARM: sunxi: Register cpufreq-dt for sun[45678]i
From: Viresh Kumar @ 2015-01-07 10:01 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Eduardo Valentin,
Hans de Goede, linux-input@vger.kernel.org, linux-arm-kernel,
linux-pm@vger.kernel.org
In-Reply-To: <CAGb2v64Qv1Nhy2w--4T7ujw9NC17QhJdmrn0VyDtTajv+tu+NQ@mail.gmail.com>
On 7 January 2015 at 14:37, Chen-Yu Tsai <wens@csie.org> wrote:
> I believe you are referring to the work done by Viresh Kumar (CCed),
> specifically the 2 series "[RFC V1 0/8] CPUFreq: create platform-dev
> for DT based cpufreq drivers" and "[RFC] OPP: Redefine bindings to
> overcome shortcomings". So far the new code has not appeared in
> linux-next. If it does, I will happily use it.
Yes. You still have to create these platform devices for cpufreq-dt.
^ permalink raw reply
* Re: [PATCH 01/17] ARM: sunxi: Register cpufreq-dt for sun[45678]i
From: Maxime Ripard @ 2015-01-07 10:23 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Dmitry Torokhov, Zhang Rui, Eduardo Valentin, Hans de Goede,
linux-input, linux-arm-kernel, linux-pm
In-Reply-To: <1420511727-8242-2-git-send-email-wens@csie.org>
[-- Attachment #1: Type: text/plain, Size: 418 bytes --]
On Tue, Jan 06, 2015 at 10:35:11AM +0800, Chen-Yu Tsai wrote:
> On sun[45678]i, we have one cluster of identical cores sharing a
> clock, which is ideal for using cpufreq-dt. Register a platform
> device for cpufreq-dt.
>
> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Applied, thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* [PATCH] add raw video support for Samsung SUR40 touchscreen
From: Florian Echtler @ 2015-01-07 10:35 UTC (permalink / raw)
To: hverkuil; +Cc: linux-input, linux-media, Florian Echtler
This patch add support for the raw video stream from the Samsung SUR40
touchscreen device. Existing input device support is not affected by this
patch and can be used concurrently. videobuf2-dma-contig is used for buffer
management. All tests from current v4l2-compliance -s run pass (see
http://floe.butterbrot.org/external/results.txt for details).
Note: I'm intentionally using dma-contig instead of vmalloc, as the USB
core apparently _will_ try to use DMA for larger bulk transfers.
Signed-off-by: Florian Echtler <floe@butterbrot.org>
---
drivers/input/touchscreen/sur40.c | 423 ++++++++++++++++++++++++++++++++++++--
1 file changed, 411 insertions(+), 12 deletions(-)
diff --git a/drivers/input/touchscreen/sur40.c b/drivers/input/touchscreen/sur40.c
index f1cb051..bcd9ee2 100644
--- a/drivers/input/touchscreen/sur40.c
+++ b/drivers/input/touchscreen/sur40.c
@@ -1,7 +1,7 @@
/*
* Surface2.0/SUR40/PixelSense input driver
*
- * Copyright (c) 2013 by Florian 'floe' Echtler <floe@butterbrot.org>
+ * Copyright (c) 2014 by Florian 'floe' Echtler <floe@butterbrot.org>
*
* Derived from the USB Skeleton driver 1.1,
* Copyright (c) 2003 Greg Kroah-Hartman (greg@kroah.com)
@@ -12,6 +12,9 @@
* and from the generic hid-multitouch driver,
* Copyright (c) 2010-2012 Stephane Chatty <chatty@enac.fr>
*
+ * and from the v4l2-pci-skeleton driver,
+ * Copyright (c) Copyright 2014 Cisco Systems, Inc.
+ *
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU General Public License as
* published by the Free Software Foundation; either version 2 of
@@ -31,6 +34,11 @@
#include <linux/input-polldev.h>
#include <linux/input/mt.h>
#include <linux/usb/input.h>
+#include <linux/videodev2.h>
+#include <media/v4l2-device.h>
+#include <media/v4l2-dev.h>
+#include <media/v4l2-ioctl.h>
+#include <media/videobuf2-dma-contig.h>
/* read 512 bytes from endpoint 0x86 -> get header + blobs */
struct sur40_header {
@@ -82,9 +90,19 @@ struct sur40_data {
struct sur40_blob blobs[];
} __packed;
+/* read 512 bytes from endpoint 0x82 -> get header below
+ * continue reading 16k blocks until header.size bytes read */
+struct sur40_image_header {
+ __le32 magic; /* "SUBF" */
+ __le32 packet_id;
+ __le32 size; /* always 0x0007e900 = 960x540 */
+ __le32 timestamp; /* milliseconds (increases by 16 or 17 each frame) */
+ __le32 unknown; /* "epoch?" always 02/03 00 00 00 */
+} __packed;
/* version information */
#define DRIVER_SHORT "sur40"
+#define DRIVER_LONG "Samsung SUR40"
#define DRIVER_AUTHOR "Florian 'floe' Echtler <floe@butterbrot.org>"
#define DRIVER_DESC "Surface2.0/SUR40/PixelSense input driver"
@@ -99,6 +117,13 @@ struct sur40_data {
/* touch data endpoint */
#define TOUCH_ENDPOINT 0x86
+/* video data endpoint */
+#define VIDEO_ENDPOINT 0x82
+
+/* video header fields */
+#define VIDEO_HEADER_MAGIC 0x46425553
+#define VIDEO_PACKET_SIZE 16384
+
/* polling interval (ms) */
#define POLL_INTERVAL 10
@@ -113,21 +138,23 @@ struct sur40_data {
#define SUR40_GET_STATE 0xc5 /* 4 bytes state (?) */
#define SUR40_GET_SENSORS 0xb1 /* 8 bytes sensors */
-/*
- * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
- * here by mistake which is very likely to have corrupted the firmware EEPROM
- * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
- * Should you ever run into a similar problem, the background story to this
- * incident and instructions on how to fix the corrupted EEPROM are available
- * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
-*/
-
+/* master device state */
struct sur40_state {
struct usb_device *usbdev;
struct device *dev;
struct input_polled_dev *input;
+ struct v4l2_device v4l2;
+ struct video_device vdev;
+ struct mutex lock;
+
+ struct vb2_queue queue;
+ struct vb2_alloc_ctx *alloc_ctx;
+ struct list_head buf_list;
+ spinlock_t qlock;
+ int sequence;
+
struct sur40_data *bulk_in_buffer;
size_t bulk_in_size;
u8 bulk_in_epaddr;
@@ -135,6 +162,27 @@ struct sur40_state {
char phys[64];
};
+struct sur40_buffer {
+ struct vb2_buffer vb;
+ struct list_head list;
+};
+
+/* forward declarations */
+static struct video_device sur40_video_device;
+static struct v4l2_pix_format sur40_video_format;
+static struct vb2_queue sur40_queue;
+static void sur40_process_video(struct sur40_state *sur40);
+
+/*
+ * Note: an earlier, non-public version of this driver used USB_RECIP_ENDPOINT
+ * here by mistake which is very likely to have corrupted the firmware EEPROM
+ * on two separate SUR40 devices. Thanks to Alan Stern who spotted this bug.
+ * Should you ever run into a similar problem, the background story to this
+ * incident and instructions on how to fix the corrupted EEPROM are available
+ * at https://floe.butterbrot.org/matrix/hacking/surface/brick.html
+*/
+
+/* command wrapper */
static int sur40_command(struct sur40_state *dev,
u8 command, u16 index, void *buffer, u16 size)
{
@@ -247,7 +295,6 @@ static void sur40_report_blob(struct sur40_blob *blob, struct input_dev *input)
/* core function: poll for new input data */
static void sur40_poll(struct input_polled_dev *polldev)
{
-
struct sur40_state *sur40 = polldev->private;
struct input_dev *input = polldev->input;
int result, bulk_read, need_blobs, packet_blobs, i;
@@ -314,6 +361,79 @@ static void sur40_poll(struct input_polled_dev *polldev)
input_mt_sync_frame(input);
input_sync(input);
+
+ sur40_process_video(sur40);
+}
+
+/* deal with video data */
+static void sur40_process_video(struct sur40_state *sur40)
+{
+
+ struct sur40_image_header *img = (void *)(sur40->bulk_in_buffer);
+ int result, bulk_read, bufpos;
+ struct sur40_buffer *new_buf;
+ uint8_t *buffer;
+
+ if (list_empty(&sur40->buf_list))
+ return;
+
+ /* get a new buffer from the list */
+ spin_lock(&sur40->qlock);
+ new_buf = list_entry(sur40->buf_list.next, struct sur40_buffer, list);
+ list_del(&new_buf->list);
+ spin_unlock(&sur40->qlock);
+
+ /* retrieve data via bulk read */
+ bufpos = 0;
+
+ result = usb_bulk_msg(sur40->usbdev,
+ usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT),
+ sur40->bulk_in_buffer, sur40->bulk_in_size,
+ &bulk_read, 1000);
+
+ if (result < 0) {
+ dev_err(sur40->dev, "error in usb_bulk_read\n");
+ goto err_poll;
+ }
+
+ if (bulk_read != sizeof(struct sur40_image_header)) {
+ dev_err(sur40->dev, "received %d bytes (%ld expected)\n",
+ bulk_read, sizeof(struct sur40_image_header));
+ goto err_poll;
+ }
+
+ if (le32_to_cpu(img->magic) != VIDEO_HEADER_MAGIC) {
+ dev_err(sur40->dev, "image magic mismatch\n");
+ goto err_poll;
+ }
+
+ if (le32_to_cpu(img->size) != sur40_video_format.sizeimage) {
+ dev_err(sur40->dev, "image size mismatch\n");
+ goto err_poll;
+ }
+
+ buffer = vb2_plane_vaddr(&new_buf->vb, 0);
+ while (bufpos < sur40_video_format.sizeimage) {
+ result = usb_bulk_msg(sur40->usbdev,
+ usb_rcvbulkpipe(sur40->usbdev, VIDEO_ENDPOINT),
+ buffer+bufpos, VIDEO_PACKET_SIZE,
+ &bulk_read, 1000);
+ if (result < 0) {
+ dev_err(sur40->dev, "error in usb_bulk_read\n");
+ goto err_poll;
+ }
+ bufpos += bulk_read;
+ }
+
+ /* mark as finished */
+ v4l2_get_timestamp(&new_buf->vb.v4l2_buf.timestamp);
+ new_buf->vb.v4l2_buf.sequence = sur40->sequence++;
+ new_buf->vb.v4l2_buf.field = V4L2_FIELD_NONE;
+ vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_DONE);
+ return;
+
+err_poll:
+ vb2_buffer_done(&new_buf->vb, VB2_BUF_STATE_ERROR);
}
/* Initialize input device parameters. */
@@ -377,6 +497,11 @@ static int sur40_probe(struct usb_interface *interface,
goto err_free_dev;
}
+ /* initialize locks/lists */
+ INIT_LIST_HEAD(&sur40->buf_list);
+ spin_lock_init(&sur40->qlock);
+ mutex_init(&sur40->lock);
+
/* Set up polled input device control structure */
poll_dev->private = sur40;
poll_dev->poll_interval = POLL_INTERVAL;
@@ -387,7 +512,7 @@ static int sur40_probe(struct usb_interface *interface,
/* Set up regular input device structure */
sur40_input_setup(poll_dev->input);
- poll_dev->input->name = "Samsung SUR40";
+ poll_dev->input->name = DRIVER_LONG;
usb_to_input_id(usbdev, &poll_dev->input->id);
usb_make_path(usbdev, sur40->phys, sizeof(sur40->phys));
strlcat(sur40->phys, "/input0", sizeof(sur40->phys));
@@ -408,6 +533,7 @@ static int sur40_probe(struct usb_interface *interface,
goto err_free_polldev;
}
+ /* register the polled input device */
error = input_register_polled_device(poll_dev);
if (error) {
dev_err(&interface->dev,
@@ -415,12 +541,54 @@ static int sur40_probe(struct usb_interface *interface,
goto err_free_buffer;
}
+ /* register the video master device */
+ snprintf(sur40->v4l2.name, sizeof(sur40->v4l2.name), "%s", DRIVER_LONG);
+ error = v4l2_device_register(sur40->dev, &sur40->v4l2);
+ if (error) {
+ dev_err(&interface->dev,
+ "Unable to register video master device.");
+ goto err_unreg_v4l2;
+ }
+
+ /* initialize the lock and subdevice */
+ sur40->queue = sur40_queue;
+ sur40->queue.drv_priv = sur40;
+ sur40->queue.lock = &sur40->lock;
+
+ /* initialize the queue */
+ error = vb2_queue_init(&sur40->queue);
+ if (error)
+ goto err_unreg_v4l2;
+
+ sur40->alloc_ctx = vb2_dma_contig_init_ctx(sur40->dev);
+ if (IS_ERR(sur40->alloc_ctx)) {
+ dev_err(sur40->dev, "Can't allocate buffer context");
+ goto err_unreg_v4l2;
+ }
+
+ sur40->vdev = sur40_video_device;
+ sur40->vdev.v4l2_dev = &sur40->v4l2;
+ sur40->vdev.lock = &sur40->lock;
+ sur40->vdev.queue = &sur40->queue;
+ video_set_drvdata(&sur40->vdev, sur40);
+
+ error = video_register_device(&sur40->vdev, VFL_TYPE_GRABBER, -1);
+ if (error) {
+ dev_err(&interface->dev,
+ "Unable to register video subdevice.");
+ goto err_unreg_video;
+ }
+
/* we can register the device now, as it is ready */
usb_set_intfdata(interface, sur40);
dev_dbg(&interface->dev, "%s is now attached\n", DRIVER_DESC);
return 0;
+err_unreg_video:
+ video_unregister_device(&sur40->vdev);
+err_unreg_v4l2:
+ v4l2_device_unregister(&sur40->v4l2);
err_free_buffer:
kfree(sur40->bulk_in_buffer);
err_free_polldev:
@@ -436,6 +604,10 @@ static void sur40_disconnect(struct usb_interface *interface)
{
struct sur40_state *sur40 = usb_get_intfdata(interface);
+ v4l2_device_unregister(&sur40->v4l2);
+ video_unregister_device(&sur40->vdev);
+ vb2_dma_contig_cleanup_ctx(sur40->alloc_ctx);
+
input_unregister_polled_device(sur40->input);
input_free_polled_device(sur40->input);
kfree(sur40->bulk_in_buffer);
@@ -445,12 +617,239 @@ static void sur40_disconnect(struct usb_interface *interface)
dev_dbg(&interface->dev, "%s is now disconnected\n", DRIVER_DESC);
}
+/*
+ * Setup the constraints of the queue: besides setting the number of planes
+ * per buffer and the size and allocation context of each plane, it also
+ * checks if sufficient buffers have been allocated. Usually 3 is a good
+ * minimum number: many DMA engines need a minimum of 2 buffers in the
+ * queue and you need to have another available for userspace processing.
+ */
+static int sur40_queue_setup(struct vb2_queue *q, const struct v4l2_format *fmt,
+ unsigned int *nbuffers, unsigned int *nplanes,
+ unsigned int sizes[], void *alloc_ctxs[])
+{
+ struct sur40_state *sur40 = vb2_get_drv_priv(q);
+
+ if (q->num_buffers + *nbuffers < 3)
+ *nbuffers = 3 - q->num_buffers;
+
+ if (fmt && fmt->fmt.pix.sizeimage < sur40_video_format.sizeimage)
+ return -EINVAL;
+
+ *nplanes = 1;
+ sizes[0] = fmt ? fmt->fmt.pix.sizeimage : sur40_video_format.sizeimage;
+ alloc_ctxs[0] = sur40->alloc_ctx;
+
+ return 0;
+}
+
+/*
+ * Prepare the buffer for queueing to the DMA engine: check and set the
+ * payload size.
+ */
+static int sur40_buffer_prepare(struct vb2_buffer *vb)
+{
+ struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
+ unsigned long size = sur40_video_format.sizeimage;
+
+ if (vb2_plane_size(vb, 0) < size) {
+ dev_err(&sur40->usbdev->dev, "buffer too small (%lu < %lu)\n",
+ vb2_plane_size(vb, 0), size);
+ return -EINVAL;
+ }
+
+ vb2_set_plane_payload(vb, 0, size);
+ return 0;
+}
+
+/*
+ * Queue this buffer to the DMA engine.
+ */
+static void sur40_buffer_queue(struct vb2_buffer *vb)
+{
+ struct sur40_state *sur40 = vb2_get_drv_priv(vb->vb2_queue);
+ struct sur40_buffer *buf = (struct sur40_buffer *)vb;
+
+ spin_lock(&sur40->qlock);
+ list_add_tail(&buf->list, &sur40->buf_list);
+ spin_unlock(&sur40->qlock);
+}
+
+static void return_all_buffers(struct sur40_state *sur40,
+ enum vb2_buffer_state state)
+{
+ struct sur40_buffer *buf, *node;
+
+ spin_lock(&sur40->qlock);
+ list_for_each_entry_safe(buf, node, &sur40->buf_list, list) {
+ vb2_buffer_done(&buf->vb, state);
+ list_del(&buf->list);
+ }
+ spin_unlock(&sur40->qlock);
+}
+
+/*
+ * Start streaming. First check if the minimum number of buffers have been
+ * queued. If not, then return -ENOBUFS and the vb2 framework will call
+ * this function again the next time a buffer has been queued until enough
+ * buffers are available to actually start the DMA engine.
+ */
+static int sur40_start_streaming(struct vb2_queue *vq, unsigned int count)
+{
+ struct sur40_state *sur40 = vb2_get_drv_priv(vq);
+
+ sur40->sequence = 0;
+ return 0;
+}
+
+/*
+ * Stop the DMA engine. Any remaining buffers in the DMA queue are dequeued
+ * and passed on to the vb2 framework marked as STATE_ERROR.
+ */
+static void sur40_stop_streaming(struct vb2_queue *vq)
+{
+ struct sur40_state *sur40 = vb2_get_drv_priv(vq);
+ /* Release all active buffers */
+ return_all_buffers(sur40, VB2_BUF_STATE_ERROR);
+}
+
+/* V4L ioctl */
+static int sur40_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap)
+{
+ struct sur40_state *sur40 = video_drvdata(file);
+
+ strlcpy(cap->driver, DRIVER_SHORT, sizeof(cap->driver));
+ strlcpy(cap->card, DRIVER_LONG, sizeof(cap->card));
+ usb_make_path(sur40->usbdev, cap->bus_info, sizeof(cap->bus_info));
+ cap->device_caps = V4L2_CAP_VIDEO_CAPTURE |
+ V4L2_CAP_READWRITE |
+ V4L2_CAP_STREAMING;
+ cap->capabilities = cap->device_caps | V4L2_CAP_DEVICE_CAPS;
+ return 0;
+}
+
+static int sur40_vidioc_enum_input(struct file *file, void *priv,
+ struct v4l2_input *i)
+{
+ if (i->index != 0)
+ return -EINVAL;
+ i->type = V4L2_INPUT_TYPE_CAMERA;
+ i->std = V4L2_STD_UNKNOWN;
+ strlcpy(i->name, "In-Cell Sensor", sizeof(i->name));
+ i->capabilities = 0;
+ return 0;
+}
+
+static int sur40_vidioc_s_input(struct file *file, void *priv, unsigned int i)
+{
+ return (i == 0) ? 0 : -EINVAL;
+}
+
+static int sur40_vidioc_g_input(struct file *file, void *priv, unsigned int *i)
+{
+ *i = 0;
+ return 0;
+}
+
+static int sur40_vidioc_fmt(struct file *file, void *priv,
+ struct v4l2_format *f)
+{
+ f->fmt.pix = sur40_video_format;
+ return 0;
+}
+
+static int sur40_vidioc_enum_fmt(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if (f->index != 0)
+ return -EINVAL;
+ strlcpy(f->description, "8-bit greyscale", sizeof(f->description));
+ f->pixelformat = V4L2_PIX_FMT_GREY;
+ f->flags = 0;
+ return 0;
+}
+
static const struct usb_device_id sur40_table[] = {
{ USB_DEVICE(ID_MICROSOFT, ID_SUR40) }, /* Samsung SUR40 */
{ } /* terminating null entry */
};
MODULE_DEVICE_TABLE(usb, sur40_table);
+/* V4L2 structures */
+static struct vb2_ops sur40_queue_ops = {
+ .queue_setup = sur40_queue_setup,
+ .buf_prepare = sur40_buffer_prepare,
+ .buf_queue = sur40_buffer_queue,
+ .start_streaming = sur40_start_streaming,
+ .stop_streaming = sur40_stop_streaming,
+ .wait_prepare = vb2_ops_wait_prepare,
+ .wait_finish = vb2_ops_wait_finish,
+};
+
+static struct vb2_queue sur40_queue = {
+ .type = V4L2_BUF_TYPE_VIDEO_CAPTURE,
+ .io_modes = VB2_MMAP | VB2_READ,
+ .buf_struct_size = sizeof(struct sur40_buffer),
+ .ops = &sur40_queue_ops,
+ .mem_ops = &vb2_dma_contig_memops,
+ .timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC,
+ .min_buffers_needed = 3,
+ .gfp_flags = GFP_DMA,
+};
+
+static const struct v4l2_file_operations sur40_video_fops = {
+ .owner = THIS_MODULE,
+ .open = v4l2_fh_open,
+ .release = vb2_fop_release,
+ .unlocked_ioctl = video_ioctl2,
+ .read = vb2_fop_read,
+ .mmap = vb2_fop_mmap,
+ .poll = vb2_fop_poll,
+};
+
+static const struct v4l2_ioctl_ops sur40_video_ioctl_ops = {
+
+ .vidioc_querycap = sur40_vidioc_querycap,
+
+ .vidioc_enum_fmt_vid_cap = sur40_vidioc_enum_fmt,
+ .vidioc_try_fmt_vid_cap = sur40_vidioc_fmt,
+ .vidioc_s_fmt_vid_cap = sur40_vidioc_fmt,
+ .vidioc_g_fmt_vid_cap = sur40_vidioc_fmt,
+
+ .vidioc_enum_input = sur40_vidioc_enum_input,
+ .vidioc_g_input = sur40_vidioc_g_input,
+ .vidioc_s_input = sur40_vidioc_s_input,
+
+ .vidioc_reqbufs = vb2_ioctl_reqbufs,
+ .vidioc_create_bufs = vb2_ioctl_create_bufs,
+ .vidioc_querybuf = vb2_ioctl_querybuf,
+ .vidioc_qbuf = vb2_ioctl_qbuf,
+ .vidioc_dqbuf = vb2_ioctl_dqbuf,
+ .vidioc_expbuf = vb2_ioctl_expbuf,
+
+ .vidioc_streamon = vb2_ioctl_streamon,
+ .vidioc_streamoff = vb2_ioctl_streamoff,
+};
+
+static struct video_device sur40_video_device = {
+ .name = DRIVER_LONG,
+ .fops = &sur40_video_fops,
+ .ioctl_ops = &sur40_video_ioctl_ops,
+ .release = video_device_release_empty,
+};
+
+static struct v4l2_pix_format sur40_video_format = {
+ .pixelformat = V4L2_PIX_FMT_GREY,
+ .width = SENSOR_RES_X / 2,
+ .height = SENSOR_RES_Y / 2,
+ .field = V4L2_FIELD_NONE,
+ .colorspace = V4L2_COLORSPACE_SRGB,
+ .bytesperline = SENSOR_RES_X / 2,
+ .sizeimage = (SENSOR_RES_X/2) * (SENSOR_RES_Y/2),
+ .priv = 0,
+};
+
/* USB-specific object needed to register this driver with the USB subsystem. */
static struct usb_driver sur40_driver = {
.name = DRIVER_SHORT,
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] HID: hid-sensor-hub: Correct documentation
From: Srinivas Pandruvada @ 2015-01-07 16:01 UTC (permalink / raw)
To: Jiri Kosina
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LNX.2.00.1501070946540.25732-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
On Wed, 2015-01-07 at 09:48 +0100, Jiri Kosina wrote: Hi Jiri,
> Srinivas,
>
> the way you sent the patches are really confusing.
>
> Most importantly, you seem to have inter-mixed three patch series (with
> 4,8 and 9 patches respectively) into one thread, plus there are 4 patches
> which aren't marked by series numbering. All this is mixed together into
> one thread without any particular ordering.
>
There are 7 series:
- The four patches, which are single independent patches
- The others 3 are multiple patches part of series.
> This way it makes it really difficult to review (and possibly apply
> afterwards).
>
> Could you please resend as proper independent series, with correct
> threading etc?
Let me send again one series at a time.
Thanks,
Srinivas
>
> --
> Jiri Kosina
> SUSE Labs
^ permalink raw reply
* Re: [PATCH 03/17] Input: sun4i-ts: Add thermal zone sensor support
From: Chen-Yu Tsai @ 2015-01-07 16:24 UTC (permalink / raw)
To: Eduardo Valentin
Cc: Maxime Ripard, Dmitry Torokhov, Zhang Rui, Hans de Goede,
linux-input@vger.kernel.org, linux-arm-kernel, linux-pm
In-Reply-To: <20150106152425.GA6276@developer>
Hi,
On Tue, Jan 6, 2015 at 11:24 PM, Eduardo Valentin <edubezval@gmail.com> wrote:
> Hello Chen-Yu,
>
>
> On Tue, Jan 06, 2015 at 10:35:13AM +0800, Chen-Yu Tsai wrote:
>> The touchscreen controller has a temperature sensor embedded in the SoC,
>> which already has hwmon support in the driver.
>>
>> Add DT thermal zone support so we can use it with cpufreq for thermal
>> throttling.
>>
>> Signed-off-by: Chen-Yu Tsai <wens@csie.org>
>> ---
>> .../bindings/input/touchscreen/sun4i.txt | 1 +
>> drivers/input/touchscreen/sun4i-ts.c | 27 ++++++++++++++++++++++
>> 2 files changed, 28 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>> index aef57791f40b..7f1110adbd24 100644
>> --- a/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>> +++ b/Documentation/devicetree/bindings/input/touchscreen/sun4i.txt
>> @@ -5,6 +5,7 @@ Required properties:
>> - compatible: "allwinner,sun4i-a10-ts"
>> - reg: mmio address range of the chip
>> - interrupts: interrupt to which the chip is connected
>> + - #thermal-sensor-cells: shall be 0
>>
>
> You may want to update your Example section too, below.
> Example:
>
> rtp: rtp@01c25000 {
> compatible = "allwinner,sun4i-a10-ts";
> reg = <0x01c25000 0x100>;
> interrupts = <29>;
> allwinner,ts-attached;
> #thermal-sensor-cells = <0>;
> };
Ok.
>
>
>> Optional properties:
>> - allwinner,ts-attached: boolean indicating that an actual touchscreen is
>> diff --git a/drivers/input/touchscreen/sun4i-ts.c b/drivers/input/touchscreen/sun4i-ts.c
>> index 28a06749ae42..b6e9043446d6 100644
>> --- a/drivers/input/touchscreen/sun4i-ts.c
>> +++ b/drivers/input/touchscreen/sun4i-ts.c
>> @@ -34,6 +34,7 @@
>>
>> #include <linux/err.h>
>> #include <linux/hwmon.h>
>> +#include <linux/thermal.h>
>> #include <linux/init.h>
>> #include <linux/input.h>
>> #include <linux/interrupt.h>
>> @@ -107,6 +108,7 @@
>> struct sun4i_ts_data {
>> struct device *dev;
>> struct input_dev *input;
>> + struct thermal_zone_device *tz;
>> void __iomem *base;
>> unsigned int irq;
>> bool ignore_fifo_data;
>> @@ -180,6 +182,23 @@ static void sun4i_ts_close(struct input_dev *dev)
>> writel(TEMP_IRQ_EN(1), ts->base + TP_INT_FIFOC);
>> }
>>
>> +static int get_temp(void *data, long *temp)
>> +{
>> + struct sun4i_ts_data *ts = data;
>> +
>> + /* No temp_data until the first irq */
>> + if (ts->temp_data == -1)
>> + return -EAGAIN;
>> +
>> + *temp = (ts->temp_data - 1447) * 100;
>> +
>
> Care to explain the formula in a simple comment?
This was just copied from the hwmon section. AFAIK there is no documentation
for the formula. It was probably copied from Allwinner's SDK code.
Hans? Do you remember where you got this?
>> + return 0;
>> +}
>> +
>> +static struct thermal_zone_of_device_ops sun4i_ts_tz_ops = {
>> + .get_temp = get_temp,
>> +};
>> +
>> static ssize_t show_temp(struct device *dev, struct device_attribute *devattr,
>> char *buf)
>> {
>> @@ -288,6 +307,11 @@ static int sun4i_ts_probe(struct platform_device *pdev)
>> if (IS_ERR(hwmon))
>> return PTR_ERR(hwmon);
>>
>> + ts->tz = thermal_zone_of_sensor_register(ts->dev, 0, ts,
>> + &sun4i_ts_tz_ops);
>> + if (IS_ERR(ts->tz))
>> + ts->tz = NULL;
>> +
>> writel(TEMP_IRQ_EN(1), ts->base + TP_INT_FIFOC);
>>
>> if (ts_attached) {
>
> here.. if input_register_device fails, you will keep an orphan thermal zone
> registered in your system:
>
> error = input_register_device(ts->input);
> if (error) {
> writel(0, ts->base + TP_INT_FIFOC);
Will add an unregister call here.
Thanks for the review.
ChenYu
> return error;
> }
> ...
>
>
>> @@ -310,6 +334,9 @@ static int sun4i_ts_remove(struct platform_device *pdev)
>> if (ts->input)
>> input_unregister_device(ts->input);
>>
>> + if (ts->tz)
>> + thermal_zone_of_sensor_unregister(ts->dev, ts->tz);
>> +
>> /* Deactivate all IRQs */
>> writel(0, ts->base + TP_INT_FIFOC);
>>
>> --
>> 2.1.4
>>
^ permalink raw reply
* Re: [PATCH 1/2] Input: adxl34x - add OF support
From: Walter Lozano @ 2015-01-07 16:25 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: michael.hennerich-OyLXuOCK7orQT0dZR+AlfA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, pawel.moll-5wv7dgnIgG8,
mark.rutland-5wv7dgnIgG8, ijc+devicetree-KcIKpvwj1kUDXYZnReoRVg,
Kumar Gala, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20150107080159.GF5256@dtor-ws>
Hi Dimitry,
First of all, thanks for your feedback
On Wed, Jan 7, 2015 at 5:01 AM, Dmitry Torokhov
<dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Walter,
>
> On Tue, Jan 06, 2015 at 11:58:56PM -0300, Walter Lozano wrote:
>> This patch adds the missing support for OF to the adxl34x digital
>> accelerometer. This is a basic version which supports the main
>> optional parameters. This implementation copies the default values
>> to the adxl34x_platform_data structure and overrides the values
>> that are passed from the device tree.
>>
>> Signed-off-by: Walter Lozano <walter-30ULvvUtt6G51wMPkGsGjgyUoB5FGQPZ@public.gmane.org>
>> ---
>> drivers/input/misc/adxl34x.c | 108 +++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 107 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/input/misc/adxl34x.c b/drivers/input/misc/adxl34x.c
>> index 2b2d02f..b3e06a3 100644
>> --- a/drivers/input/misc/adxl34x.c
>> +++ b/drivers/input/misc/adxl34x.c
>> @@ -16,6 +16,8 @@
>> #include <linux/workqueue.h>
>> #include <linux/input/adxl34x.h>
>> #include <linux/module.h>
>> +#include <linux/of.h>
>> +#include <linux/of_device.h>
>>
>> #include "adxl34x.h"
>>
>> @@ -688,13 +690,113 @@ static void adxl34x_input_close(struct input_dev *input)
>> mutex_unlock(&ac->mutex);
>> }
>>
>> +void adxl34x_parse_dt(struct device *dev, struct adxl34x_platform_data *pdata){
>> + if (!dev->of_node)
>> + return;
>> +
>> + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
>> +
>> + memcpy(pdata, &adxl34x_default_init, sizeof(struct adxl34x_platform_data));
>> +
>> + of_property_read_u8(dev->of_node, "adi,tap-axis-control",
>> + &pdata->tap_axis_control);
>> +
>> + of_property_read_u8(dev->of_node, "adi,tap-threshold",
>> + &pdata->tap_threshold);
>> +
>> + of_property_read_u8(dev->of_node, "adi,tap-duration",
>> + &pdata->tap_duration);
>> +
>> + of_property_read_u8(dev->of_node, "adi,tap-latency",
>> + &pdata->tap_latency);
>> +
>> + of_property_read_u8(dev->of_node, "adi,tap-window",
>> + &pdata->tap_window);
>> +
>> + of_property_read_u8(dev->of_node, "adi,act-axis-control",
>> + &pdata->act_axis_control);
>> +
>> + of_property_read_u8(dev->of_node, "adi,activity-threshold",
>> + &pdata->activity_threshold);
>> +
>> + of_property_read_u8(dev->of_node, "adi,inactivity-threshold",
>> + &pdata->inactivity_threshold);
>> +
>> + of_property_read_u8(dev->of_node, "adi,inactivity-time",
>> + &pdata->inactivity_time);
>> +
>> + of_property_read_u8(dev->of_node, "adi,free-fall-threshold",
>> + &pdata->free_fall_threshold);
>> +
>> + of_property_read_u8(dev->of_node, "adi,free-fall-time",
>> + &pdata->free_fall_time);
>> +
>> + of_property_read_u8(dev->of_node, "adi,data-rate",
>> + &pdata->data_rate);
>> +
>> + of_property_read_u8(dev->of_node, "adi,data-range",
>> + &pdata->data_range);
>> +
>> + of_property_read_u8(dev->of_node, "adi,low-power-mode",
>> + &pdata->low_power_mode);
>> +
>> + of_property_read_u8(dev->of_node, "adi,power-mode",
>> + &pdata->power_mode);
>> +
>> + of_property_read_u8(dev->of_node, "adi,fifo-mode",
>> + &pdata->fifo_mode);
>> +
>> + of_property_read_u8(dev->of_node, "adi,watermark",
>> + &pdata->watermark);
>> +
>> + of_property_read_u8(dev->of_node, "adi,use-int2",
>> + &pdata->use_int2);
>> +
>> + of_property_read_u8(dev->of_node, "adi,orientation-enable",
>> + &pdata->orientation_enable);
>> +
>> + of_property_read_u8(dev->of_node, "adi,deadzone-angle",
>> + &pdata->deadzone_angle);
>> +
>> + of_property_read_u8(dev->of_node, "adi,divisor-length",
>> + &pdata->divisor_length);
>> +
>> + of_property_read_u32(dev->of_node, "adi,ev-type",
>> + &pdata->ev_type);
>
> All these ev* properties are Linux-specific so should have linux prefix
> and not adi.
Yes, I have many doubts about these parameters. First I'm not sure if anybody
will need to change them as the accelerometer reports absolute values.
I was thinking
about omitting them but I would like someone else opinion.
The default values for these parameters are
.ev_type = EV_ABS,
.ev_code_x = ABS_X, /* EV_REL */
.ev_code_y = ABS_Y, /* EV_REL */
.ev_code_z = ABS_Z, /* EV_REL */
.ev_code_tap = {BTN_TOUCH, BTN_TOUCH, BTN_TOUCH}, /* EV_KEY {x,y,z} */
In case if it is worthy should I add nodes for each different event?
For example
axisx{
label = "Axis X";
linux,code = <0>;
}
>> +
>> + of_property_read_u32(dev->of_node, "adi,ev-code-x",
>> + &pdata->ev_code_x);
>> +
>> + of_property_read_u32(dev->of_node, "adi,ev-code-y",
>> + &pdata->ev_code_y);
>> +
>> + of_property_read_u32(dev->of_node, "adi,ev-code-z",
>> + &pdata->ev_code_z);
>> +
>> + of_property_read_u32_array(dev->of_node, "adi,ev-code-tap",
>> + pdata->ev_code_tap, 3);
>> +
>> + of_property_read_u32(dev->of_node, "adi,ev-code-ff",
>> + &pdata->ev_code_ff);
>> +
>> + of_property_read_u32(dev->of_node, "adi,ev-code-act-inactivity",
>> + &pdata->ev_code_act_inactivity);
>> +
>> + of_property_read_u32_array(dev->of_node, "adi,ev-codes-orient-2d",
>> + pdata->ev_codes_orient_2d, 4);
>> +
>> + of_property_read_u32_array(dev->of_node, "adi,ev-codes-orient-3d",
>> + pdata->ev_codes_orient_3d, 6);
>> +
>> +}
>> +
>> struct adxl34x *adxl34x_probe(struct device *dev, int irq,
>> bool fifo_delay_default,
>> const struct adxl34x_bus_ops *bops)
>> {
>> struct adxl34x *ac;
>> struct input_dev *input_dev;
>> - const struct adxl34x_platform_data *pdata;
>> + struct adxl34x_platform_data *pdata;
>> int err, range, i;
>> unsigned char revid;
>>
>> @@ -714,6 +816,10 @@ struct adxl34x *adxl34x_probe(struct device *dev, int irq,
>> ac->fifo_delay = fifo_delay_default;
>>
>> pdata = dev_get_platdata(dev);
>> +
>> + if (!pdata && dev->of_node)
>> + adxl34x_parse_dt(dev, pdata);
>> +
>> if (!pdata) {
>
> Umm, what's changing data pointer? Was this tested?
>
You are right. I've tested a previous version, but then I make some changes as
I have some doubts about how is the better way to handle the compatibility
with board files.
My initial intention was to keep the original code as much as I can, so in case
of using board files the pdata is set to adxl34x_default_init, but if
DT is used,
memory is allocated and the default parameters are copied. Then in the remove,
only if DT is used free the memory (not included in this patch).
So as I wasn't quite sure if this was the best approach I send this patch to get
some comments. Probably I should send a RFC...
>> dev_dbg(dev,
>> "No platform data: Using default initialization\n");
>> --
>> 1.7.10.4
>>
Thanks again for your time and comments.
Regards,
Walter
--
Walter Lozano, VanguardiaSur
www.vanguardiasur.com.ar
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] HID: hid-sensor-hub: Correct documentation
From: Jiri Kosina @ 2015-01-07 16:27 UTC (permalink / raw)
To: Srinivas Pandruvada
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1420646463.4459.126.camel-hINH/TbAiWppyMZ9rn1DP+ejPoqOX1/hEvhb3Hwu1Ks@public.gmane.org>
On Wed, 7 Jan 2015, Srinivas Pandruvada wrote:
> > Most importantly, you seem to have inter-mixed three patch series (with
> > 4,8 and 9 patches respectively) into one thread, plus there are 4 patches
> > which aren't marked by series numbering. All this is mixed together into
> > one thread without any particular ordering.
> >
> There are 7 series:
> - The four patches, which are single independent patches
> - The others 3 are multiple patches part of series.
What I see this this:
=====
Jan 6 Srinivas Pandruvada (4379) . [PATCH] HID: hid-sensor-hub: Correct documentation
Jan 6 Srinivas Pandruvada (4207) |-[PATCH] HID: sensor-hub: correct dyn_callback_lock IRQ-safe change
Jan 6 Srinivas Pandruvada (5440) |-[PATCH 1/4] HID: hid-sensor-hub: Enhance feature report API
Jan 6 Srinivas Pandruvada (5112) |-[PATCH 2/4] iio: hid_sensor_hub: update parameters to get feature report
Jan 6 Srinivas Pandruvada (5618) |-[PATCH 1/9] HID: hid-sensor-hub: Extend API for async reads
Jan 6 Srinivas Pandruvada (3575) |-[PATCH 2/9] iio: hid-sensor-accel-3d: Adjust parameter for attribute read
Jan 6 Srinivas Pandruvada (5408) |-[PATCH 3/4] HID: hid-sensor-hub: Enhance feature report set API
Jan 6 Srinivas Pandruvada (3561) |-[PATCH 3/9] iio: hid-sensor-gyro-3d: Adjust parameter for attribute read
Jan 6 Srinivas Pandruvada (5306) |-[PATCH 4/4] iio: hid_sensor_hub: update parameters to set feature report
Jan 6 Srinivas Pandruvada (3535) |-[PATCH 4/9] iio: hid-sensor-als: Adjust parameter for attribute read
Jan 6 Srinivas Pandruvada (3544) |-[PATCH 5/9] iio: hid-sensor-prox: Adjust parameter for attribute read
Jan 6 Srinivas Pandruvada (3599) |-[PATCH 6/9] iio: hid-sensor-magn-3d: Adjust parameter for attribute read
Jan 6 Srinivas Pandruvada (3600) |-[PATCH 7/9] iio: hid-sensor-incl-3d: Adjust parameter for attribute read
Jan 6 Srinivas Pandruvada (11K) |-[PATCH] HID: hid-sensor-hub: Allow parallel synchronous reads
Jan 6 Srinivas Pandruvada (3568) |-[PATCH 8/9] iio: hid-sensor-press: Adjust parameter for attribute read
Jan 6 Srinivas Pandruvada (4136) |-[PATCH 3/8] iio: hid-sensor-gyro-3d: Introduce PM
Jan 6 Srinivas Pandruvada (3692) |-[PATCH 9/9] drivers/rtc/rtc-hid-sensor-time.c: Adjust parameter for attribute read
Jan 6 Srinivas Pandruvada (4192) |-[PATCH 4/8] iio: hid-sensor-als: Introduce PM
Jan 6 Srinivas Pandruvada (4162) |-[PATCH 2/8] iio: hid-sensor-accel-3d: Introduce PM
Jan 6 Srinivas Pandruvada (7791) |-[PATCH 1/8] iio: hid_sensor_hub: Common PM functions
Jan 6 Srinivas Pandruvada (4210) |-[PATCH 5/8] iio: hid-sensor-prox: Introduce PM
Jan 6 Srinivas Pandruvada (4161) |-[PATCH 6/8] iio: hid-sensor-magn-3d: Introduce PM
Jan 6 Srinivas Pandruvada (4174) |-[PATCH 7/8] iio: hid-sensor-incl-3d: Introduce PM
Jan 6 Srinivas Pandruvada (4239) |-[PATCH 8/8] iio: hid-sensor-press: Introduce PM
Jan 6 Srinivas Pandruvada (7319) \-[PATCH] HID: hid-sensor-hub: Add collection device
=====
i.e. all the patches from all the seris (and some out of the series) are
referncing just a single e-mail, and that's
1420592328-9942-1-git-send-email-srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
Which is a giant mess.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: hid-sensor-hub: Correct documentation
From: Srinivas Pandruvada @ 2015-01-07 16:35 UTC (permalink / raw)
To: Jiri Kosina
Cc: jic23-DgEjT+Ai2ygdnm+yROfE0A, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <alpine.LNX.2.00.1501071718240.25732-ztGlSCb7Y1iN3ZZ/Hiejyg@public.gmane.org>
On Wed, 2015-01-07 at 17:27 +0100, Jiri Kosina wrote:
> On Wed, 7 Jan 2015, Srinivas Pandruvada wrote:
>
> > > Most importantly, you seem to have inter-mixed three patch series (with
> > > 4,8 and 9 patches respectively) into one thread, plus there are 4 patches
> > > which aren't marked by series numbering. All this is mixed together into
> > > one thread without any particular ordering.
> > >
> > There are 7 series:
> > - The four patches, which are single independent patches
> > - The others 3 are multiple patches part of series.
>
> What I see this this:
>
> =====
> Jan 6 Srinivas Pandruvada (4379) . [PATCH] HID: hid-sensor-hub: Correct documentation
> Jan 6 Srinivas Pandruvada (4207) |-[PATCH] HID: sensor-hub: correct dyn_callback_lock IRQ-safe change
> Jan 6 Srinivas Pandruvada (5440) |-[PATCH 1/4] HID: hid-sensor-hub: Enhance feature report API
> Jan 6 Srinivas Pandruvada (5112) |-[PATCH 2/4] iio: hid_sensor_hub: update parameters to get feature report
> Jan 6 Srinivas Pandruvada (5618) |-[PATCH 1/9] HID: hid-sensor-hub: Extend API for async reads
> Jan 6 Srinivas Pandruvada (3575) |-[PATCH 2/9] iio: hid-sensor-accel-3d: Adjust parameter for attribute read
> Jan 6 Srinivas Pandruvada (5408) |-[PATCH 3/4] HID: hid-sensor-hub: Enhance feature report set API
> Jan 6 Srinivas Pandruvada (3561) |-[PATCH 3/9] iio: hid-sensor-gyro-3d: Adjust parameter for attribute read
> Jan 6 Srinivas Pandruvada (5306) |-[PATCH 4/4] iio: hid_sensor_hub: update parameters to set feature report
> Jan 6 Srinivas Pandruvada (3535) |-[PATCH 4/9] iio: hid-sensor-als: Adjust parameter for attribute read
> Jan 6 Srinivas Pandruvada (3544) |-[PATCH 5/9] iio: hid-sensor-prox: Adjust parameter for attribute read
> Jan 6 Srinivas Pandruvada (3599) |-[PATCH 6/9] iio: hid-sensor-magn-3d: Adjust parameter for attribute read
> Jan 6 Srinivas Pandruvada (3600) |-[PATCH 7/9] iio: hid-sensor-incl-3d: Adjust parameter for attribute read
> Jan 6 Srinivas Pandruvada (11K) |-[PATCH] HID: hid-sensor-hub: Allow parallel synchronous reads
> Jan 6 Srinivas Pandruvada (3568) |-[PATCH 8/9] iio: hid-sensor-press: Adjust parameter for attribute read
> Jan 6 Srinivas Pandruvada (4136) |-[PATCH 3/8] iio: hid-sensor-gyro-3d: Introduce PM
> Jan 6 Srinivas Pandruvada (3692) |-[PATCH 9/9] drivers/rtc/rtc-hid-sensor-time.c: Adjust parameter for attribute read
> Jan 6 Srinivas Pandruvada (4192) |-[PATCH 4/8] iio: hid-sensor-als: Introduce PM
> Jan 6 Srinivas Pandruvada (4162) |-[PATCH 2/8] iio: hid-sensor-accel-3d: Introduce PM
> Jan 6 Srinivas Pandruvada (7791) |-[PATCH 1/8] iio: hid_sensor_hub: Common PM functions
> Jan 6 Srinivas Pandruvada (4210) |-[PATCH 5/8] iio: hid-sensor-prox: Introduce PM
> Jan 6 Srinivas Pandruvada (4161) |-[PATCH 6/8] iio: hid-sensor-magn-3d: Introduce PM
> Jan 6 Srinivas Pandruvada (4174) |-[PATCH 7/8] iio: hid-sensor-incl-3d: Introduce PM
> Jan 6 Srinivas Pandruvada (4239) |-[PATCH 8/8] iio: hid-sensor-press: Introduce PM
> Jan 6 Srinivas Pandruvada (7319) \-[PATCH] HID: hid-sensor-hub: Add collection device
> =====
>
> i.e. all the patches from all the seris (and some out of the series) are
> referncing just a single e-mail, and that's
>
> 1420592328-9942-1-git-send-email-srinivas.pandruvada-VuQAYsv1563Yd54FQh9/CA@public.gmane.org
>
> Which is a giant mess.
I see.
What about I send the 26 patches in a series (1/26 .. 2/26, 3/26...).
This way the ordering is preserved?
Thanks,
Srinivas
>
> --
> Jiri Kosina
> SUSE Labs
^ 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