* Re: [PATCH v2 8/8] Input: olpc_apsp: allocate the GPIOs used
From: Dmitry Torokhov @ 2018-10-10 17:11 UTC (permalink / raw)
To: Lubomir Rintel, Linus Walleij
Cc: Michael Turquette, Rob Herring, Mark Rutland, Stephen Boyd,
James Cameron, linux-input, devicetree, linux-kernel, linux-clk
In-Reply-To: <20181010171013.GD47260@dtor-ws>
On Wed, Oct 10, 2018 at 10:10:13AM -0700, Dmitry Torokhov wrote:
> On Wed, Oct 10, 2018 at 04:25:04PM +0200, Lubomir Rintel wrote:
> > Take the GPIO lines are used by the SP. The driver doesn't touch the
> > lines -- this is done to disallow anything else from fiddling with
> > them because that would confuse the SP firmware.
> >
> > Also, the lines are now nicely visible in /sys/kernel/debug/gpio.
>
> Linus, is this something that should be handled by GPIO "hogs"?
Argh, meant to add Linus Walleij here.
>
> >
> > Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> > ---
> > drivers/input/serio/olpc_apsp.c | 13 +++++++++++++
> > 1 file changed, 13 insertions(+)
> >
> > diff --git a/drivers/input/serio/olpc_apsp.c b/drivers/input/serio/olpc_apsp.c
> > index fe9e19014e70..287759c5f36d 100644
> > --- a/drivers/input/serio/olpc_apsp.c
> > +++ b/drivers/input/serio/olpc_apsp.c
> > @@ -24,6 +24,7 @@
> > #include <linux/slab.h>
> > #include <linux/delay.h>
> > #include <linux/clk.h>
> > +#include <linux/gpio/consumer.h>
> >
> > /*
> > * The OLPC XO-1.75 and XO-4 laptops do not have a hardware PS/2 controller.
> > @@ -76,6 +77,8 @@ struct olpc_apsp {
> > struct serio *padio;
> > void __iomem *base;
> > struct clk *clk;
> > + struct gpio_desc *clk_gpio;
> > + struct gpio_desc *data_gpio;
> > int open_count;
> > int irq;
> > };
> > @@ -211,6 +214,16 @@ static int olpc_apsp_probe(struct platform_device *pdev)
> > if (IS_ERR(priv->clk))
> > return PTR_ERR(priv->clk);
> >
> > + priv->clk_gpio = devm_gpiod_get_optional(&pdev->dev, "clk",
> > + GPIOD_ASIS);
> > + if (IS_ERR(priv->clk_gpio))
> > + return PTR_ERR(priv->clk_gpio);
> > +
> > + priv->data_gpio = devm_gpiod_get_optional(&pdev->dev, "data",
> > + GPIOD_ASIS);
> > + if (IS_ERR(priv->data_gpio))
> > + return PTR_ERR(priv->data_gpio);
> > +
> > /* KEYBOARD */
> > kb_serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
> > if (!kb_serio)
> > --
> > 2.19.0
> >
>
> --
> Dmitry
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2 5/8] Input: olpc_apsp: depend on CONFIG_OF
From: Dmitry Torokhov @ 2018-10-10 17:18 UTC (permalink / raw)
To: Lubomir Rintel
Cc: Michael Turquette, Rob Herring, Mark Rutland, Stephen Boyd,
James Cameron, linux-input, devicetree, linux-kernel, linux-clk
In-Reply-To: <20181010142504.233467-6-lkundrak@v3.sk>
On Wed, Oct 10, 2018 at 04:25:01PM +0200, Lubomir Rintel wrote:
> This is a device-tree enabled driver. Moreover CONFIG_OLPC is specific
> to the x86 platform code, while the driver is for an ARM-based laptop.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
> ---
> drivers/input/serio/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
> index d90d9f1098ff..a4f70021b53e 100644
> --- a/drivers/input/serio/Kconfig
> +++ b/drivers/input/serio/Kconfig
> @@ -254,7 +254,7 @@ config SERIO_APBPS2
>
> config SERIO_OLPC_APSP
> tristate "OLPC AP-SP input support"
> - depends on OLPC || COMPILE_TEST
> + depends on OF
I do not see anything in the driver that depends on OF. If OLPC is not
right dependency, then let's drop the whole depends.
Are you going to be submitting DTS files for the platform?
Thanks.
--
Dmitry
^ permalink raw reply
* [PATCH v2] Input: elants_i2c - Use DMA safe i2c when possible
From: Stephen Boyd @ 2018-10-10 20:00 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-kernel, linux-input, Wolfram Sang
This irq handler is always reading bytes from the device into a
kmalloced buffer, so it's safe to mark this transaction as DMA safe.
This avoids bouncing the buffer when an i2c controller decides to use
DMA for a transaction.
Cc: Wolfram Sang <wsa@the-dreams.de>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
Changes from v1:
* Moved buf to end of structure to keep it cacheline aligned and DMA
safe
drivers/input/touchscreen/elants_i2c.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c
index d21ca39b0fdb..f2cb23121833 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -147,10 +147,11 @@ struct elants_data {
u8 cmd_resp[HEADER_SIZE];
struct completion cmd_done;
- u8 buf[MAX_PACKET_SIZE];
-
bool wake_irq_enabled;
bool keep_power_in_suspend;
+
+ /* Must be last to be used for DMA operations */
+ u8 buf[MAX_PACKET_SIZE] ____cacheline_aligned;
};
static int elants_i2c_send(struct i2c_client *client,
@@ -863,7 +864,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
int i;
int len;
- len = i2c_master_recv(client, ts->buf, sizeof(ts->buf));
+ len = i2c_master_recv_dmasafe(client, ts->buf, sizeof(ts->buf));
if (len < 0) {
dev_err(&client->dev, "%s: failed to read data: %d\n",
__func__, len);
--
Sent by a computer through tubes
^ permalink raw reply related
* [PATCH] HID: wacom: Work around HID descriptor bug in DTK-2451 and DTH-2452
From: Jason Gerecke @ 2018-10-10 20:40 UTC (permalink / raw)
To: linux-input, Jiri Kosina, Benjamin Tissoires, Ping Cheng
Cc: Jason Gerecke, Jason Gerecke, stable
The DTK-2451 and DTH-2452 have a buggy HID descriptor which incorrectly
contains a Cintiq-like report, complete with pen tilt, rotation, twist,
serial number, etc. The hardware doesn't actually support this data but
our driver duitifully sets up the device as though it does. To ensure
userspace has a correct view of devices without updated firmware, we clean
up this incorrect data in wacom_setup_device_quirks.
We're also careful to clear the WACOM_QUIRK_TOOLSERIAL flag since its
presence causes the driver to wait for serial number information (via
wacom_wac_pen_serial_enforce) that never comes, resulting in the pen
being non-responsive.
Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
Fixes: 8341720642 ("HID: wacom: Queue events with missing type/serial data for later processing")
Cc: stable@vger.kernel.org # v4.16+
---
drivers/hid/wacom_wac.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
index e0a06be5ef5c..b4b4a30e3982 100644
--- a/drivers/hid/wacom_wac.c
+++ b/drivers/hid/wacom_wac.c
@@ -3335,6 +3335,7 @@ static void wacom_setup_intuos(struct wacom_wac *wacom_wac)
void wacom_setup_device_quirks(struct wacom *wacom)
{
+ struct wacom_wac *wacom_wac = &wacom->wacom_wac;
struct wacom_features *features = &wacom->wacom_wac.features;
/* The pen and pad share the same interface on most devices */
@@ -3464,6 +3465,25 @@ void wacom_setup_device_quirks(struct wacom *wacom)
if (features->type == REMOTE)
features->device_type |= WACOM_DEVICETYPE_WL_MONITOR;
+
+ /* HID descriptor for DTK-2451 / DTH-2452 claims to report lots
+ * of things it shouldn't. Lets fix up the damage...
+ */
+ if (wacom->hdev->product == 0x382 || wacom->hdev->product == 0x37d) {
+ features->quirks &= ~WACOM_QUIRK_TOOLSERIAL;
+ __clear_bit(BTN_TOOL_BRUSH, wacom_wac->pen_input->keybit);
+ __clear_bit(BTN_TOOL_PENCIL, wacom_wac->pen_input->keybit);
+ __clear_bit(BTN_TOOL_AIRBRUSH, wacom_wac->pen_input->keybit);
+ __clear_bit(ABS_Z, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_DISTANCE, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_TILT_X, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_TILT_Y, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_WHEEL, wacom_wac->pen_input->absbit);
+ __clear_bit(ABS_MISC, wacom_wac->pen_input->absbit);
+ __clear_bit(MSC_SERIAL, wacom_wac->pen_input->mscbit);
+ __clear_bit(EV_MSC, wacom_wac->pen_input->evbit);
+ }
}
int wacom_setup_pen_input_capabilities(struct input_dev *input_dev,
--
2.19.1
^ permalink raw reply related
* Re: [PATCH v2] Input: elants_i2c - Use DMA safe i2c when possible
From: Dmitry Torokhov @ 2018-10-11 0:11 UTC (permalink / raw)
To: Stephen Boyd; +Cc: linux-kernel, linux-input, Wolfram Sang
In-Reply-To: <20181010200017.255874-1-swboyd@chromium.org>
On Wed, Oct 10, 2018 at 01:00:17PM -0700, Stephen Boyd wrote:
> This irq handler is always reading bytes from the device into a
> kmalloced buffer, so it's safe to mark this transaction as DMA safe.
> This avoids bouncing the buffer when an i2c controller decides to use
> DMA for a transaction.
>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Changed patch description a bit (now that we are actually making the
buffer DMA-safe) and applied, thank you.
> ---
>
> Changes from v1:
> * Moved buf to end of structure to keep it cacheline aligned and DMA
> safe
>
> drivers/input/touchscreen/elants_i2c.c | 7 ++++---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c
> index d21ca39b0fdb..f2cb23121833 100644
> --- a/drivers/input/touchscreen/elants_i2c.c
> +++ b/drivers/input/touchscreen/elants_i2c.c
> @@ -147,10 +147,11 @@ struct elants_data {
> u8 cmd_resp[HEADER_SIZE];
> struct completion cmd_done;
>
> - u8 buf[MAX_PACKET_SIZE];
> -
> bool wake_irq_enabled;
> bool keep_power_in_suspend;
> +
> + /* Must be last to be used for DMA operations */
> + u8 buf[MAX_PACKET_SIZE] ____cacheline_aligned;
> };
>
> static int elants_i2c_send(struct i2c_client *client,
> @@ -863,7 +864,7 @@ static irqreturn_t elants_i2c_irq(int irq, void *_dev)
> int i;
> int len;
>
> - len = i2c_master_recv(client, ts->buf, sizeof(ts->buf));
> + len = i2c_master_recv_dmasafe(client, ts->buf, sizeof(ts->buf));
> if (len < 0) {
> dev_err(&client->dev, "%s: failed to read data: %d\n",
> __func__, len);
> --
> Sent by a computer through tubes
>
--
Dmitry
^ permalink raw reply
* Re: [PATCH v2] Input: elants_i2c - Use DMA safe i2c when possible
From: Wolfram Sang @ 2018-10-11 7:29 UTC (permalink / raw)
To: Stephen Boyd; +Cc: Dmitry Torokhov, linux-kernel, linux-input
In-Reply-To: <20181010200017.255874-1-swboyd@chromium.org>
[-- Attachment #1: Type: text/plain, Size: 465 bytes --]
On Wed, Oct 10, 2018 at 01:00:17PM -0700, Stephen Boyd wrote:
> This irq handler is always reading bytes from the device into a
> kmalloced buffer, so it's safe to mark this transaction as DMA safe.
> This avoids bouncing the buffer when an i2c controller decides to use
> DMA for a transaction.
>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
For the record:
Acked-by: Wolfram Sang <wsa@the-dreams.de>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [PATCH] HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2
From: Kai-Heng Feng @ 2018-10-11 7:56 UTC (permalink / raw)
To: jikos; +Cc: benjamin.tissoires, linux-input, linux-kernel, Kai-Heng Feng
Redragon Seymur 2 stops working since commit 190d7f02ce8e ("HID: input:
do not increment usages when a duplicate is found").
Use quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE suggested by the commit
can solve the issue.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
BugLink: https://bugs.launchpad.net/bugs/1793846
Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
---
drivers/hid/hid-ids.h | 1 +
drivers/hid/hid-quirks.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index bc49909aba8e..0e0aa7f0e6fc 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -342,6 +342,7 @@
#define USB_DEVICE_ID_DMI_ENC 0x5fab
#define USB_VENDOR_ID_DRAGONRISE 0x0079
+#define USB_DEVICE_ID_REDRAGON_SEYMUR2 0x0006
#define USB_DEVICE_ID_DRAGONRISE_WIIU 0x1800
#define USB_DEVICE_ID_DRAGONRISE_PS3 0x1801
#define USB_DEVICE_ID_DRAGONRISE_DOLPHINBAR 0x1803
diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
index 249d49b6b16c..52c3b01917e7 100644
--- a/drivers/hid/hid-quirks.c
+++ b/drivers/hid/hid-quirks.c
@@ -70,6 +70,7 @@ static const struct hid_device_id hid_quirks[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC), HID_QUIRK_NOGET },
{ HID_USB_DEVICE(USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES), HID_QUIRK_MULTI_INPUT },
+ { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_REDRAGON_SEYMUR2), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_DOLPHINBAR), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_GAMECUBE1), HID_QUIRK_MULTI_INPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_PS3), HID_QUIRK_MULTI_INPUT },
--
2.17.1
^ permalink raw reply related
* Re: [RFC/PATCH 2/5] device property: introduce notion of subnodes for legacy boards
From: Heikki Krogerus @ 2018-10-11 8:18 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linus Walleij, Rafael J . Wysocki, linux-input, linux-gpio,
linux-kernel, Andy Shevchenko
In-Reply-To: <20181005214734.GC215120@dtor-ws>
Hi Dmitry,
Sorry for the late reply. I decided to give this a try myself, and
I've now prepared something (not for the gpio stuff!). I'll do a quick
internal review round, and send it to you guys as RFC after that..
On Fri, Oct 05, 2018 at 02:47:34PM -0700, Dmitry Torokhov wrote:
> Hi Heikki,
>
> On Tue, Sep 25, 2018 at 03:19:27PM +0300, Heikki Krogerus wrote:
> > On Mon, Sep 24, 2018 at 11:45:43AM -0700, Dmitry Torokhov wrote:
> > > I think we are talking about totally different use cases and that is why
> > > we are having hard time coming to a mutually agreeable solution. Could
> > > you please describe in more detail what you would like to achieve,
> > > and preferably show how it is described now with DT and/or ACPI, so that
> > > I have a better frame of reference.
> >
> > Yes, of course. Sorry.
> >
> > USB ports are devices that usually the USB controller drivers register
> > (or actually the USB core code). They are represented in both ACPI and
> > DT as child nodes of the controller device node. The USB connector OF
> > node is defined in file
> > Documentation/devicetree/bindings/connector/usb-connector.txt
> >
> > In short, the controller drivers will request handle to a child node
> > that represents a port, and only after that register the actual port
> > device.
> >
> > The drivers I'm looking at currently are the USB Type-C port
> > controller drivers and the port manager (in Greg's usb-next or
> > linux-next):
> >
> > drivers/usb/typec/tcpm/tcpci.c
> > drivers/usb/typec/tcpm/fusb302.c
> > drivers/usb/typec/tcpm/tcpm.c
> >
> > The goal is simply to get rid of the platform data as usual, and
> > ideally so that we don't need any extra code in order to support the
> > "legacy" platforms.
>
> Are these actually used on any of the "legacy" platforms? I fetched
> linux-next today, but I do not actually see anything in
> drivers/usb/typec touching platform data...
It's not touching any platform data, and I would like to keep it that
way :-). The device for fusb302 is created for example in
drivers/platform/x86/intel_cht_int33fe.c.
The fusb302.c driver already tries to find that child node named
"connector" (and so do the other port drivers). I'm trying to supply
the driver that node here somehow so I can avoid quirks.
> In the context of the connector, even before we descend to child nodes
> details, how do you propose implementing references between fwnodes?
> Especially since the other node (in case you complementing existing
> topology) may be ACPI or DT instance?
The different fwnode types (ACPI, OF, etc.) must live in parallel,
i.e. you can not have something like ACPI parent node with
property_set children if that's what you mean. The "secondary" member
will link the different types of fwnodes together, but they will live
their separate lives. I'm not planning on changing that.
I'm just looking for a smooth way of describing the devices in
software when the firmware is not supplying the hardware description,
just like you. What I really need is separation of the fwnode
registration from device registration in those cases. For that I now
have a proposal, and I believe my proposal will work for you as a
baseline as well.
Thanks,
--
heikki
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2
From: Benjamin Tissoires @ 2018-10-11 8:34 UTC (permalink / raw)
To: Kai Heng Feng; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <20181011075633.18868-1-kai.heng.feng@canonical.com>
Hi Kai-Heng,
On Thu, Oct 11, 2018 at 9:56 AM Kai-Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
> Redragon Seymur 2 stops working since commit 190d7f02ce8e ("HID: input:
> do not increment usages when a duplicate is found").
>
> Use quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE suggested by the commit
> can solve the issue.
Before we take the hammer, could you share the report descriptors (or
I'll request those in the kernel BZ)?
In the kernel BZ, it's clear that the report descriptor is wrong at
assigning axes, but I'd like to double check if applying the quirk
will be OK and will not pollute other axes.
Cheers,
Benjamin
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
> BugLink: https://bugs.launchpad.net/bugs/1793846
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> ---
> drivers/hid/hid-ids.h | 1 +
> drivers/hid/hid-quirks.c | 1 +
> 2 files changed, 2 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index bc49909aba8e..0e0aa7f0e6fc 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -342,6 +342,7 @@
> #define USB_DEVICE_ID_DMI_ENC 0x5fab
>
> #define USB_VENDOR_ID_DRAGONRISE 0x0079
> +#define USB_DEVICE_ID_REDRAGON_SEYMUR2 0x0006
> #define USB_DEVICE_ID_DRAGONRISE_WIIU 0x1800
> #define USB_DEVICE_ID_DRAGONRISE_PS3 0x1801
> #define USB_DEVICE_ID_DRAGONRISE_DOLPHINBAR 0x1803
> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> index 249d49b6b16c..52c3b01917e7 100644
> --- a/drivers/hid/hid-quirks.c
> +++ b/drivers/hid/hid-quirks.c
> @@ -70,6 +70,7 @@ static const struct hid_device_id hid_quirks[] = {
> { HID_USB_DEVICE(USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC), HID_QUIRK_NOGET },
> { HID_USB_DEVICE(USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES), HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES), HID_QUIRK_MULTI_INPUT },
> + { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_REDRAGON_SEYMUR2), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_DOLPHINBAR), HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_GAMECUBE1), HID_QUIRK_MULTI_INPUT },
> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_PS3), HID_QUIRK_MULTI_INPUT },
> --
> 2.17.1
>
^ permalink raw reply
* Re: [PATCH v2 8/8] Input: olpc_apsp: allocate the GPIOs used
From: Linus Walleij @ 2018-10-11 8:38 UTC (permalink / raw)
To: lkundrak, Stephen Boyd, Ricardo Ribalda Delgado, Andy Shevchenko
Cc: Dmitry Torokhov, Michael Turquette, Rob Herring, Mark Rutland,
Stephen Boyd, quozl, Linux Input,
open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS,
linux-kernel@vger.kernel.org, linux-clk
In-Reply-To: <20181010142504.233467-9-lkundrak@v3.sk>
Hi Lubomir,
thanks for your patch!
On Wed, Oct 10, 2018 at 4:26 PM Lubomir Rintel <lkundrak@v3.sk> wrote:
> Take the GPIO lines are used by the SP. The driver doesn't touch the
> lines -- this is done to disallow anything else from fiddling with
> them because that would confuse the SP firmware.
>
> Also, the lines are now nicely visible in /sys/kernel/debug/gpio.
>
> Signed-off-by: Lubomir Rintel <lkundrak@v3.sk>
Sadly I do not think this is the right way to do this these days.
In the past I would have agreed.
A few months back, Qualcomm engineers working on ACPI
support ran into similar issues: there were GPIO lines that
could not be touched by the kernel because they were used
by firmware (BIOS).
The solution we devised can be seen in
commit 726cb3ba49692bdae6caff457755e7cdb432efa4
"gpiolib: Support 'gpio-reserved-ranges' property"
which adds a "valid mask" to struct gpio_chip.
It is further refined in the lates working kernel code to make
it easy for users to set up a custom valid_mask.
https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio.git/commit/?h=devel&id=f8ec92a9f63b3b11e399409141b7868bb405e6b5
So what you should do is modify the platform set-up for
the OLPC to mask off these GPIO lines as invalid since
they are used by the firmware and Linux should not touch
them.
Sadly I don't know which GPIO driver the XO1 is using,
but if you tell us I bet me or Andy will be able to help you
out in finding the right spot to patch.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2
From: Kai Heng Feng @ 2018-10-11 9:16 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <CAO-hwJJkB=u44_kJNjOSL=8pgnXDkvda12_g8p39DeZ0JybqWQ@mail.gmail.com>
Hi Benjamin,
> On Oct 11, 2018, at 16:34, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
>
> Hi Kai-Heng,
>
> On Thu, Oct 11, 2018 at 9:56 AM Kai-Heng Feng
> <kai.heng.feng@canonical.com> wrote:
>>
>> Redragon Seymur 2 stops working since commit 190d7f02ce8e ("HID: input:
>> do not increment usages when a duplicate is found").
>>
>> Use quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE suggested by the commit
>> can solve the issue.
>
> Before we take the hammer, could you share the report descriptors (or
> I'll request those in the kernel BZ)?
Feel free to do so!
I send the patch because seems like the user doesn’t know how to upstream patches.
Kai-Heng
> In the kernel BZ, it's clear that the report descriptor is wrong at
> assigning axes, but I'd like to double check if applying the quirk
> will be OK and will not pollute other axes.
>
> Cheers,
> Benjamin
>
>>
>> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
>> BugLink: https://bugs.launchpad.net/bugs/1793846
>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>> ---
>> drivers/hid/hid-ids.h | 1 +
>> drivers/hid/hid-quirks.c | 1 +
>> 2 files changed, 2 insertions(+)
>>
>> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
>> index bc49909aba8e..0e0aa7f0e6fc 100644
>> --- a/drivers/hid/hid-ids.h
>> +++ b/drivers/hid/hid-ids.h
>> @@ -342,6 +342,7 @@
>> #define USB_DEVICE_ID_DMI_ENC 0x5fab
>>
>> #define USB_VENDOR_ID_DRAGONRISE 0x0079
>> +#define USB_DEVICE_ID_REDRAGON_SEYMUR2 0x0006
>> #define USB_DEVICE_ID_DRAGONRISE_WIIU 0x1800
>> #define USB_DEVICE_ID_DRAGONRISE_PS3 0x1801
>> #define USB_DEVICE_ID_DRAGONRISE_DOLPHINBAR 0x1803
>> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
>> index 249d49b6b16c..52c3b01917e7 100644
>> --- a/drivers/hid/hid-quirks.c
>> +++ b/drivers/hid/hid-quirks.c
>> @@ -70,6 +70,7 @@ static const struct hid_device_id hid_quirks[] = {
>> { HID_USB_DEVICE(USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC), HID_QUIRK_NOGET },
>> { HID_USB_DEVICE(USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES), HID_QUIRK_MULTI_INPUT },
>> { HID_USB_DEVICE(USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES), HID_QUIRK_MULTI_INPUT },
>> + { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_REDRAGON_SEYMUR2), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
>> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_DOLPHINBAR), HID_QUIRK_MULTI_INPUT },
>> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_GAMECUBE1), HID_QUIRK_MULTI_INPUT },
>> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_PS3), HID_QUIRK_MULTI_INPUT },
>> --
>> 2.17.1
>>
^ permalink raw reply
* Re: [PATCH] HID: wacom: Work around HID descriptor bug in DTK-2451 and DTH-2452
From: Jiri Kosina @ 2018-10-11 12:33 UTC (permalink / raw)
To: Jason Gerecke
Cc: linux-input, Benjamin Tissoires, Ping Cheng, Jason Gerecke,
stable
In-Reply-To: <20181010204026.4555-1-killertofu@gmail.com>
On Wed, 10 Oct 2018, Jason Gerecke wrote:
> The DTK-2451 and DTH-2452 have a buggy HID descriptor which incorrectly
> contains a Cintiq-like report, complete with pen tilt, rotation, twist,
> serial number, etc. The hardware doesn't actually support this data but
> our driver duitifully sets up the device as though it does. To ensure
> userspace has a correct view of devices without updated firmware, we clean
> up this incorrect data in wacom_setup_device_quirks.
>
> We're also careful to clear the WACOM_QUIRK_TOOLSERIAL flag since its
> presence causes the driver to wait for serial number information (via
> wacom_wac_pen_serial_enforce) that never comes, resulting in the pen
> being non-responsive.
>
> Signed-off-by: Jason Gerecke <jason.gerecke@wacom.com>
> Fixes: 8341720642 ("HID: wacom: Queue events with missing type/serial data for later processing")
> Cc: stable@vger.kernel.org # v4.16+
> ---
> drivers/hid/wacom_wac.c | 20 ++++++++++++++++++++
> 1 file changed, 20 insertions(+)
>
> diff --git a/drivers/hid/wacom_wac.c b/drivers/hid/wacom_wac.c
> index e0a06be5ef5c..b4b4a30e3982 100644
> --- a/drivers/hid/wacom_wac.c
> +++ b/drivers/hid/wacom_wac.c
> @@ -3335,6 +3335,7 @@ static void wacom_setup_intuos(struct wacom_wac *wacom_wac)
>
> void wacom_setup_device_quirks(struct wacom *wacom)
> {
> + struct wacom_wac *wacom_wac = &wacom->wacom_wac;
> struct wacom_features *features = &wacom->wacom_wac.features;
>
> /* The pen and pad share the same interface on most devices */
> @@ -3464,6 +3465,25 @@ void wacom_setup_device_quirks(struct wacom *wacom)
>
> if (features->type == REMOTE)
> features->device_type |= WACOM_DEVICETYPE_WL_MONITOR;
> +
> + /* HID descriptor for DTK-2451 / DTH-2452 claims to report lots
> + * of things it shouldn't. Lets fix up the damage...
> + */
> + if (wacom->hdev->product == 0x382 || wacom->hdev->product == 0x37d) {
> + features->quirks &= ~WACOM_QUIRK_TOOLSERIAL;
> + __clear_bit(BTN_TOOL_BRUSH, wacom_wac->pen_input->keybit);
> + __clear_bit(BTN_TOOL_PENCIL, wacom_wac->pen_input->keybit);
> + __clear_bit(BTN_TOOL_AIRBRUSH, wacom_wac->pen_input->keybit);
> + __clear_bit(ABS_Z, wacom_wac->pen_input->absbit);
> + __clear_bit(ABS_DISTANCE, wacom_wac->pen_input->absbit);
> + __clear_bit(ABS_TILT_X, wacom_wac->pen_input->absbit);
> + __clear_bit(ABS_TILT_Y, wacom_wac->pen_input->absbit);
> + __clear_bit(ABS_WHEEL, wacom_wac->pen_input->absbit);
> + __clear_bit(ABS_MISC, wacom_wac->pen_input->absbit);
> + __clear_bit(MSC_SERIAL, wacom_wac->pen_input->mscbit);
> + __clear_bit(EV_MSC, wacom_wac->pen_input->evbit);
> + }
> }
>
> int wacom_setup_pen_input_capabilities(struct input_dev *input_dev,
I don't know how you did it (I can't spot anything wrong there), but both
git and patch complain about this line when trying to apply the patch :)
Anyway, I've applied it "manually" to for-4.19/fixes branch. Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2
From: Benjamin Tissoires @ 2018-10-11 15:02 UTC (permalink / raw)
To: Kai Heng Feng; +Cc: Jiri Kosina, open list:HID CORE LAYER, lkml
In-Reply-To: <3941E373-A385-4080-ADCC-BAEBC862809A@canonical.com>
On Thu, Oct 11, 2018 at 11:16 AM Kai Heng Feng
<kai.heng.feng@canonical.com> wrote:
>
> Hi Benjamin,
>
> > On Oct 11, 2018, at 16:34, Benjamin Tissoires <benjamin.tissoires@redhat.com> wrote:
> >
> > Hi Kai-Heng,
> >
> > On Thu, Oct 11, 2018 at 9:56 AM Kai-Heng Feng
> > <kai.heng.feng@canonical.com> wrote:
> >>
> >> Redragon Seymur 2 stops working since commit 190d7f02ce8e ("HID: input:
> >> do not increment usages when a duplicate is found").
> >>
> >> Use quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE suggested by the commit
> >> can solve the issue.
> >
> > Before we take the hammer, could you share the report descriptors (or
> > I'll request those in the kernel BZ)?
>
> Feel free to do so!
>
> I send the patch because seems like the user doesn’t know how to upstream patches.
Heh, no worries :)
So, after a review of the report descriptors:
Reviewed-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
(In this case, adding the quirk is the easiest solution and it has no
side effects)
Cheers,
Benjamin
>
> Kai-Heng
>
> > In the kernel BZ, it's clear that the report descriptor is wrong at
> > assigning axes, but I'd like to double check if applying the quirk
> > will be OK and will not pollute other axes.
> >
> > Cheers,
> > Benjamin
> >
> >>
> >> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
> >> BugLink: https://bugs.launchpad.net/bugs/1793846
> >> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
> >> ---
> >> drivers/hid/hid-ids.h | 1 +
> >> drivers/hid/hid-quirks.c | 1 +
> >> 2 files changed, 2 insertions(+)
> >>
> >> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> >> index bc49909aba8e..0e0aa7f0e6fc 100644
> >> --- a/drivers/hid/hid-ids.h
> >> +++ b/drivers/hid/hid-ids.h
> >> @@ -342,6 +342,7 @@
> >> #define USB_DEVICE_ID_DMI_ENC 0x5fab
> >>
> >> #define USB_VENDOR_ID_DRAGONRISE 0x0079
> >> +#define USB_DEVICE_ID_REDRAGON_SEYMUR2 0x0006
> >> #define USB_DEVICE_ID_DRAGONRISE_WIIU 0x1800
> >> #define USB_DEVICE_ID_DRAGONRISE_PS3 0x1801
> >> #define USB_DEVICE_ID_DRAGONRISE_DOLPHINBAR 0x1803
> >> diff --git a/drivers/hid/hid-quirks.c b/drivers/hid/hid-quirks.c
> >> index 249d49b6b16c..52c3b01917e7 100644
> >> --- a/drivers/hid/hid-quirks.c
> >> +++ b/drivers/hid/hid-quirks.c
> >> @@ -70,6 +70,7 @@ static const struct hid_device_id hid_quirks[] = {
> >> { HID_USB_DEVICE(USB_VENDOR_ID_DMI, USB_DEVICE_ID_DMI_ENC), HID_QUIRK_NOGET },
> >> { HID_USB_DEVICE(USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_2NES2SNES), HID_QUIRK_MULTI_INPUT },
> >> { HID_USB_DEVICE(USB_VENDOR_ID_DRACAL_RAPHNET, USB_DEVICE_ID_RAPHNET_4NES4SNES), HID_QUIRK_MULTI_INPUT },
> >> + { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_REDRAGON_SEYMUR2), HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE },
> >> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_DOLPHINBAR), HID_QUIRK_MULTI_INPUT },
> >> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_GAMECUBE1), HID_QUIRK_MULTI_INPUT },
> >> { HID_USB_DEVICE(USB_VENDOR_ID_DRAGONRISE, USB_DEVICE_ID_DRAGONRISE_PS3), HID_QUIRK_MULTI_INPUT },
> >> --
> >> 2.17.1
> >>
>
^ permalink raw reply
* Re: [PATCH] HID: usbhid: Add quirk for Redragon/Dragonrise Seymur 2
From: Jiri Kosina @ 2018-10-11 20:03 UTC (permalink / raw)
To: Kai-Heng Feng; +Cc: benjamin.tissoires, linux-input, linux-kernel
In-Reply-To: <20181011075633.18868-1-kai.heng.feng@canonical.com>
On Thu, 11 Oct 2018, Kai-Heng Feng wrote:
> Redragon Seymur 2 stops working since commit 190d7f02ce8e ("HID: input:
> do not increment usages when a duplicate is found").
>
> Use quirk HID_QUIRK_INCREMENT_USAGE_ON_DUPLICATE suggested by the commit
> can solve the issue.
>
> Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=200995
> BugLink: https://bugs.launchpad.net/bugs/1793846
> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
Applied, thanks.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [git pull] Input updates for v4.19-rc7
From: Dmitry Torokhov @ 2018-10-11 23:57 UTC (permalink / raw)
To: Greg KH; +Cc: Linus Torvalds, linux-kernel, linux-input
Hi Greg,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem:
- we added a few scheduling points into various input interfaces to
ensure that large writes will not cause RCU stalls
- fixed configuring PS/2 keyboards as wakeup devices on newer platforms
- added a new Xbox gamepad ID.
Changelog:
---------
Daniel Drake (1):
Input: i8042 - enable keyboard wakeups by default when s2idle is used
Dmitry Torokhov (2):
Input: evdev - add a schedule point in evdev_write()
Input: uinput - add a schedule point in uinput_inject_events()
Eric Dumazet (1):
Input: mousedev - add a schedule point in mousedev_write()
Ramses Ramírez (1):
Input: xpad - add support for Xbox1 PDP Camo series gamepad
Diffstat:
--------
drivers/input/evdev.c | 1 +
drivers/input/joystick/xpad.c | 3 +++
drivers/input/misc/uinput.c | 1 +
drivers/input/mousedev.c | 1 +
drivers/input/serio/i8042.c | 29 ++++++++++++++++++++---------
include/linux/suspend.h | 2 ++
kernel/power/suspend.c | 6 ++++++
7 files changed, 34 insertions(+), 9 deletions(-)
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [git pull] Input updates for v4.19-rc7
From: Greg KH @ 2018-10-12 10:51 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Linus Torvalds, linux-kernel, linux-input
In-Reply-To: <20181011235736.GA68543@dtor-ws>
On Thu, Oct 11, 2018 at 04:57:36PM -0700, Dmitry Torokhov wrote:
> Hi Greg,
>
> Please pull from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
>
> to receive updates for the input subsystem:
>
> - we added a few scheduling points into various input interfaces to
> ensure that large writes will not cause RCU stalls
>
> - fixed configuring PS/2 keyboards as wakeup devices on newer platforms
That feels like a really "late" contribution, I hope it goes well :)
Now merged, thanks.
greg k-h
^ permalink raw reply
* [PATCH] HID: alps: allow incoming reports when only the trackstick is opened
From: Benjamin Tissoires @ 2018-10-12 14:05 UTC (permalink / raw)
To: Jiri Kosina, Masaki Ota; +Cc: linux-input, linux-kernel, Benjamin Tissoires
If userspace only reads the trackstick node, and no one is listening to
the touchpad nor the hidraw node then, the device is not powered on.
Add open/close callbacks to allow users to disable the touchpad in Gnome
while keeping the trackstick active.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1559632
Link: https://gitlab.gnome.org/GNOME/mutter/issues/128
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/hid/hid-alps.c | 18 ++++++++++++++++++
1 file changed, 18 insertions(+)
diff --git a/drivers/hid/hid-alps.c b/drivers/hid/hid-alps.c
index aec253b44156..3cd7229b6e54 100644
--- a/drivers/hid/hid-alps.c
+++ b/drivers/hid/hid-alps.c
@@ -660,6 +660,20 @@ static int T4_init(struct hid_device *hdev, struct alps_dev *pri_data)
return ret;
}
+static int alps_sp_open(struct input_dev *dev)
+{
+ struct hid_device *hid = input_get_drvdata(dev);
+
+ return hid_hw_open(hid);
+}
+
+static void alps_sp_close(struct input_dev *dev)
+{
+ struct hid_device *hid = input_get_drvdata(dev);
+
+ hid_hw_close(hid);
+}
+
static int alps_input_configured(struct hid_device *hdev, struct hid_input *hi)
{
struct alps_dev *data = hid_get_drvdata(hdev);
@@ -733,6 +747,10 @@ static int alps_input_configured(struct hid_device *hdev, struct hid_input *hi)
input2->id.version = input->id.version;
input2->dev.parent = input->dev.parent;
+ input_set_drvdata(input2, hdev);
+ input2->open = alps_sp_open;
+ input2->close = alps_sp_close;
+
__set_bit(EV_KEY, input2->evbit);
data->sp_btn_cnt = (data->sp_btn_info & 0x0F);
for (i = 0; i < data->sp_btn_cnt; i++)
--
2.14.3
^ permalink raw reply related
* [PATCH 0/5] Fix Elan I2C touchpads in latest generation from Lenovo
From: Benjamin Tissoires @ 2018-10-12 14:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: KT Liao, Rob Herring, linux-input, linux-kernel, devicetree,
Benjamin Tissoires
Since v4.18, we unconditionally switch the I2C capable touchpads over I2C.
In the model I had (a pre-prod t480s I guess), the touchpad was behaving
fine.
However, it occurs that later production models don't expose the clickpad
information from I2C. The Windows driver gets all the information from PS/2
so we should do the same.
The situation is even worse for the P52. Once of the query parameter function
fails, which means the touchpad doesn't even probe. This effectively kills
the touchpad, which is less than ideal.
Dmitry, I am not sure if we should take those for stable in v4.18+.
I'd like to, but given the series is 5 patches, I don't know if this
will be acceptable.
We could revert in stable df077237cf55928f5 but that would mean
distributions will have to revert the revert if they want to provide
the I2C behavior.
So, regarding stable: your call :)
Cheers,
Benjamin
Benjamin Tissoires (5):
Input: elantech - query the min/max information beforehand too
Input: elantech - add helper function elantech_is_buttonpad()
dt-bindings: add more optional properties for elan_i2c touchpads
Input: elan_i2c - do not query the info if they are provided
Input: elantech/SMBus - export all capabilities from the PS/2 node
.../devicetree/bindings/input/elan_i2c.txt | 8 +
drivers/input/mouse/elan_i2c_core.c | 49 +++-
drivers/input/mouse/elantech.c | 272 +++++++++++----------
drivers/input/mouse/elantech.h | 5 +
4 files changed, 188 insertions(+), 146 deletions(-)
--
2.14.3
^ permalink raw reply
* [PATCH 1/5] Input: elantech - query the min/max information beforehand too
From: Benjamin Tissoires @ 2018-10-12 14:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: KT Liao, Rob Herring, linux-input, linux-kernel, devicetree,
Benjamin Tissoires
In-Reply-To: <20181012142413.26107-1-benjamin.tissoires@redhat.com>
For the latest generation of Elantech touchpads, we need to forward
the min/max information from PS/2 to SMBus. Prepare this work
by fetching the information before creating the SMBus companion
device.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1628715
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/mouse/elantech.c | 160 +++++++++++++++++++----------------------
drivers/input/mouse/elantech.h | 5 ++
2 files changed, 79 insertions(+), 86 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 2d95e8d93cc7..577c795cbe82 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -994,88 +994,6 @@ static int elantech_set_absolute_mode(struct psmouse *psmouse)
return rc;
}
-static int elantech_set_range(struct psmouse *psmouse,
- unsigned int *x_min, unsigned int *y_min,
- unsigned int *x_max, unsigned int *y_max,
- unsigned int *width)
-{
- struct elantech_data *etd = psmouse->private;
- struct elantech_device_info *info = &etd->info;
- unsigned char param[3];
- unsigned char traces;
-
- switch (info->hw_version) {
- case 1:
- *x_min = ETP_XMIN_V1;
- *y_min = ETP_YMIN_V1;
- *x_max = ETP_XMAX_V1;
- *y_max = ETP_YMAX_V1;
- break;
-
- case 2:
- if (info->fw_version == 0x020800 ||
- info->fw_version == 0x020b00 ||
- info->fw_version == 0x020030) {
- *x_min = ETP_XMIN_V2;
- *y_min = ETP_YMIN_V2;
- *x_max = ETP_XMAX_V2;
- *y_max = ETP_YMAX_V2;
- } else {
- int i;
- int fixed_dpi;
-
- i = (info->fw_version > 0x020800 &&
- info->fw_version < 0x020900) ? 1 : 2;
-
- if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
- return -1;
-
- fixed_dpi = param[1] & 0x10;
-
- if (((info->fw_version >> 16) == 0x14) && fixed_dpi) {
- if (info->send_cmd(psmouse, ETP_SAMPLE_QUERY, param))
- return -1;
-
- *x_max = (info->capabilities[1] - i) * param[1] / 2;
- *y_max = (info->capabilities[2] - i) * param[2] / 2;
- } else if (info->fw_version == 0x040216) {
- *x_max = 819;
- *y_max = 405;
- } else if (info->fw_version == 0x040219 || info->fw_version == 0x040215) {
- *x_max = 900;
- *y_max = 500;
- } else {
- *x_max = (info->capabilities[1] - i) * 64;
- *y_max = (info->capabilities[2] - i) * 64;
- }
- }
- break;
-
- case 3:
- if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
- return -1;
-
- *x_max = (0x0f & param[0]) << 8 | param[1];
- *y_max = (0xf0 & param[0]) << 4 | param[2];
- break;
-
- case 4:
- if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
- return -1;
-
- *x_max = (0x0f & param[0]) << 8 | param[1];
- *y_max = (0xf0 & param[0]) << 4 | param[2];
- traces = info->capabilities[1];
- if ((traces < 2) || (traces > *x_max))
- return -1;
-
- *width = *x_max / (traces - 1);
- break;
- }
-
- return 0;
-}
-
/*
* (value from firmware) * 10 + 790 = dpi
* we also have to convert dpi to dots/mm (*10/254 to avoid floating point)
@@ -1191,10 +1109,9 @@ static int elantech_set_input_params(struct psmouse *psmouse)
struct input_dev *dev = psmouse->dev;
struct elantech_data *etd = psmouse->private;
struct elantech_device_info *info = &etd->info;
- unsigned int x_min = 0, y_min = 0, x_max = 0, y_max = 0, width = 0;
-
- if (elantech_set_range(psmouse, &x_min, &y_min, &x_max, &y_max, &width))
- return -1;
+ unsigned int x_min = info->x_min, y_min = info->y_min,
+ x_max = info->x_max, y_max = info->y_max,
+ width = info->width;
__set_bit(INPUT_PROP_POINTER, dev->propbit);
__set_bit(EV_KEY, dev->evbit);
@@ -1678,6 +1595,7 @@ static int elantech_query_info(struct psmouse *psmouse,
struct elantech_device_info *info)
{
unsigned char param[3];
+ unsigned char traces;
memset(info, 0, sizeof(*info));
@@ -1746,6 +1664,76 @@ static int elantech_query_info(struct psmouse *psmouse,
}
}
+ /* query range information */
+ switch (info->hw_version) {
+ case 1:
+ info->x_min = ETP_XMIN_V1;
+ info->y_min = ETP_YMIN_V1;
+ info->x_max = ETP_XMAX_V1;
+ info->y_max = ETP_YMAX_V1;
+ break;
+
+ case 2:
+ if (info->fw_version == 0x020800 ||
+ info->fw_version == 0x020b00 ||
+ info->fw_version == 0x020030) {
+ info->x_min = ETP_XMIN_V2;
+ info->y_min = ETP_YMIN_V2;
+ info->x_max = ETP_XMAX_V2;
+ info->y_max = ETP_YMAX_V2;
+ } else {
+ int i;
+ int fixed_dpi;
+
+ i = (info->fw_version > 0x020800 &&
+ info->fw_version < 0x020900) ? 1 : 2;
+
+ if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
+ return -EINVAL;
+
+ fixed_dpi = param[1] & 0x10;
+
+ if (((info->fw_version >> 16) == 0x14) && fixed_dpi) {
+ if (info->send_cmd(psmouse, ETP_SAMPLE_QUERY, param))
+ return -EINVAL;
+
+ info->x_max = (info->capabilities[1] - i) * param[1] / 2;
+ info->y_max = (info->capabilities[2] - i) * param[2] / 2;
+ } else if (info->fw_version == 0x040216) {
+ info->x_max = 819;
+ info->y_max = 405;
+ } else if (info->fw_version == 0x040219 || info->fw_version == 0x040215) {
+ info->x_max = 900;
+ info->y_max = 500;
+ } else {
+ info->x_max = (info->capabilities[1] - i) * 64;
+ info->y_max = (info->capabilities[2] - i) * 64;
+ }
+ }
+ break;
+
+ case 3:
+ if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
+ return -EINVAL;
+
+ info->x_max = (0x0f & param[0]) << 8 | param[1];
+ info->y_max = (0xf0 & param[0]) << 4 | param[2];
+ break;
+
+ case 4:
+ if (info->send_cmd(psmouse, ETP_FW_ID_QUERY, param))
+ return -EINVAL;
+
+ info->x_max = (0x0f & param[0]) << 8 | param[1];
+ info->y_max = (0xf0 & param[0]) << 4 | param[2];
+ traces = info->capabilities[1];
+ if ((traces < 2) || (traces > info->x_max))
+ return -EINVAL;
+
+ info->width = info->x_max / (traces - 1);
+ break;
+ }
+
return 0;
}
diff --git a/drivers/input/mouse/elantech.h b/drivers/input/mouse/elantech.h
index 119727085a60..194503ed59c5 100644
--- a/drivers/input/mouse/elantech.h
+++ b/drivers/input/mouse/elantech.h
@@ -144,8 +144,13 @@ struct elantech_device_info {
unsigned char debug;
unsigned char hw_version;
unsigned int fw_version;
+ unsigned int x_min;
+ unsigned int y_min;
+ unsigned int x_max;
+ unsigned int y_max;
unsigned int x_res;
unsigned int y_res;
+ unsigned int width;
unsigned int bus;
bool paritycheck;
bool jumpy_cursor;
--
2.14.3
^ permalink raw reply related
* [PATCH 2/5] Input: elantech - add helper function elantech_is_buttonpad()
From: Benjamin Tissoires @ 2018-10-12 14:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: KT Liao, Rob Herring, linux-input, linux-kernel, devicetree,
Benjamin Tissoires
In-Reply-To: <20181012142413.26107-1-benjamin.tissoires@redhat.com>
We check for this bit all over the code, better have it defined once
for all.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1628715
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/mouse/elantech.c | 89 ++++++++++++++++++++++--------------------
1 file changed, 47 insertions(+), 42 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 577c795cbe82..78ac732e8188 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -229,6 +229,50 @@ static void elantech_packet_dump(struct psmouse *psmouse)
psmouse->pktsize, psmouse->packet);
}
+/*
+ * Advertise INPUT_PROP_BUTTONPAD for clickpads. The testing of bit 12 in
+ * fw_version for this is based on the following fw_version & caps table:
+ *
+ * Laptop-model: fw_version: caps: buttons:
+ * Acer S3 0x461f00 10, 13, 0e clickpad
+ * Acer S7-392 0x581f01 50, 17, 0d clickpad
+ * Acer V5-131 0x461f02 01, 16, 0c clickpad
+ * Acer V5-551 0x461f00 ? clickpad
+ * Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
+ * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
+ * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
+ * Asus TP500LN 0x381f17 10, 14, 0e clickpad
+ * Asus X750JN 0x381f17 10, 14, 0e clickpad
+ * Asus UX31 0x361f00 20, 15, 0e clickpad
+ * Asus UX32VD 0x361f02 00, 15, 0e clickpad
+ * Avatar AVIU-145A2 0x361f00 ? clickpad
+ * Fujitsu LIFEBOOK E544 0x470f00 d0, 12, 09 2 hw buttons
+ * Fujitsu LIFEBOOK E546 0x470f00 50, 12, 09 2 hw buttons
+ * Fujitsu LIFEBOOK E547 0x470f00 50, 12, 09 2 hw buttons
+ * Fujitsu LIFEBOOK E554 0x570f01 40, 14, 0c 2 hw buttons
+ * Fujitsu LIFEBOOK E557 0x570f01 40, 14, 0c 2 hw buttons
+ * Fujitsu T725 0x470f01 05, 12, 09 2 hw buttons
+ * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**)
+ * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
+ * Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons (*)
+ * Lenovo L530 0x350f02 b9, 15, 0c 2 hw buttons (*)
+ * Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
+ * Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
+ * Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
+ * Samsung NP900X3E-A02 0x575f03 ? clickpad
+ * Samsung NP-QX410 0x851b00 19, 14, 0c clickpad
+ * Samsung RC512 0x450f00 08, 15, 0c 2 hw buttons
+ * Samsung RF710 0x450f00 ? 2 hw buttons
+ * System76 Pangolin 0x250f01 ? 2 hw buttons
+ * (*) + 3 trackpoint buttons
+ * (**) + 0 trackpoint buttons
+ * Note: Lenovo L430 and Lenovo L530 have the same fw_version/caps
+ */
+static inline int elantech_is_buttonpad(struct elantech_device_info *info)
+{
+ return info->fw_version & 0x001000;
+}
+
/*
* Interpret complete data packets and report absolute mode input events for
* hardware version 1. (4 byte packets)
@@ -526,7 +570,7 @@ static void elantech_report_absolute_v3(struct psmouse *psmouse,
input_report_key(dev, BTN_TOOL_TRIPLETAP, fingers == 3);
/* For clickpads map both buttons to BTN_LEFT */
- if (etd->info.fw_version & 0x001000)
+ if (elantech_is_buttonpad(&etd->info))
input_report_key(dev, BTN_LEFT, packet[0] & 0x03);
else
psmouse_report_standard_buttons(dev, packet[0]);
@@ -544,7 +588,7 @@ static void elantech_input_sync_v4(struct psmouse *psmouse)
unsigned char *packet = psmouse->packet;
/* For clickpads map both buttons to BTN_LEFT */
- if (etd->info.fw_version & 0x001000)
+ if (elantech_is_buttonpad(&etd->info))
input_report_key(dev, BTN_LEFT, packet[0] & 0x03);
else
psmouse_report_standard_buttons(dev, packet[0]);
@@ -1020,51 +1064,12 @@ static int elantech_get_resolution_v4(struct psmouse *psmouse,
return 0;
}
-/*
- * Advertise INPUT_PROP_BUTTONPAD for clickpads. The testing of bit 12 in
- * fw_version for this is based on the following fw_version & caps table:
- *
- * Laptop-model: fw_version: caps: buttons:
- * Acer S3 0x461f00 10, 13, 0e clickpad
- * Acer S7-392 0x581f01 50, 17, 0d clickpad
- * Acer V5-131 0x461f02 01, 16, 0c clickpad
- * Acer V5-551 0x461f00 ? clickpad
- * Asus K53SV 0x450f01 78, 15, 0c 2 hw buttons
- * Asus G46VW 0x460f02 00, 18, 0c 2 hw buttons
- * Asus G750JX 0x360f00 00, 16, 0c 2 hw buttons
- * Asus TP500LN 0x381f17 10, 14, 0e clickpad
- * Asus X750JN 0x381f17 10, 14, 0e clickpad
- * Asus UX31 0x361f00 20, 15, 0e clickpad
- * Asus UX32VD 0x361f02 00, 15, 0e clickpad
- * Avatar AVIU-145A2 0x361f00 ? clickpad
- * Fujitsu LIFEBOOK E544 0x470f00 d0, 12, 09 2 hw buttons
- * Fujitsu LIFEBOOK E546 0x470f00 50, 12, 09 2 hw buttons
- * Fujitsu LIFEBOOK E547 0x470f00 50, 12, 09 2 hw buttons
- * Fujitsu LIFEBOOK E554 0x570f01 40, 14, 0c 2 hw buttons
- * Fujitsu LIFEBOOK E557 0x570f01 40, 14, 0c 2 hw buttons
- * Fujitsu T725 0x470f01 05, 12, 09 2 hw buttons
- * Fujitsu H730 0x570f00 c0, 14, 0c 3 hw buttons (**)
- * Gigabyte U2442 0x450f01 58, 17, 0c 2 hw buttons
- * Lenovo L430 0x350f02 b9, 15, 0c 2 hw buttons (*)
- * Lenovo L530 0x350f02 b9, 15, 0c 2 hw buttons (*)
- * Samsung NF210 0x150b00 78, 14, 0a 2 hw buttons
- * Samsung NP770Z5E 0x575f01 10, 15, 0f clickpad
- * Samsung NP700Z5B 0x361f06 21, 15, 0f clickpad
- * Samsung NP900X3E-A02 0x575f03 ? clickpad
- * Samsung NP-QX410 0x851b00 19, 14, 0c clickpad
- * Samsung RC512 0x450f00 08, 15, 0c 2 hw buttons
- * Samsung RF710 0x450f00 ? 2 hw buttons
- * System76 Pangolin 0x250f01 ? 2 hw buttons
- * (*) + 3 trackpoint buttons
- * (**) + 0 trackpoint buttons
- * Note: Lenovo L430 and Lenovo L530 have the same fw_version/caps
- */
static void elantech_set_buttonpad_prop(struct psmouse *psmouse)
{
struct input_dev *dev = psmouse->dev;
struct elantech_data *etd = psmouse->private;
- if (etd->info.fw_version & 0x001000) {
+ if (elantech_is_buttonpad(&etd->info)) {
__set_bit(INPUT_PROP_BUTTONPAD, dev->propbit);
__clear_bit(BTN_RIGHT, dev->keybit);
}
--
2.14.3
^ permalink raw reply related
* [PATCH 3/5] dt-bindings: add more optional properties for elan_i2c touchpads
From: Benjamin Tissoires @ 2018-10-12 14:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: KT Liao, Rob Herring, linux-input, linux-kernel, devicetree,
Benjamin Tissoires
In-Reply-To: <20181012142413.26107-1-benjamin.tissoires@redhat.com>
Some new touchpads IC are connected through PS/2 and I2C. On some of these
new IC, the I2C part doesn't have all of the information available.
We need to be able to forward the touchpad parameters from PS/2 and
thus, we need those new optional properties.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1628715
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
Documentation/devicetree/bindings/input/elan_i2c.txt | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/input/elan_i2c.txt b/Documentation/devicetree/bindings/input/elan_i2c.txt
index 797607460735..ace6bcb0b4eb 100644
--- a/Documentation/devicetree/bindings/input/elan_i2c.txt
+++ b/Documentation/devicetree/bindings/input/elan_i2c.txt
@@ -13,6 +13,14 @@ Optional properties:
pinctrl binding [1]).
- vcc-supply: a phandle for the regulator supplying 3.3V power.
- elan,trackpoint: touchpad can support a trackpoint (boolean)
+- elan,clickpad: touchpad is a clickpad (the entire surface is a button)
+- elan,max_x: the maximum reported value on the X axis
+- elan,max_y: the maximum reported value on the Y axis
+- elan,min_x: the minimum reported value on the X axis
+- elan,min_y: the minimum reported value on the Y axis
+- elan,x_res: the resolution of the X axis (in units per mm)
+- elan,y_res: the resolution of the Y axis (in units per mm)
+- elan,width: max reported width of a blob
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
--
2.14.3
^ permalink raw reply related
* [PATCH 4/5] Input: elan_i2c - do not query the info if they are provided
From: Benjamin Tissoires @ 2018-10-12 14:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: KT Liao, Rob Herring, linux-input, linux-kernel, devicetree,
Benjamin Tissoires
In-Reply-To: <20181012142413.26107-1-benjamin.tissoires@redhat.com>
See the previous patch for a long explanation.
TL;DR: the P52 and the t480s from Lenovo can't rely on I2C to fetch
the information, so we need it from PS/2.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1628715
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/mouse/elan_i2c_core.c | 49 +++++++++++++++++++++++++++----------
1 file changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_core.c b/drivers/input/mouse/elan_i2c_core.c
index f5ae24865355..5e7ba383f95c 100644
--- a/drivers/input/mouse/elan_i2c_core.c
+++ b/drivers/input/mouse/elan_i2c_core.c
@@ -366,27 +366,50 @@ static unsigned int elan_convert_resolution(u8 val)
static int elan_query_device_parameters(struct elan_tp_data *data)
{
+ struct i2c_client *client = data->client;
unsigned int x_traces, y_traces;
u8 hw_x_res, hw_y_res;
int error;
- error = data->ops->get_max(data->client, &data->max_x, &data->max_y);
- if (error)
- return error;
+ if (device_property_read_u32(&client->dev,
+ "elan,max_x", &data->max_x) ||
+ device_property_read_u32(&client->dev,
+ "elan,max_y", &data->max_y)) {
+ error = data->ops->get_max(data->client,
+ &data->max_x,
+ &data->max_y);
+ if (error)
+ return error;
+ }
- error = data->ops->get_num_traces(data->client, &x_traces, &y_traces);
- if (error)
- return error;
+ if (device_property_read_u32(&client->dev,
+ "elan,width", &data->width_x)) {
+ error = data->ops->get_num_traces(data->client,
+ &x_traces, &y_traces);
+ if (error)
+ return error;
- data->width_x = data->max_x / x_traces;
- data->width_y = data->max_y / y_traces;
+ data->width_x = data->max_x / x_traces;
+ data->width_y = data->max_y / y_traces;
+ } else {
+ data->width_y = data->width_x;
+ }
- error = data->ops->get_resolution(data->client, &hw_x_res, &hw_y_res);
- if (error)
- return error;
+ if (device_property_read_u32(&client->dev,
+ "elan,x_res", &data->x_res) ||
+ device_property_read_u32(&client->dev,
+ "elan,y_res", &data->y_res)) {
+ error = data->ops->get_resolution(data->client,
+ &hw_x_res, &hw_y_res);
+ if (error)
+ return error;
+
+ data->x_res = elan_convert_resolution(hw_x_res);
+ data->y_res = elan_convert_resolution(hw_y_res);
+ }
- data->x_res = elan_convert_resolution(hw_x_res);
- data->y_res = elan_convert_resolution(hw_y_res);
+ if (device_property_read_bool(&client->dev, "elan,clickpad"))
+ data->clickpad = 1;
return 0;
}
--
2.14.3
^ permalink raw reply related
* [PATCH 5/5] Input: elantech/SMBus - export all capabilities from the PS/2 node
From: Benjamin Tissoires @ 2018-10-12 14:24 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: KT Liao, Rob Herring, linux-input, linux-kernel, devicetree,
Benjamin Tissoires
In-Reply-To: <20181012142413.26107-1-benjamin.tissoires@redhat.com>
The recent touchpads might not have all the information regarding the
characteristics through the I2C port.
On some Lenovo t480s, this results in the touchpad not being detected
as a clickpad, and on the Lenovo P52, this results in a failure while
fetching the resolution through I2C.
We need to imitate the Windows behavior: fetch the data under PS/2, and
limit the querries under I2C.
This patch exports the needed info from PS/2.
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1628715
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/mouse/elantech.c | 23 ++++++++++++++++++-----
1 file changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/input/mouse/elantech.c b/drivers/input/mouse/elantech.c
index 78ac732e8188..f597b5d14de8 100644
--- a/drivers/input/mouse/elantech.c
+++ b/drivers/input/mouse/elantech.c
@@ -1764,17 +1764,30 @@ static int elantech_create_smbus(struct psmouse *psmouse,
struct elantech_device_info *info,
bool leave_breadcrumbs)
{
- const struct property_entry i2c_properties[] = {
- PROPERTY_ENTRY_BOOL("elan,trackpoint"),
- { },
- };
+ struct property_entry i2c_props[10] = {};
struct i2c_board_info smbus_board = {
I2C_BOARD_INFO("elan_i2c", 0x15),
.flags = I2C_CLIENT_HOST_NOTIFY,
};
+ unsigned int prop_idx = 0;
+
+ smbus_board.properties = i2c_props;
+
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_U32("elan,max_x", info->x_max);
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_U32("elan,max_y", info->y_max);
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_U32("elan,min_x", info->x_min);
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_U32("elan,min_y", info->y_min);
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_U32("elan,x_res", info->x_res);
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_U32("elan,y_res", info->y_res);
if (info->has_trackpoint)
- smbus_board.properties = i2c_properties;
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_BOOL("elan,trackpoint");
+
+ if (info->width)
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_U32("elan,width", info->width);
+
+ if (elantech_is_buttonpad(info))
+ i2c_props[prop_idx++] = PROPERTY_ENTRY_BOOL("elan,clickpad");
return psmouse_smbus_init(psmouse, &smbus_board, NULL, 0, false,
leave_breadcrumbs);
--
2.14.3
^ permalink raw reply related
* Re: [PATCH v3 1/8] dt-bindings: mfd: document stpmic1
From: Rob Herring @ 2018-10-12 15:28 UTC (permalink / raw)
To: Pascal PAILLET-LME
Cc: dmitry.torokhov@gmail.com, mark.rutland@arm.com,
lee.jones@linaro.org, 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
In-Reply-To: <1539016176-4072-2-git-send-email-p.paillet@st.com>
On Mon, Oct 08, 2018 at 04:29:39PM +0000, Pascal PAILLET-LME wrote:
> From: pascal paillet <p.paillet@st.com>
>
> stpmic1 is a pmic from STMicroelectronics. The STPMIC1 integrates 10
> regulators ,3 switches, a watchdog and an input for a power on key.
regulators, 3 switches, ...
>
> Signed-off-by: pascal paillet <p.paillet@st.com>
> ---
> changes in v3:
> * Replace st,onkey-long-press-seconds by power-off-time-sec.
> * Replace interrupts-extended by interrupts.
> * Remove wakeup interrupt.
> * Cosmetics.
>
> .../devicetree/bindings/mfd/st,stpmic1.txt | 133 +++++++++++++++++++++
> include/dt-bindings/mfd/st,stpmic1.h | 46 +++++++
> 2 files changed, 179 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> create mode 100644 include/dt-bindings/mfd/st,stpmic1.h
A few nits, otherwise:
Reviewed-by: Rob Herring <robh@kernel.org>
>
> diff --git a/Documentation/devicetree/bindings/mfd/st,stpmic1.txt b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> new file mode 100644
> index 0000000..989bd58
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mfd/st,stpmic1.txt
> @@ -0,0 +1,133 @@
> +* STMicroelectronics STPMIC1 Power Management IC
> +
> +Required parent device properties:
> +- compatible: "st,stpmic1"
> +- reg: The I2C slave address for the STPMIC1 chip.
space before tabs
> +- interrupt-parent Phandle to the parent interrupt controller.
Drop this. It could be in the parent.
> +- interrupts: The interrupt line the device is connected to.
> +- #interrupt-cells: Should be 1.
more space before tabs.
> +- interrupt-controller: Describes the STPMIC1 as an interrupt
> + controller (has its own domain). Interrupt number are the following:
> + /* Interrupt Register 1 (0x50 for latch) */
> + IT_SWOUT_R=0
> + IT_SWOUT_F=1
> + IT_VBUS_OTG_R=2
> + IT_VBUS_OTG_F=3
> + IT_WAKEUP_R=4
> + IT_WAKEUP_F=5
> + IT_PONKEY_R=6
> + IT_PONKEY_F=7
> + /* Interrupt Register 2 (0x51 for latch) */
> + IT_OVP_BOOST=8
> + IT_OCP_BOOST=9
> + IT_OCP_SWOUT=10
> + IT_OCP_OTG=11
> + IT_CURLIM_BUCK4=12
> + IT_CURLIM_BUCK3=13
> + IT_CURLIM_BUCK2=14
> + IT_CURLIM_BUCK1=15
> + /* Interrupt Register 3 (0x52 for latch) */
> + IT_SHORT_SWOUT=16
> + IT_SHORT_SWOTG=17
> + IT_CURLIM_LDO6=18
> + IT_CURLIM_LDO5=19
> + IT_CURLIM_LDO4=20
> + IT_CURLIM_LDO3=21
> + IT_CURLIM_LDO2=22
> + IT_CURLIM_LDO1=23
> + /* Interrupt Register 3 (0x52 for latch) */
> + IT_SWIN_R=24
> + IT_SWIN_F=25
> + IT_RESERVED_1=26
> + IT_RESERVED_2=27
> + IT_VINLOW_R=28
> + IT_VINLOW_F=29
> + IT_TWARN_R=30
> + IT_TWARN_F=31
> +
> +Optional parent device properties:
> +- st,main-control-register:
> + -bit 1: Power cycling will be performed on turn OFF condition
> + -bit 2: PWRCTRL is functional
> + -bit 3: PWRCTRL active high
> +- st,pads-pull-register:
> + -bit 1: WAKEUP pull down is not active
> + -bit 2: PWRCTRL pull up is active
> + -bit 3: PWRCTRL pull down is active
> + -bit 4: WAKEUP detector is disabled
> +- st,vin-control-register:
> + -bit 0: VINLOW monitoring is enabled
> + -bit [1...3]: VINLOW rising threshold
> + 000 VINOK_f + 50mV
> + 001 VINOK_f + 100mV
> + 010 VINOK_f + 150mV
> + 011 VINOK_f + 200mV
> + 100 VINOK_f + 250mV
> + 101 VINOK_f + 300mV
> + 110 VINOK_f + 350mV
> + 111 VINOK_f + 400mV
> + -bit [4...5]: VINLOW hyst
> + 00 100mV
> + 01 200mV
> + 10 300mV
> + 11 400mV
> + -bit 6: SW_OUT detector is disabled
> + -bit 7: SW_IN detector is enabled.
> +- st,usb-control-register:
> + -bit 3: SW_OUT current limit
> + 0: 600mA
> + 1: 1.1A
> + -bit 4: VBUS_OTG discharge is enabled
> + -bit 5: SW_OUT discharge is enabled
> + -bit 6: VBUS_OTG detection is enabled
> + -bit 7: BOOST_OVP is disabled
> +
> +STPMIC1 consists in a varied group of sub-devices.
> +Each sub-device binding is be described in own documentation file.
> +
> +Device Description
> +------ ------------
> +st,stpmic1-onkey : Power on key, see ../input/st,stpmic1-onkey.txt
> +st,stpmic1-regulators : Regulators, see ../regulator/st,stpmic1-regulator.txt
> +st,stpmic1-wdt : Watchdog, see ../watchdog/st,stpmic1-wdt.txt
> +
> +Example:
> +
> +pmic: pmic1@33 {
pmic@33
> + compatible = "st,stpmic1";
> + reg = <0x33>;
> + interrupt-parent = <&gpioa>;
> + interrupts = <0 2>;
> + st,main-control-register=<0x0c>;
> + interrupt-controller;
> + #interrupt-cells = <2>;
> +
> + onkey {
> + compatible = "st,stpmic1-onkey";
> + interrupt-parent = <&pmic>;
Not needed because the parent is the interrupt controller.
> + interrupts = <IT_PONKEY_F 0>,<IT_PONKEY_R 1>;
> + interrupt-names = "onkey-falling", "onkey-rising";
> + power-off-time-sec = <10>;
> + };
> +
> + watchdog {
> + compatible = "st,stpmic1-wdt";
> + };
> +
> + regulators {
> + compatible = "st,stpmic1-regulators";
> +
> + vdd_core: buck1 {
> + regulator-name = "vdd_core";
> + regulator-boot-on;
> + regulator-min-microvolt = <700000>;
> + regulator-max-microvolt = <1200000>;
> + };
> + vdd: buck3 {
> + regulator-name = "vdd";
> + regulator-min-microvolt = <3300000>;
> + regulator-max-microvolt = <3300000>;
> + regulator-boot-on;
> + regulator-pull-down;
> + };
> + };
> diff --git a/include/dt-bindings/mfd/st,stpmic1.h b/include/dt-bindings/mfd/st,stpmic1.h
> new file mode 100644
> index 0000000..b2d6c83
> --- /dev/null
> +++ b/include/dt-bindings/mfd/st,stpmic1.h
> @@ -0,0 +1,46 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +/*
> + * Copyright (C) STMicroelectronics 2018 - All Rights Reserved
> + * Author: Philippe Peurichard <philippe.peurichard@st.com>,
> + * Pascal Paillet <p.paillet@st.com> for STMicroelectronics.
> + */
> +
> +#ifndef __DT_BINDINGS_STPMIC1_H__
> +#define __DT_BINDINGS_STPMIC1_H__
> +
> +/* IRQ definitions */
> +#define IT_PONKEY_F 0
> +#define IT_PONKEY_R 1
> +#define IT_WAKEUP_F 2
> +#define IT_WAKEUP_R 3
> +#define IT_VBUS_OTG_F 4
> +#define IT_VBUS_OTG_R 5
> +#define IT_SWOUT_F 6
> +#define IT_SWOUT_R 7
> +
> +#define IT_CURLIM_BUCK1 8
> +#define IT_CURLIM_BUCK2 9
> +#define IT_CURLIM_BUCK3 10
> +#define IT_CURLIM_BUCK4 11
> +#define IT_OCP_OTG 12
> +#define IT_OCP_SWOUT 13
> +#define IT_OCP_BOOST 14
> +#define IT_OVP_BOOST 15
> +
> +#define IT_CURLIM_LDO1 16
> +#define IT_CURLIM_LDO2 17
> +#define IT_CURLIM_LDO3 18
> +#define IT_CURLIM_LDO4 19
> +#define IT_CURLIM_LDO5 20
> +#define IT_CURLIM_LDO6 21
> +#define IT_SHORT_SWOTG 22
> +#define IT_SHORT_SWOUT 23
> +
> +#define IT_TWARN_F 24
> +#define IT_TWARN_R 25
> +#define IT_VINLOW_F 26
> +#define IT_VINLOW_R 27
> +#define IT_SWIN_F 30
> +#define IT_SWIN_R 31
> +
> +#endif /* __DT_BINDINGS_STPMIC1_H__ */
> --
> 1.9.1
^ permalink raw reply
* Re: [PATCH v3 3/8] dt-bindings: regulator: document stpmic1 pmic regulators
From: Rob Herring @ 2018-10-12 15:32 UTC (permalink / raw)
Cc: dmitry.torokhov@gmail.com, robh+dt@kernel.org,
mark.rutland@arm.com, lee.jones@linaro.org, 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,
Pascal PAILLET-LME
In-Reply-To: <1539016176-4072-4-git-send-email-p.paillet@st.com>
On Mon, 8 Oct 2018 16:29:40 +0000, Pascal PAILLET-LME wrote:
> From: pascal paillet <p.paillet@st.com>
>
> The STPMIC1 regulators supply power to the application processor as well as
> to the external system peripherals such as DDR, Flash memories and system
> devices.
>
> Signed-off-by: pascal paillet <p.paillet@st.com>
> ---
> changes in v3: nothing
>
> .../bindings/regulator/st,stpmic1-regulator.txt | 68 ++++++++++++++++++++++
> 1 file changed, 68 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/regulator/st,stpmic1-regulator.txt
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ 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