* Re: [PATCHv3 2/5] ARM:sunxi:drivers:input Add support for A10/A20 PS2
From: Vishnu Patekar @ 2014-12-23 22:28 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: linux-input@vger.kernel.org, maxime.ripard@free-electrons.com,
Hans de Goede, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, robh+dt@kernel.org,
pawel.moll@arm.com, mark.rutland@arm.com,
ijc+devicetree@hellion.org.uk, Kumar Gala, linux@arm.linux.org.uk,
Grant Likely, benh@kernel.crashing.org, msalter@redhat.com,
ralf@linux-mips.org, jdelvare@suse.de
In-Reply-To: <20141214203759.GA36053@dtor-ws>
Hello Dmitry,
Sorry for delayed response. please find my comment in-lined.
Please let me know in case I am wrong.
On Mon, Dec 15, 2014 at 2:07 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Vishnu,
>
> On Fri, Dec 12, 2014 at 11:55:45PM +0530, VishnuPatekar wrote:
>>
>> Signed-off-by: VishnuPatekar <vishnupatekar0510@gmail.com>
>> ---
>> drivers/input/serio/Kconfig | 11 ++
>> drivers/input/serio/Makefile | 1 +
>> drivers/input/serio/sun4i-ps2.c | 362 +++++++++++++++++++++++++++++++++++++++
>> 3 files changed, 374 insertions(+)
>> create mode 100644 drivers/input/serio/sun4i-ps2.c
>>
>> diff --git a/drivers/input/serio/Kconfig b/drivers/input/serio/Kconfig
>> index bc2d474..964afc5 100644
>> --- a/drivers/input/serio/Kconfig
>> +++ b/drivers/input/serio/Kconfig
>> @@ -281,4 +281,15 @@ config HYPERV_KEYBOARD
>> To compile this driver as a module, choose M here: the module will
>> be called hyperv_keyboard.
>>
>> +config SERIO_SUN4I_PS2
>> + tristate "Allwinner A10 PS/2 controller support"
>> + default n
>> + depends on ARCH_SUNXI || COMPILE_TEST
>> + help
>> + This selects support for the PS/2 Host Controller on
>> + Allwinner A10.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called sun4i-ps2.
>> +
>> endif
>> diff --git a/drivers/input/serio/Makefile b/drivers/input/serio/Makefile
>> index 815d874..c600089 100644
>> --- a/drivers/input/serio/Makefile
>> +++ b/drivers/input/serio/Makefile
>> @@ -29,3 +29,4 @@ obj-$(CONFIG_SERIO_ARC_PS2) += arc_ps2.o
>> obj-$(CONFIG_SERIO_APBPS2) += apbps2.o
>> obj-$(CONFIG_SERIO_OLPC_APSP) += olpc_apsp.o
>> obj-$(CONFIG_HYPERV_KEYBOARD) += hyperv-keyboard.o
>> +obj-$(CONFIG_SERIO_SUN4I_PS2) += sun4i-ps2.o
>> diff --git a/drivers/input/serio/sun4i-ps2.c b/drivers/input/serio/sun4i-ps2.c
>> new file mode 100644
>> index 0000000..e6d22ae
>> --- /dev/null
>> +++ b/drivers/input/serio/sun4i-ps2.c
>> @@ -0,0 +1,362 @@
>> +/*
>> + * Driver for Allwinner A10 PS2 host controller
>> + *
>> + * Author: Vishnu Patekar <vishnupatekar0510@gmail.com>
>> + * Aaron.maoye <leafy.myeh@newbietech.com>
>> + *
>> + *
>> + */
>> +
>> +#include <linux/module.h>
>> +#include <linux/serio.h>
>> +#include <linux/interrupt.h>
>> +#include <linux/errno.h>
>> +#include <linux/slab.h>
>> +#include <linux/list.h>
>> +#include <linux/io.h>
>> +#include <linux/of_address.h>
>> +#include <linux/of_device.h>
>> +#include <linux/of_irq.h>
>> +#include <linux/of_platform.h>
>> +#include <linux/clk.h>
>> +#include <linux/delay.h>
>> +
>> +#define DRIVER_NAME "sun4i-ps2"
>> +
>> +/* register offset definitions */
>> +#define PS2_REG_GCTL (0x00) /* PS2 Module Global Control Reg */
>> +#define PS2_REG_DATA (0x04) /* PS2 Module Data Reg */
>> +#define PS2_REG_LCTL (0x08) /* PS2 Module Line Control Reg */
>> +#define PS2_REG_LSTS (0x0C) /* PS2 Module Line Status Reg */
>> +#define PS2_REG_FCTL (0x10) /* PS2 Module FIFO Control Reg */
>> +#define PS2_REG_FSTS (0x14) /* PS2 Module FIFO Status Reg */
>> +#define PS2_REG_CLKDR (0x18) /* PS2 Module Clock Divider Reg*/
>
> You do not need parenthesis around simple constants.
Okie, I'll remove.
>
>> +
>> +/* PS2 GLOBAL CONTROL REGISTER PS2_GCTL */
>> +#define PS2_GCTL_INTFLAG BIT(4)
>> +#define PS2_GCTL_INTEN BIT(3)
>> +#define PS2_GCTL_RESET BIT(2)
>> +#define PS2_GCTL_MASTER BIT(1)
>> +#define PS2_GCTL_BUSEN BIT(0)
>> +
>> +/* PS2 LINE CONTROL REGISTER */
>> +#define PS2_LCTL_NOACK BIT(18)
>> +#define PS2_LCTL_TXDTOEN BIT(8)
>> +#define PS2_LCTL_STOPERREN BIT(3)
>> +#define PS2_LCTL_ACKERREN BIT(2)
>> +#define PS2_LCTL_PARERREN BIT(1)
>> +#define PS2_LCTL_RXDTOEN BIT(0)
>> +
>> +/* PS2 LINE STATUS REGISTER */
>> +#define PS2_LSTS_TXTDO BIT(8)
>> +#define PS2_LSTS_STOPERR BIT(3)
>> +#define PS2_LSTS_ACKERR BIT(2)
>> +#define PS2_LSTS_PARERR BIT(1)
>> +#define PS2_LSTS_RXTDO BIT(0)
>> +
>> +#define PS2_LINE_ERROR_BIT \
>> + (PS2_LSTS_TXTDO | PS2_LSTS_STOPERR | PS2_LSTS_ACKERR | \
>> + PS2_LSTS_PARERR | PS2_LSTS_RXTDO)
>> +
>> +/* PS2 FIFO CONTROL REGISTER */
>> +#define PS2_FCTL_TXRST BIT(17)
>> +#define PS2_FCTL_RXRST BIT(16)
>> +#define PS2_FCTL_TXUFIEN BIT(10)
>> +#define PS2_FCTL_TXOFIEN BIT(9)
>> +#define PS2_FCTL_TXRDYIEN BIT(8)
>> +#define PS2_FCTL_RXUFIEN BIT(2)
>> +#define PS2_FCTL_RXOFIEN BIT(1)
>> +#define PS2_FCTL_RXRDYIEN BIT(0)
>> +
>> +/* PS2 FIFO STATUS REGISTER */
>> +#define PS2_FSTS_TXUF BIT(10)
>> +#define PS2_FSTS_TXOF BIT(9)
>> +#define PS2_FSTS_TXRDY BIT(8)
>> +#define PS2_FSTS_RXUF BIT(2)
>> +#define PS2_FSTS_RXOF BIT(1)
>> +#define PS2_FSTS_RXRDY BIT(0)
>> +
>> +#define PS2_FIFO_ERROR_BIT \
>> + (PS2_FSTS_TXUF | PS2_FSTS_TXOF | PS2_FSTS_RXUF | PS2_FSTS_RXOF)
>> +
>> +#define PS2_SAMPLE_CLK (1000000)
>> +#define PS2_SCLK (125000)
I'll remove these parenthesis around simple constants.
>> +
>> +struct sun4i_ps2data {
>> + struct serio *serio;
>> + struct device *dev;
>> +
>> + /* IO mapping base */
>> + void __iomem *reg_base;
>> +
>> + /* clock management */
>> + struct clk *clk;
>> +
>> + /* irq */
>> + spinlock_t lock;
>> + int irq;
>> +};
>> +
>> +/*********************/
>> +/* Interrupt handler */
>> +/*********************/
>> +static irqreturn_t sun4i_ps2_interrupt(int irq, void *dev_id)
>> +{
>> + struct sun4i_ps2data *drvdata = dev_id;
>> + u32 intr_status;
>> + u32 fifo_status;
>> + unsigned char byte;
>> + u32 rval;
>> + u32 error = 0;
>> +
>> + spin_lock(&drvdata->lock);
>> +
>> + /* Get the PS/2 interrupts and clear them */
>> + intr_status = readl(drvdata->reg_base + PS2_REG_LSTS);
>> + fifo_status = readl(drvdata->reg_base + PS2_REG_FSTS);
>> +
>> + /*Check Line Status Register*/
>> + if (intr_status & PS2_LINE_ERROR_BIT) {
>> + if (intr_status & PS2_LSTS_STOPERR)
>> + dev_info(drvdata->dev, "PS/2 Stop Bit Error!");
>
> The stop bit error is I believe should be reported to consumers as
> SSERIO_FRAME, receive timeout as SERIO_TIMEOUT and parity as
> SERIO_PARITY.
Yes, this can be passed via flags in setio_interrpt. I'll add this.
>
>> + if (intr_status & PS2_LSTS_ACKERR)
>> + dev_info(drvdata->dev, "PS/2 Acknowledge Error!\n");
>
> When is this error signalled?
this is signaled when ACK is not received after data transmitted.
>
>> + if (intr_status & PS2_LSTS_PARERR)
>> + dev_info(drvdata->dev, "PS/2 Parity Error!\n");
>> + if (intr_status & PS2_LSTS_TXTDO)
>> + dev_info(drvdata->dev, "PS/2 Transmit Data Timeout!\n");
>
> Should not you check this status in serio_write() instead of here?
I never get transmit data timeout in serio_write(), even if PS2
keyboard is not connected.
However, it generates this interrupt.
Yes, in case of timeout/failure in serio_write SERIO_TIMEOUT can be returned.
>
>> + if (intr_status & PS2_LSTS_RXTDO)
>> + dev_info(drvdata->dev, "PS/2 Receive Data Timeout!\n");
>> +
>> + /*reset PS/2 controller*/
>> + rval = readl(drvdata->reg_base + PS2_REG_GCTL);
>> + writel(rval | PS2_GCTL_RESET, drvdata->reg_base + PS2_REG_GCTL);
>
> Why do we need to reset controller in case of, let's say, parity glitch?
As per the Reference Manual :
Setting SOFT RESET bit will reset transmitter and receiver of PS2
Module, and the status of transmitter and receiver will revert
to the default state, but not affect any control bits in register,
and data in TXFIFO/RXFIFO.
I think, there is no harm in soft resetting PS2 instead of writing to
multiple registers.
>
>> +
>> + rval = PS2_LSTS_TXTDO | PS2_LSTS_STOPERR | PS2_LSTS_ACKERR |
>> + PS2_LSTS_PARERR | PS2_LSTS_RXTDO;
>> + writel(rval, drvdata->reg_base + PS2_REG_LSTS);
>> + error = 1;
>> + }
>> +
>> + /*Check FIFO Status Register*/
>> + if (fifo_status & PS2_FIFO_ERROR_BIT) {
>> + if (fifo_status & PS2_FSTS_TXUF)
>> + dev_info(drvdata->dev, "PS/2 Tx FIFO Underflow!\n");
>> + if (fifo_status & PS2_FSTS_TXOF)
>> + dev_info(drvdata->dev, "PS/2 Tx FIFO Overflow!\n");
>> + if (fifo_status & PS2_FSTS_RXUF)
>> + dev_info(drvdata->dev, "PS/2 Rx FIFO Underflow!\n");
>> + if (fifo_status & PS2_FSTS_RXOF)
>> + dev_info(drvdata->dev, "PS/2 Rx FIFO Overflow!\n");
>> + /*reset PS/2 controller*/
>> + writel(readl(drvdata->reg_base + PS2_REG_GCTL) | PS2_GCTL_RESET,
>> + drvdata->reg_base + PS2_REG_GCTL);
>
> Again, we do we need to reset controller? Does it stop receiving data
> after RX overflow condition?
After RX overflow it just set the overflow flag in FSTS reg, then we
can reset FIFO to get more data.
>
>> +
>> + rval = PS2_FSTS_TXUF | PS2_FSTS_TXOF | PS2_FSTS_TXRDY |
>> + PS2_FSTS_RXUF | PS2_FSTS_RXOF | PS2_FSTS_RXRDY;
>> + writel(rval, drvdata->reg_base + PS2_REG_FSTS);
>> + error = 1;
>> + }
>> +
>> + rval = (fifo_status >> 16) & 0x3;
>> + while (!error && rval--) {
>> + byte = readl(drvdata->reg_base + PS2_REG_DATA) & 0xff;
>> + serio_interrupt(drvdata->serio, byte, 0);
>> + }
>> +
>> + writel(intr_status, drvdata->reg_base + PS2_REG_LSTS);
>> + writel(fifo_status, drvdata->reg_base + PS2_REG_FSTS);
>> +
>> + spin_unlock(&drvdata->lock);
>> +
>> + return IRQ_HANDLED;
>> +}
>> +
>> +
>> +static int sun4i_ps2_open(struct serio *pserio)
>> +{
>> + struct sun4i_ps2data *drvdata = pserio->port_data;
>> + u32 src_clk = 0;
>> + u32 clk_scdf;
>> + u32 clk_pcdf;
>> + u32 rval;
>> + unsigned long flags;
>> +
>> + /*Set Line Control And Enable Interrupt*/
>> + rval = PS2_LCTL_TXDTOEN | PS2_LCTL_STOPERREN | PS2_LCTL_ACKERREN
>> + | PS2_LCTL_PARERREN | PS2_LCTL_RXDTOEN;
>> + writel(rval, drvdata->reg_base + PS2_REG_LCTL);
>> +
>> + /*Reset FIFO*/
>> + rval = PS2_FCTL_TXRST | PS2_FCTL_RXRST | PS2_FCTL_TXUFIEN
>> + | PS2_FCTL_TXOFIEN | PS2_FCTL_RXUFIEN
>> + | PS2_FCTL_RXOFIEN | PS2_FCTL_RXRDYIEN;
>> +
>> + writel(rval, drvdata->reg_base + PS2_REG_FCTL);
>> +
>> + src_clk = clk_get_rate(drvdata->clk);
>> + /*Set Clock Divider Register*/
>> + clk_scdf = DIV_ROUND_UP(src_clk, PS2_SAMPLE_CLK) - 1;
>> + clk_pcdf = DIV_ROUND_UP(PS2_SAMPLE_CLK, PS2_SCLK) - 1;
>> + rval = (clk_scdf<<8) | clk_pcdf;
>> + writel(rval, drvdata->reg_base + PS2_REG_CLKDR);
>> +
>> +
>> + /*Set Global Control Register*/
>> + rval = PS2_GCTL_RESET | PS2_GCTL_INTEN | PS2_GCTL_MASTER
>> + | PS2_GCTL_BUSEN;
>> +
>> + spin_lock_irqsave(&drvdata->lock, flags);
>> + writel(rval, drvdata->reg_base + PS2_REG_GCTL);
>> + spin_unlock_irqrestore(&drvdata->lock, flags);
>> +
>> + return 0;
>> +}
>> +
>> +static void sun4i_ps2_close(struct serio *pserio)
>> +{
>> + struct sun4i_ps2data *drvdata = pserio->port_data;
>> + unsigned long flags;
>> +
>> + spin_lock_irqsave(&drvdata->lock, flags);
>> + /* Disable the PS2 interrupts */
>> + writel(0, drvdata->reg_base + PS2_REG_GCTL);
>> + spin_unlock_irqrestore(&drvdata->lock, flags);
>
>
> I think you want to add synchronize_irq() here to make sure pending
> interrupt handler runs to completion before you return.
Yes, synchronize_irq()
>
>> +}
>> +
>> +static int sun4i_ps2_write(struct serio *pserio, unsigned char val)
>> +{
>> + unsigned long expire = jiffies + msecs_to_jiffies(10000);
>> + struct sun4i_ps2data *drvdata;
>> +
>> + drvdata = (struct sun4i_ps2data *)pserio->port_data;
>> +
>> + do {
>> + if (readl(drvdata->reg_base + PS2_REG_FSTS) & PS2_FSTS_TXRDY) {
>> + writel(val, drvdata->reg_base + PS2_REG_DATA);
>> + return 0;
>> + }
>> + } while (time_before(jiffies, expire));
>> +
>> + return 0;
>> +}
>> +
>> +static int sun4i_ps2_probe(struct platform_device *pdev)
>> +{
>> + struct resource *res; /* IO mem resources */
>> + struct sun4i_ps2data *drvdata;
>> + struct serio *serio;
>> + struct device *dev = &pdev->dev;
>> + unsigned int irq;
>> + int error;
>> +
>> + drvdata = devm_kzalloc(dev, sizeof(struct sun4i_ps2data), GFP_KERNEL);
>> + serio = kzalloc(sizeof(struct serio), GFP_KERNEL);
>> + if (!drvdata || !serio) {
>> + error = -ENOMEM;
>> + goto err_free_mem;
>> + }
>> +
>> + spin_lock_init(&drvdata->lock);
>> +
>> + /* IO */
>> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>> + drvdata->reg_base = devm_ioremap_resource(dev, res);
>> + if (IS_ERR(drvdata->reg_base)) {
>> + dev_err(dev, "failed to map registers\n");
>> + error = PTR_ERR(drvdata->reg_base);
>> + goto err_free_mem;
>> + }
>> +
>> + drvdata->clk = devm_clk_get(dev, NULL);
>> + if (IS_ERR(drvdata->clk)) {
>> + error = PTR_ERR(drvdata->clk);
>> + dev_err(dev, "couldn't get clock %d\n", error);
>> + goto err_free_mem;
>> + }
>> +
>> + error = clk_prepare_enable(drvdata->clk);
>> + if (error) {
>> + dev_err(dev, "failed to enable clock %d\n", error);
>> + goto err_free_mem;
>> + }
>> +
>
> I think you should explicitly prohibit the device generating interrupts
> by writing to PS2_ERG_CTRL here.
Okie.
>
>> + serio->id.type = SERIO_8042;
>> + serio->write = sun4i_ps2_write;
>> + serio->open = sun4i_ps2_open;
>> + serio->close = sun4i_ps2_close;
>> + serio->port_data = drvdata;
>> + serio->dev.parent = dev;
>> + strlcpy(serio->name, dev_name(dev), sizeof(serio->name));
>> + strlcpy(serio->phys, dev_name(dev), sizeof(serio->phys));
>> +
>> + /* Get IRQ for the device */
>> + irq = platform_get_irq(pdev, 0);
>> + if (!irq) {
>> + dev_err(dev, "no IRQ found\n");
>> + error = -ENXIO;
>> + goto error_disable_clk;
>> + }
>> +
>> + drvdata->irq = irq;
>> + drvdata->serio = serio;
>> + drvdata->dev = dev;
>> + error = devm_request_threaded_irq(dev, drvdata->irq,
>> + sun4i_ps2_interrupt, NULL, 0, DRIVER_NAME, drvdata);
>> +
>> + if (error) {
>> + dev_err(drvdata->dev, "Interrupt alloc failed %d:error:%d\n",
>> + drvdata->irq, error);
>> + goto error_disable_clk;
>> + }
>> +
>> + serio_register_port(serio);
>> + platform_set_drvdata(pdev, drvdata);
>> +
>> + return 0; /* success */
>> +
>> +error_disable_clk:
>> + clk_disable_unprepare(drvdata->clk);
>> +
>> +err_free_mem:
>> + kfree(serio);
>> + return error;
>> +}
>> +
>> +static int sun4i_ps2_remove(struct platform_device *pdev)
>> +{
>> + struct sun4i_ps2data *drvdata = platform_get_drvdata(pdev);
>> +
>> + serio_unregister_port(drvdata->serio);
>> + disable_irq(drvdata->irq);
>
> I do not think you need to disable irq here - serio_close will make sure
> that the device does not generate interrupts.
Okie
>
>> +
>> + if (!IS_ERR(drvdata->clk))
>> + clk_disable_unprepare(drvdata->clk);
>> + kfree(drvdata->serio);
>> +
>> + return 0;
>> +}
>> +
>> +/* Match table for of_platform binding */
>> +static const struct of_device_id sun4i_ps2_match[] = {
>> + { .compatible = "allwinner,sun4i-a10-ps2", },
>> + { },
>> +};
>> +
>> +MODULE_DEVICE_TABLE(of, sun4i_ps2_match);
>> +
>> +/*platform driver structure*/
>
> I do not think we should keep the obvious comments like this one.
Okie, I'll remove it.
>
>> +static struct platform_driver sun4i_ps2_driver = {
>> + .probe = sun4i_ps2_probe,
>> + .remove = sun4i_ps2_remove,
>> + .driver = {
>> + .name = DRIVER_NAME,
>> + .of_match_table = sun4i_ps2_match,
>> + },
>> +};
>> +module_platform_driver(sun4i_ps2_driver);
>> +
>> +MODULE_AUTHOR("Vishnu Patekar <vishnupatekar0510@gmail.com>");
>> +MODULE_AUTHOR("Aaron.maoye <leafy.myeh@newbietech.com>");
>> +MODULE_DESCRIPTION("Allwinner A10/Sun4i PS/2 driver");
>> +MODULE_LICENSE("GPL v2");
>> --
>> 1.7.9.5
>>
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Anshul Garg @ 2014-12-23 14:34 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, anshul.g@samsung.com
In-Reply-To: <20141222172622.GA18556@dtor-ws>
Dear Mr Dmitry ,
Thanks for the reply.
I understand that if some handler grabs the input device then all
events will sent to that handler only.
My Concern is If No handler has grabbed the input device then all events
should go to all handlers after application of all filter handlers on
input event
list ( As we have to check for each event whether that event can be filtered
or not).
For example : If 5 handlers registered for the input device and input device is
not grabbed.
Now among these 5 handlers 2 are filter handlers and remaining 3 are regular
input handlers.
So we have to filter the event list first after applying 2 filters
then send the remaining
events to all registered handler.
In this case as per current implementation we pass the events array to
each handler. Input Core does events filtering fr handler then send remaining
events to handler.
What i am proposing is first we have to pass input_value list to all
filter handlers
After filteration of events, we can send the remaining events (Some
events might be removed after applying filter) to all handlers.
In case device is grabbed we will just send the events to handler
which grabbed to device.
I hope to hear from you soon.
Thanks
On Mon, Dec 22, 2014 at 10:56 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Anshul,
>
> On Mon, Dec 22, 2014 at 10:36:09PM +0530, Anshul Garg wrote:
>> In function input_pass_values in input.c file , input core sends all
>> events to each handler associated with the input device ,
>>
>> rcu_read_lock();
>>
>> handle = rcu_dereference(dev->grab);
>> if (handle) {
>> count = input_to_handler(handle, vals, count);
>> } else {
>> list_for_each_entry_rcu(handle, &dev->h_list, d_node)
>> if (handle->open)
>> count = input_to_handler(handle, vals, count);
>> }
>>
>> after this in input_to_handler function events are filtered and sent
>> to the handler.
>>
>> for (v = vals; v != vals + count; v++) {
>> if (handler->filter &&
>> handler->filter(handle, v->type, v->code, v->value))
>> continue;
>> if (end != v)
>> *end = *v;
>> end++;
>> }
>>
>>
>>
>> But as per previous event filter mechanism all the events should be
>> parsed from all
>> handlers after that remaining events should be sent to handlers list.
>>
>> And in comments also its mentioned as
>>
>> /*
>> * Pass event first through all filters and then, if event has not been
>> * filtered out, through all open handles.*/
>>
>> So current approach to filter events seems to be incorrect.
>>
>> Please help to clarify my query.
>
> When you "grab" input device your handler gets exclusive access to all
> events coming form it. Neither filer handlers nor regular input handlers
> receive events from this device until you release it.
>
> So I believe it works as intended.
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* [PATCH v8 6/6] ARM: sunxi: Add AXP20x support multi_v7_defconfig
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/configs/multi_v7_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/multi_v7_defconfig b/arch/arm/configs/multi_v7_defconfig
index 2328fe752e9c..bef90c4ca984 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -191,6 +191,7 @@ CONFIG_TOUCHSCREEN_ATMEL_MXT=y
CONFIG_TOUCHSCREEN_STMPE=y
CONFIG_INPUT_MISC=y
CONFIG_INPUT_MPU3050=y
+CONFIG_INPUT_AXP20X_PEK=y
CONFIG_SERIO_AMBAKMI=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
@@ -278,6 +279,7 @@ CONFIG_SUNXI_WATCHDOG=y
CONFIG_MESON_WATCHDOG=y
CONFIG_MFD_AS3722=y
CONFIG_MFD_BCM590XX=y
+CONFIG_MFD_AXP20X=y
CONFIG_MFD_CROS_EC=y
CONFIG_MFD_CROS_EC_SPI=y
CONFIG_MFD_MAX77686=y
@@ -290,6 +292,7 @@ CONFIG_MFD_TPS6586X=y
CONFIG_MFD_TPS65910=y
CONFIG_REGULATOR_AB8500=y
CONFIG_REGULATOR_AS3722=y
+CONFIG_REGULATOR_AXP20X=y
CONFIG_REGULATOR_BCM590XX=y
CONFIG_REGULATOR_GPIO=y
CONFIG_MFD_SYSCON=y
--
2.1.4
^ permalink raw reply related
* [PATCH v8 5/6] ARM: sunxi: Add AXP20x support in defconfig
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
arch/arm/configs/sunxi_defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm/configs/sunxi_defconfig b/arch/arm/configs/sunxi_defconfig
index 7a342d2780a8..0a781e3c6de3 100644
--- a/arch/arm/configs/sunxi_defconfig
+++ b/arch/arm/configs/sunxi_defconfig
@@ -54,6 +54,8 @@ CONFIG_STMMAC_ETH=y
# CONFIG_INPUT_MOUSEDEV is not set
# CONFIG_INPUT_KEYBOARD is not set
# CONFIG_INPUT_MOUSE is not set
+CONFIG_INPUT_MISC=y
+CONFIG_INPUT_AXP20X_PEK=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_NR_UARTS=8
@@ -77,6 +79,7 @@ CONFIG_SUNXI_WATCHDOG=y
CONFIG_MFD_AXP20X=y
CONFIG_REGULATOR=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
+CONFIG_REGULATOR_AXP20X=y
CONFIG_REGULATOR_GPIO=y
CONFIG_USB=y
CONFIG_USB_EHCI_HCD=y
--
2.1.4
^ permalink raw reply related
* [PATCH v8 4/6] input: misc: Add ABI docs for AXP20x PEK
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Add ABI entries for the PEK found on PMU X-Powers AXP202 and AXP209.
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
[wens-jdAy2FN1RRM@public.gmane.org: Fixed path for sysfs entries]
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/ABI/testing/sysfs-driver-input-axp-pek | 11 +++++++++++
1 file changed, 11 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-input-axp-pek
diff --git a/Documentation/ABI/testing/sysfs-driver-input-axp-pek b/Documentation/ABI/testing/sysfs-driver-input-axp-pek
new file mode 100644
index 000000000000..a5e671b9fa79
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-driver-input-axp-pek
@@ -0,0 +1,11 @@
+What: /sys/class/input/input(x)/device/startup
+Date: March 2014
+Contact: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
+Description: Startup time in us. Board is powered on if the button is pressed
+ for more than <startup_time>
+
+What: /sys/class/input/input(x)/device/shutdown
+Date: March 2014
+Contact: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
+Description: Shutdown time in us. Board is powered off if the button is pressed
+ for more than <shutdown_time>
--
2.1.4
^ permalink raw reply related
* [PATCH v8 3/6] input: misc: Add driver for AXP20x Power Enable Key
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
This patch add support for the Power Enable Key found on MFD AXP202 and
AXP209. Besides the basic support for the button, the driver adds two
entries in sysfs to configure the time delay for power on/off.
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[wens-jdAy2FN1RRM@public.gmane.org: make axp20x_pek_remove() static; remove driver owner field]
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
drivers/input/misc/Kconfig | 11 ++
drivers/input/misc/Makefile | 1 +
drivers/input/misc/axp20x-pek.c | 282 ++++++++++++++++++++++++++++++++++++++++
3 files changed, 294 insertions(+)
create mode 100644 drivers/input/misc/axp20x-pek.c
diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 23297ab6163f..a49bcd351e13 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -404,6 +404,17 @@ config INPUT_RETU_PWRBUTTON
To compile this driver as a module, choose M here. The module will
be called retu-pwrbutton.
+config INPUT_AXP20X_PEK
+ tristate "X-Powers AXP20X power button driver"
+ depends on MFD_AXP20X
+ help
+ Say Y here if you want to enable power key reporting via the
+ AXP20X PMIC.
+
+ To compile this driver as a module, choose M here. The module will
+ be called axp20x-pek.
+
+
config INPUT_TWL4030_PWRBUTTON
tristate "TWL4030 Power button Driver"
depends on TWL4030_CORE
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index 19c760361f80..04ea87fd600d 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -54,6 +54,7 @@ obj-$(CONFIG_INPUT_POWERMATE) += powermate.o
obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
obj-$(CONFIG_INPUT_RB532_BUTTON) += rb532_button.o
obj-$(CONFIG_INPUT_RETU_PWRBUTTON) += retu-pwrbutton.o
+obj-$(CONFIG_INPUT_AXP20X_PEK) += axp20x-pek.o
obj-$(CONFIG_INPUT_GPIO_ROTARY_ENCODER) += rotary_encoder.o
obj-$(CONFIG_INPUT_SGI_BTNS) += sgi_btns.o
obj-$(CONFIG_INPUT_SIRFSOC_ONKEY) += sirfsoc-onkey.o
diff --git a/drivers/input/misc/axp20x-pek.c b/drivers/input/misc/axp20x-pek.c
new file mode 100644
index 000000000000..8dbd097ac939
--- /dev/null
+++ b/drivers/input/misc/axp20x-pek.c
@@ -0,0 +1,282 @@
+/*
+ * axp20x power button driver.
+ *
+ * Copyright (C) 2013 Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
+ *
+ * This file is subject to the terms and conditions of the GNU General
+ * Public License. See the file "COPYING" in the main directory of this
+ * archive for more details.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include <linux/errno.h>
+#include <linux/irq.h>
+#include <linux/init.h>
+#include <linux/input.h>
+#include <linux/interrupt.h>
+#include <linux/kernel.h>
+#include <linux/mfd/axp20x.h>
+#include <linux/module.h>
+#include <linux/platform_device.h>
+#include <linux/regmap.h>
+#include <linux/slab.h>
+
+#define AXP20X_PEK_STARTUP_MASK (0xc0)
+#define AXP20X_PEK_SHUTDOWN_MASK (0x03)
+
+struct axp20x_pek {
+ struct axp20x_dev *axp20x;
+ struct input_dev *input;
+ int irq_dbr;
+ int irq_dbf;
+};
+
+struct axp20x_time {
+ unsigned int time;
+ unsigned int idx;
+};
+
+static const struct axp20x_time startup_time[] = {
+ { .time = 128, .idx = 0 },
+ { .time = 1000, .idx = 2 },
+ { .time = 3000, .idx = 1 },
+ { .time = 2000, .idx = 3 },
+};
+
+static const struct axp20x_time shutdown_time[] = {
+ { .time = 4000, .idx = 0 },
+ { .time = 6000, .idx = 1 },
+ { .time = 8000, .idx = 2 },
+ { .time = 10000, .idx = 3 },
+};
+
+struct axp20x_pek_ext_attr {
+ const struct axp20x_time *p_time;
+ unsigned int mask;
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_startup_ext_attr = {
+ .p_time = startup_time,
+ .mask = AXP20X_PEK_STARTUP_MASK,
+};
+
+static struct axp20x_pek_ext_attr axp20x_pek_shutdown_ext_attr = {
+ .p_time = shutdown_time,
+ .mask = AXP20X_PEK_SHUTDOWN_MASK,
+};
+
+static struct axp20x_pek_ext_attr *get_axp_ext_attr(struct device_attribute *attr)
+{
+ return container_of(attr, struct dev_ext_attribute, attr)->var;
+}
+
+static ssize_t axp20x_show_ext_attr(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
+ struct axp20x_pek_ext_attr *axp20x_ea = get_axp_ext_attr(attr);
+ unsigned int val;
+ int ret, i;
+
+ ret = regmap_read(axp20x_pek->axp20x->regmap, AXP20X_PEK_KEY, &val);
+ if (ret != 0)
+ return ret;
+
+ val &= axp20x_ea->mask;
+ val >>= ffs(axp20x_ea->mask) - 1;
+
+ for (i = 0; i < 4; i++)
+ if (val == axp20x_ea->p_time[i].idx)
+ val = axp20x_ea->p_time[i].time;
+
+ return sprintf(buf, "%u\n", val);
+}
+
+static ssize_t axp20x_store_ext_attr(struct device *dev,
+ struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+ struct axp20x_pek *axp20x_pek = dev_get_drvdata(dev);
+ struct axp20x_pek_ext_attr *axp20x_ea = get_axp_ext_attr(attr);
+ char val_str[20];
+ size_t len;
+ int ret, i;
+ unsigned int val, idx = 0;
+ unsigned int best_err = UINT_MAX;
+
+ val_str[sizeof(val_str) - 1] = '\0';
+ strncpy(val_str, buf, sizeof(val_str) - 1);
+ len = strlen(val_str);
+
+ if (len && val_str[len - 1] == '\n')
+ val_str[len - 1] = '\0';
+
+ ret = kstrtouint(val_str, 10, &val);
+ if (ret)
+ return ret;
+
+ for (i = 3; i >= 0; i--) {
+ unsigned int err;
+
+ err = abs(axp20x_ea->p_time[i].time - val);
+ if (err < best_err) {
+ best_err = err;
+ idx = axp20x_ea->p_time[i].idx;
+ }
+
+ if (!err)
+ break;
+ }
+
+ idx <<= ffs(axp20x_ea->mask) - 1;
+ ret = regmap_update_bits(axp20x_pek->axp20x->regmap,
+ AXP20X_PEK_KEY,
+ axp20x_ea->mask, idx);
+ if (ret != 0)
+ return -EINVAL;
+ return count;
+}
+
+static struct dev_ext_attribute axp20x_dev_attr_startup = {
+ .attr = __ATTR(startup, 0644, axp20x_show_ext_attr, axp20x_store_ext_attr),
+ .var = &axp20x_pek_startup_ext_attr
+};
+
+static struct dev_ext_attribute axp20x_dev_attr_shutdown = {
+ .attr = __ATTR(shutdown, 0644, axp20x_show_ext_attr, axp20x_store_ext_attr),
+ .var = &axp20x_pek_shutdown_ext_attr
+};
+
+static irqreturn_t axp20x_pek_irq(int irq, void *pwr)
+{
+ struct input_dev *idev = pwr;
+ struct axp20x_pek *axp20x_pek = input_get_drvdata(idev);
+
+ if (irq == axp20x_pek->irq_dbr)
+ input_report_key(idev, KEY_POWER, true);
+ else if (irq == axp20x_pek->irq_dbf)
+ input_report_key(idev, KEY_POWER, false);
+
+ input_sync(idev);
+
+ return IRQ_HANDLED;
+}
+
+static int axp20x_pek_probe(struct platform_device *pdev)
+{
+ struct axp20x_pek *axp20x_pek;
+ struct axp20x_dev *axp20x;
+ struct input_dev *idev;
+ int error;
+
+ axp20x_pek = devm_kzalloc(&pdev->dev, sizeof(struct axp20x_pek),
+ GFP_KERNEL);
+ if (!axp20x_pek)
+ return -ENOMEM;
+
+ axp20x_pek->axp20x = dev_get_drvdata(pdev->dev.parent);
+ axp20x = axp20x_pek->axp20x;
+
+ axp20x_pek->irq_dbr = platform_get_irq_byname(pdev, "PEK_DBR");
+ if (axp20x_pek->irq_dbr < 0) {
+ dev_err(&pdev->dev, "No IRQ for PEK_DBR, error=%d\n",
+ axp20x_pek->irq_dbr);
+ return axp20x_pek->irq_dbr;
+ }
+ axp20x_pek->irq_dbr = regmap_irq_get_virq(axp20x->regmap_irqc,
+ axp20x_pek->irq_dbr);
+
+ axp20x_pek->irq_dbf = platform_get_irq_byname(pdev, "PEK_DBF");
+ if (axp20x_pek->irq_dbf < 0) {
+ dev_err(&pdev->dev, "No IRQ for PEK_DBF, error=%d\n",
+ axp20x_pek->irq_dbf);
+ return axp20x_pek->irq_dbf;
+ }
+ axp20x_pek->irq_dbf = regmap_irq_get_virq(axp20x->regmap_irqc,
+ axp20x_pek->irq_dbf);
+
+ axp20x_pek->input = devm_input_allocate_device(&pdev->dev);
+ if (!axp20x_pek->input)
+ return -ENOMEM;
+
+ idev = axp20x_pek->input;
+
+ idev->name = "axp20x-pek";
+ idev->phys = "m1kbd/input2";
+ idev->dev.parent = &pdev->dev;
+
+ input_set_capability(idev, EV_KEY, KEY_POWER);
+
+ input_set_drvdata(idev, axp20x_pek);
+
+ error = devm_request_any_context_irq(&pdev->dev, axp20x_pek->irq_dbr,
+ axp20x_pek_irq, 0,
+ "axp20x-pek-dbr", idev);
+ if (error < 0) {
+ dev_err(axp20x->dev, "Failed to request dbr IRQ#%d: %d\n",
+ axp20x_pek->irq_dbr, error);
+
+ return error;
+ }
+
+ error = devm_request_any_context_irq(&pdev->dev, axp20x_pek->irq_dbf,
+ axp20x_pek_irq, 0,
+ "axp20x-pek-dbf", idev);
+ if (error < 0) {
+ dev_err(axp20x->dev, "Failed to request dbf IRQ#%d: %d\n",
+ axp20x_pek->irq_dbf, error);
+ return error;
+ }
+
+ error = device_create_file(&pdev->dev, &axp20x_dev_attr_startup.attr);
+ if (error)
+ return error;
+
+ error = device_create_file(&pdev->dev, &axp20x_dev_attr_shutdown.attr);
+ if (error)
+ goto clear_startup_attr;
+
+ error = input_register_device(idev);
+ if (error) {
+ dev_err(axp20x->dev, "Can't register input device: %d\n",
+ error);
+ goto clear_attr;
+ }
+
+ platform_set_drvdata(pdev, axp20x_pek);
+
+ return 0;
+
+clear_attr:
+ device_remove_file(&pdev->dev, &axp20x_dev_attr_shutdown.attr);
+
+clear_startup_attr:
+ device_remove_file(&pdev->dev, &axp20x_dev_attr_startup.attr);
+
+ return error;
+}
+
+static int axp20x_pek_remove(struct platform_device *pdev)
+{
+ device_remove_file(&pdev->dev, &axp20x_dev_attr_shutdown.attr);
+ device_remove_file(&pdev->dev, &axp20x_dev_attr_startup.attr);
+
+ return 0;
+}
+
+static struct platform_driver axp20x_pek_driver = {
+ .probe = axp20x_pek_probe,
+ .remove = axp20x_pek_remove,
+ .driver = {
+ .name = "axp20x-pek",
+ },
+};
+module_platform_driver(axp20x_pek_driver);
+
+MODULE_DESCRIPTION("axp20x Power Button");
+MODULE_AUTHOR("Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>");
+MODULE_LICENSE("GPL");
--
2.1.4
^ permalink raw reply related
* [PATCH v8 2/6] dt-bindings: add vendor-prefix for X-Powers
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt
index b1df0ad1306c..1794fce3de80 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -172,6 +172,7 @@ voipac Voipac Technologies s.r.o.
winbond Winbond Electronics corp.
wlf Wolfson Microelectronics
wm Wondermedia Technologies, Inc.
+x-powers X-Powers
xes Extreme Engineering Solutions (X-ES)
xillybus Xillybus Ltd.
xlnx Xilinx
--
2.1.4
^ permalink raw reply related
* [PATCH v8 1/6] mfd: AXP20x: Add bindings documentation
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Carlo Caione,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Chen-Yu Tsai
In-Reply-To: <1419303194-3075-1-git-send-email-wens-jdAy2FN1RRM@public.gmane.org>
From: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Bindings documentation for the AXP20x driver. In this file also
sub-nodes are documented.
Signed-off-by: Carlo Caione <carlo-KA+7E9HrN00dnm+yROfE0A@public.gmane.org>
Acked-by: Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>
[wens-jdAy2FN1RRM@public.gmane.org: clarify interrupt source for the axp PMIC]
[wens-jdAy2FN1RRM@public.gmane.org: explain dcdc-workmode in detail and trim lines to 80 chars]
[wens-jdAy2FN1RRM@public.gmane.org: make regulator supplies optional if using unregulated input]
[wens-jdAy2FN1RRM@public.gmane.org: use cubieboard2 regulator nodes as example]
Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
---
Documentation/devicetree/bindings/mfd/axp20x.txt | 97 ++++++++++++++++++++++++
1 file changed, 97 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
diff --git a/Documentation/devicetree/bindings/mfd/axp20x.txt b/Documentation/devicetree/bindings/mfd/axp20x.txt
new file mode 100644
index 000000000000..b775d8ccbc7c
--- /dev/null
+++ b/Documentation/devicetree/bindings/mfd/axp20x.txt
@@ -0,0 +1,97 @@
+AXP202/AXP209 device tree bindings
+
+The axp20x family current members :
+axp202 (X-Powers)
+axp209 (X-Powers)
+
+Required properties:
+- compatible: "x-powers,axp202" or "x-powers,axp209"
+- reg: The I2C slave address for the AXP chip
+- interrupt-parent: The parent interrupt controller
+- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin
+- interrupt-controller: axp20x has its own internal IRQs
+- #interrupt-cells: Should be set to 1
+- regulators: A node that houses a sub-node for each regulator. The regulators
+ are bound using their name as listed here: dcdc2, dcdc3, ldo1,
+ ldo2, ldo3, ldo4, ldo5. The bindings details of individual
+ regulator device can be found in:
+ Documentation/devicetree/bindings/regulator/regulator.txt with
+ the exception of x-powers,dcdc-freq. Regulators not used should
+ still be listed for completeness and that the regulator subsystem
+ properly registers them.
+
+- x-powers,dcdc-freq: defines the work frequency of DC-DC in KHz
+ (range: 750-1875). Default: 1.5MHz
+
+Optional properties:
+- regulator supplies - may be omitted if inputs are unregulated, such as using
+ the IPSOUT output from the PMIC
+ - acin-supply: The input supply for LDO1
+ - vin2-supply: The input supply for DCDC2
+ - vin3-supply: The input supply for DCDC3
+ - ldo24in-supply: The input supply for LDO2, LDO4
+ - ldo3in-supply: The input supply for LDO3
+ - ldo5in-supply: The input supply for LDO5
+
+Optional properties for DCDC regulators:
+- x-powers,dcdc-workmode: 1 for PWM mode, 0 for AUTO (PWM/PFM) mode
+ Default: AUTO mode
+ The DCDC regulators work in a mixed PWM/PFM mode,
+ using PFM under light loads and switching to PWM
+ for heavier loads. Forcing PWM mode trades efficiency
+ under light loads for lower output noise. This
+ probably makes sense for HiFi audio related
+ applications that aren't battery constrained.
+
+Example:
+
+axp209: pmic@34 {
+ compatible = "x-powers,axp209";
+ reg = <0x34>;
+ interrupt-parent = <&nmi_intc>;
+ interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+
+ regulators {
+ x-powers,dcdc-freq = <1500>;
+
+ vdd_cpu: dcdc2 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1450000>;
+ regulator-name = "vdd-cpu";
+ };
+
+ vdd_int_dll: dcdc3 {
+ regulator-always-on;
+ regulator-min-microvolt = <1000000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-int-dll";
+ };
+
+ vdd_rtc: ldo1 {
+ regulator-always-on;
+ regulator-min-microvolt = <1200000>;
+ regulator-max-microvolt = <1400000>;
+ regulator-name = "vdd-rtc";
+ };
+
+ avcc: ldo2 {
+ regulator-always-on;
+ regulator-min-microvolt = <2700000>;
+ regulator-max-microvolt = <3300000>;
+ regulator-name = "avcc";
+ };
+
+ ldo3 {
+ /* unused */
+ };
+
+ csi1_io_2v8: ldo4 {
+ /* output on extension headers */
+ regulator-name = "csi1-io-2v8";
+ };
+ };
+};
+
--
2.1.4
^ permalink raw reply related
* [PATCH v8 0/6] mfd: AXP20x: Add support for AXP202 and AXP209
From: Chen-Yu Tsai @ 2014-12-23 2:53 UTC (permalink / raw)
To: Lee Jones, Mark Brown, Maxime Ripard, Dmitry Torokhov
Cc: linux-sunxi-/JYPxA39Uh5TLH3MbocFFw, Chen-Yu Tsai,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-doc-u79uwXL29TY76Z2rM5mHXA, Carlo Caione
Hi everyone,
This is v8 of the AXP20x PMIC patches. These are the remaining patches
of the original series: PEK (power button) input driver, binding docs,
and defconfig updates.
Mark raised some questions during v7 about the first patch, specifically
about the "x-powers,dcdc-workmode" property. I've expanded the regulator
parts of the DT bindings doc. Mark, if you could take a look and give us
your blessing?
Dmitry, you were OK with the input bits going through the MFD tree, is
that still the case?
If there are no more problems, maybe Lee could take patches 1~4, and
Maxime can take the defconfig patches through his tree.
Thanks
ChenYu
Changes since v7:
- DT bindings
* Clarified the AXP's interrupt source
* Added explaination for "x-powers,dcdc-workmode" property
* Made regulator supply properties optional. They can be omitted
when the input is unregulated, as is the case when they are
connected to the IPSOUT output on the PMIC.
* Used real world example (Cubieboard2) for regulator nodes
- Fixed paths for PEK sysfs entries.
- PEK driver
* Made axp20x_pek_remove() in PEK driver static.
* Removed driver owner field.
* Wrapped some lines over 80 characters.
Original cover letter from v7:
During the merging of v6 several patches were left out. This v7 comprises
all the patches that are still pending.
//--
AXP209 and AXP202 are the PMUs (Power Management Unit) used by A10, A13
and A20 SoCs and developed by X-Powers, a sister company of Allwinner.
AXP20x comprises an adaptive USB-Compatible PWM charger, 2 BUCK DC-DC
converters, 5 LDOs, multiple 12-bit ADCs of voltage, current and temperature
as well as 4 configurable GPIOs.
This set of patches introduces the core driver and support for two different
subsystems:
- Regulators
- PEK (Power Enable Key)
Changes since v1:
- Added a new standalone patch for defconfig
- MFD core:
* Removed axp,system-power-controller property
- Bindings documentation:
* Corrected description for dcdc-workmode property
* Removed unused axp20x-pek compatible
- Input misc PEK driver:
* Fixed seconds in lower case
- Regulators subsystem:
* Fixed axp20x_set_suspend_voltage()
* Switched to using multi-bit control for regulators
* When "regulators" node is not found driver doesn't quit
* Driver is now using devm_regulator_register()
* Added module_platform_driver() instead of subsys_initcall()
- DT:
* Added new DTSI for AXP209
* Added support for cubietruck and olinuxino-micro
Changes since v2:
- Added a new patch for multi_v7_defconfig to enable MFD core
and subsystems
- DT:
* Dropped axp,system-power-controller property from DTS
* Moved compatible and interrupt-related properties from the
DTSI file to the DTS board files
- Regulators subsystem:
* Deleted useless struct axp20x_regulators
* Added a warning when out of specs values are used for the
dcdc frequency
- MFD core:
* Fixed coding style
* Removed IDs from device table for i2c
- Bindings documentation:
* Several corrections and fixes
Changes since v3:
- Removed x-powers-axp209.dtsi file
- Rewritten bindings document
- MFD core:
* Fixed casting
* Better comments / documentation
- Input misc PEK driver:
* Timings are now expressed in ms and the sysfs appies the
closest possible value
* No more useless pretty-printing
* Removed devm_request_threaded_irq in favour of
devm_request_any_context_irq
* Moved from input attributes to platform device attributes
- Regulators subsystem:
* Removed suspend mode (axp20x_set_suspend_voltage)
* Added regulators input supply
- DT:
* DTs doesn't include anymore the dtsi
* Added input supplies for regulators
Changes since v4:
- Removed regulator patches already applied / acked by Mark Brown
- Input misc PEK driver:
* Don't print anymore the "us" unit
* Added cleanup for attributes when unbindind the device
* Fixed error code returned when device_create_file() fails
- DT:
* Enable all the regulators on at boot-time
* Removed min and max microvolts for all the regulators but DCDC2
* Moved the axp_ipsout regulator outside the MFD node
- MFD core:
* The supply regulators are now specified in the MFD driver using
regulator_bulk_register_supply_alias() and the .parent_supplies
in the MFD cell
Changes since v5:
- Added ACKs
- Fixed compilation warning (reported by Hans De Goede)
- Vendor-prefixes are now sorted
- Removed DT patch
Carlo Caione (6):
mfd: AXP20x: Add bindings documentation
dt-bindings: add vendor-prefix for X-Powers
input: misc: Add driver for AXP20x Power Enable Key
input: misc: Add ABI docs for AXP20x PEK
ARM: sunxi: Add AXP20x support in defconfig
ARM: sunxi: Add AXP20x support multi_v7_defconfig
.../ABI/testing/sysfs-driver-input-axp-pek | 11 +
Documentation/devicetree/bindings/mfd/axp20x.txt | 97 +++++++
.../devicetree/bindings/vendor-prefixes.txt | 1 +
arch/arm/configs/multi_v7_defconfig | 3 +
arch/arm/configs/sunxi_defconfig | 3 +
drivers/input/misc/Kconfig | 11 +
drivers/input/misc/Makefile | 1 +
drivers/input/misc/axp20x-pek.c | 282 +++++++++++++++++++++
8 files changed, 409 insertions(+)
create mode 100644 Documentation/ABI/testing/sysfs-driver-input-axp-pek
create mode 100644 Documentation/devicetree/bindings/mfd/axp20x.txt
create mode 100644 drivers/input/misc/axp20x-pek.c
--
2.1.4
^ permalink raw reply
* Re: [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Anshul Garg @ 2014-12-23 1:22 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, anshul.g@samsung.com
In-Reply-To: <20141222172622.GA18556@dtor-ws>
Dear Mr Dmitry ,
Thanks for the reply.
I understand that if some handler grabs the input device then all
events will sent
to that handler only.
My Concern is If No one has grabbed the input device then all events
should go to
all handlers after application of all filter handlers.
For example : If 5 handlers registered for the input device.
Now among these 5 handlers 2 are filter handlers and remaining 3 are regular
input handlers.
In this case as per current implementation we pass the events array to
each handler.
Handler does its filtering then sent to handler.
What i am proposing is first we have to pass input_value list to all
filter handlers
After filteration of events, we can send the remaining events (Some
events might be removed
after filter) to all handlers.
In case device is grabbed we will just send the events to handler
which grabbed to device.
I hope to hear from you soon.
Thanks
On Mon, Dec 22, 2014 at 10:56 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> Hi Anshul,
>
> On Mon, Dec 22, 2014 at 10:36:09PM +0530, Anshul Garg wrote:
>> In function input_pass_values in input.c file , input core sends all
>> events to each handler associated with the input device ,
>>
>> rcu_read_lock();
>>
>> handle = rcu_dereference(dev->grab);
>> if (handle) {
>> count = input_to_handler(handle, vals, count);
>> } else {
>> list_for_each_entry_rcu(handle, &dev->h_list, d_node)
>> if (handle->open)
>> count = input_to_handler(handle, vals, count);
>> }
>>
>> after this in input_to_handler function events are filtered and sent
>> to the handler.
>>
>> for (v = vals; v != vals + count; v++) {
>> if (handler->filter &&
>> handler->filter(handle, v->type, v->code, v->value))
>> continue;
>> if (end != v)
>> *end = *v;
>> end++;
>> }
>>
>>
>>
>> But as per previous event filter mechanism all the events should be
>> parsed from all
>> handlers after that remaining events should be sent to handlers list.
>>
>> And in comments also its mentioned as
>>
>> /*
>> * Pass event first through all filters and then, if event has not been
>> * filtered out, through all open handles.*/
>>
>> So current approach to filter events seems to be incorrect.
>>
>> Please help to clarify my query.
>
> When you "grab" input device your handler gets exclusive access to all
> events coming form it. Neither filer handlers nor regular input handlers
> receive events from this device until you release it.
>
> So I believe it works as intended.
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Dmitry Torokhov @ 2014-12-22 17:26 UTC (permalink / raw)
To: Anshul Garg; +Cc: linux-input, anshul.g@samsung.com
In-Reply-To: <CA+HOOsgL_fY=Wc+ciDAuk485d=uTn=YTgVGVDJ5Qk3UsqQ8zVA@mail.gmail.com>
Hi Anshul,
On Mon, Dec 22, 2014 at 10:36:09PM +0530, Anshul Garg wrote:
> In function input_pass_values in input.c file , input core sends all
> events to each handler associated with the input device ,
>
> rcu_read_lock();
>
> handle = rcu_dereference(dev->grab);
> if (handle) {
> count = input_to_handler(handle, vals, count);
> } else {
> list_for_each_entry_rcu(handle, &dev->h_list, d_node)
> if (handle->open)
> count = input_to_handler(handle, vals, count);
> }
>
> after this in input_to_handler function events are filtered and sent
> to the handler.
>
> for (v = vals; v != vals + count; v++) {
> if (handler->filter &&
> handler->filter(handle, v->type, v->code, v->value))
> continue;
> if (end != v)
> *end = *v;
> end++;
> }
>
>
>
> But as per previous event filter mechanism all the events should be
> parsed from all
> handlers after that remaining events should be sent to handlers list.
>
> And in comments also its mentioned as
>
> /*
> * Pass event first through all filters and then, if event has not been
> * filtered out, through all open handles.*/
>
> So current approach to filter events seems to be incorrect.
>
> Please help to clarify my query.
When you "grab" input device your handler gets exclusive access to all
events coming form it. Neither filer handlers nor regular input handlers
receive events from this device until you release it.
So I believe it works as intended.
Thanks.
--
Dmitry
^ permalink raw reply
* [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Anshul Garg @ 2014-12-22 17:06 UTC (permalink / raw)
To: Dmitry Torokhov, linux-input, dtor; +Cc: anshul.g@samsung.com
Dear Mr. Dmitry and Linux Community,
I am Anshul Garg working on Linux Kernel from last 2 years .
I have one query regarding event filter mechanism in input subsystem.
Can you please help in answering my query as below:
==============================
=======================
In function input_pass_values in input.c file , input core sends all
events to each handler associated with
the input device ,
rcu_read_lock();
handle = rcu_dereference(dev->grab);
if (handle) {
count = input_to_handler(handle, vals, count);
} else {
list_for_each_entry_rcu(handle, &dev->h_list, d_node)
if (handle->open)
count = input_to_handler(handle, vals, count);
}
after this in input_to_handler function events are filtered and sent
to the handler.
for (v = vals; v != vals + count; v++) {
if (handler->filter &&
handler->filter(handle, v->type, v->code, v->value))
continue;
if (end != v)
*end = *v;
end++;
}
But as per previous event filter mechanism all the events should be
parsed from all
handlers after that remaining events should be sent to handlers list.
And in comments also its mentioned as
/*
* Pass event first through all filters and then, if event has not been
* filtered out, through all open handles.*/
So current approach to filter events seems to be incorrect.
Please help to clarify my query.
I have prepared one patch with new event filter mechanism which will
first filter all events from attached handlers then pass the remaining
events after being filtered
through all handlers unlike current implementation.
Once My query is resolved , I will send the patch.
Thanks
Anshul Garg
+91-9899777351
^ permalink raw reply
* [RFC PATCH 2/2] USB: input: yealink.c: add mapping for "RING" and "MUTE" keys
From: Daniele Forsi @ 2014-12-22 14:41 UTC (permalink / raw)
To: Henk Vergonet, Dmitry Torokhov
Cc: usbb2k-api-dev, linux-input, linux-kernel, Daniele Forsi
In-Reply-To: <1419259269-23820-1-git-send-email-dforsi@gmail.com>
According to the user manual of the "VOIP-3 SKY" USB phone, the RING
key is used to select different ring tones and the MUTE key is used
to mute the microphone.
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
---
drivers/input/misc/yealink.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index e9403da..0b86c49 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -189,7 +189,9 @@ static int setChar(struct yealink_dev *yld, int el, int chr)
* USB-P1K button layout:
*
* up
+ * ring
* IN OUT
+ * mute
* down
*
* pickup C hangup
@@ -207,7 +209,9 @@ static int map_p1k_to_key(int scancode)
switch(scancode) { /* phone key: */
case 0x23: return KEY_LEFT; /* IN */
case 0x33: return KEY_UP; /* up */
+ case 0x44: return KEY_SOUND; /* ring */
case 0x04: return KEY_RIGHT; /* OUT */
+ case 0x41: return KEY_MICMUTE; /* mute */
case 0x24: return KEY_DOWN; /* down */
case 0x03: return KEY_ENTER; /* pickup */
case 0x14: return KEY_BACKSPACE; /* C */
--
2.1.3
^ permalink raw reply related
* [RFC PATCH 1/2] USB: input: yealink.c: use KEY_NUMERIC_* for numeric keys, star and pound
From: Daniele Forsi @ 2014-12-22 14:41 UTC (permalink / raw)
To: Henk Vergonet, Dmitry Torokhov
Cc: usbb2k-api-dev, linux-input, linux-kernel, Daniele Forsi
In-Reply-To: <1419259269-23820-1-git-send-email-dforsi@gmail.com>
Fix the "pound" key that being mapped to Shift+3 was returning '£' instead
of '#' when using an Italian keyboard mapping and use the same values as
the cm109.c driver (which was based on this yealink.c driver) also for '0'
to '9' and for '*'.
Signed-off-by: Daniele Forsi <dforsi@gmail.com>
---
drivers/input/misc/yealink.c | 39 +++++++++++++++------------------------
1 file changed, 15 insertions(+), 24 deletions(-)
diff --git a/drivers/input/misc/yealink.c b/drivers/input/misc/yealink.c
index 79c964c..e9403da 100644
--- a/drivers/input/misc/yealink.c
+++ b/drivers/input/misc/yealink.c
@@ -212,27 +212,24 @@ static int map_p1k_to_key(int scancode)
case 0x03: return KEY_ENTER; /* pickup */
case 0x14: return KEY_BACKSPACE; /* C */
case 0x13: return KEY_ESC; /* hangup */
- case 0x00: return KEY_1; /* 1 */
- case 0x01: return KEY_2; /* 2 */
- case 0x02: return KEY_3; /* 3 */
- case 0x10: return KEY_4; /* 4 */
- case 0x11: return KEY_5; /* 5 */
- case 0x12: return KEY_6; /* 6 */
- case 0x20: return KEY_7; /* 7 */
- case 0x21: return KEY_8; /* 8 */
- case 0x22: return KEY_9; /* 9 */
- case 0x30: return KEY_KPASTERISK; /* * */
- case 0x31: return KEY_0; /* 0 */
- case 0x32: return KEY_LEFTSHIFT |
- KEY_3 << 8; /* # */
+ case 0x00: return KEY_NUMERIC_1; /* 1 */
+ case 0x01: return KEY_NUMERIC_2; /* 2 */
+ case 0x02: return KEY_NUMERIC_3; /* 3 */
+ case 0x10: return KEY_NUMERIC_4; /* 4 */
+ case 0x11: return KEY_NUMERIC_5; /* 5 */
+ case 0x12: return KEY_NUMERIC_6; /* 6 */
+ case 0x20: return KEY_NUMERIC_7; /* 7 */
+ case 0x21: return KEY_NUMERIC_8; /* 8 */
+ case 0x22: return KEY_NUMERIC_9; /* 9 */
+ case 0x30: return KEY_NUMERIC_STAR; /* * */
+ case 0x31: return KEY_NUMERIC_0; /* 0 */
+ case 0x32: return KEY_NUMERIC_POUND; /* # */
}
return -EINVAL;
}
/* Completes a request by converting the data into events for the
* input subsystem.
- *
- * The key parameter can be cascaded: key2 << 8 | key1
*/
static void report_key(struct yealink_dev *yld, int key)
{
@@ -240,17 +237,13 @@ static void report_key(struct yealink_dev *yld, int key)
if (yld->key_code >= 0) {
/* old key up */
- input_report_key(idev, yld->key_code & 0xff, 0);
- if (yld->key_code >> 8)
- input_report_key(idev, yld->key_code >> 8, 0);
+ input_report_key(idev, yld->key_code, 0);
}
yld->key_code = key;
if (key >= 0) {
/* new valid key */
- input_report_key(idev, key & 0xff, 1);
- if (key >> 8)
- input_report_key(idev, key >> 8, 1);
+ input_report_key(idev, key, 1);
}
input_sync(idev);
}
@@ -966,9 +959,7 @@ static int usb_probe(struct usb_interface *intf, const struct usb_device_id *id)
for (i = 0; i < 256; i++) {
int k = map_p1k_to_key(i);
if (k >= 0) {
- set_bit(k & 0xff, input_dev->keybit);
- if (k >> 8)
- set_bit(k >> 8, input_dev->keybit);
+ set_bit(k, input_dev->keybit);
}
}
--
2.1.3
^ permalink raw reply related
* [RFC PATCH 0/2] USB: input: yealink.c: update key mappings
From: Daniele Forsi @ 2014-12-22 14:41 UTC (permalink / raw)
To: Henk Vergonet, Dmitry Torokhov; +Cc: usbb2k-api-dev, linux-input, linux-kernel
Hello,
I have an Yealink USB phone which is handled by the yealink.c driver but the
'#' key returns an unexpected value and keys labeled "RING" and "MUTE" do not
return any value to userspace.
In the first patch of this series I replace the combination KEY_LEFTSHIFT and
KEY_3 with KEY_NUMERIC_POUND and I also replace other keys for internal consistency
and with the cm109.c driver, which according to the comment in the code is derived
from this one, is this the right approach?
In the second patch I add two additional keys which could be handled by userspace:
"RING" whose purpose according to the user manual is to cycle all available ringtones
"MUTE" whose purpose is to mute the USB microphone
which KEY_* values should be used for them?
I have two more questions:
DRIVER_VERSION should be updated?
are both patches suitable for stable?
Daniele Forsi (2):
USB: input: yealink.c: use KEY_NUMERIC_* for numeric keys, star and
pound
USB: input: yealink.c: add mapping for "RING" and "MUTE" keys
drivers/input/misc/yealink.c | 43 +++++++++++++++++++------------------------
1 file changed, 19 insertions(+), 24 deletions(-)
--
2.1.3
^ permalink raw reply
* Re: [PATCHv4 1/1] HID: add BETOP game controller force feedback support
From: Jiri Kosina @ 2014-12-22 13:43 UTC (permalink / raw)
To: Huang Bo; +Cc: linux-input, linux-kernel
In-Reply-To: <547D54FC.3080202@163.com>
On Tue, 2 Dec 2014, Huang Bo wrote:
> From: Huang Bo <huangbobupt@163.com>
>
> Adds force feedback support for BETOP USB game controllers.
> These devices are mass produced in China.
>
> Signed-off-by: Huang Bo <huangbobupt@163.com>
Applied to for-3.20/betop.
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH 1/3] HID: rmi: Support non rmi devices by passing events to hid-input
From: Jiri Kosina @ 2014-12-22 13:24 UTC (permalink / raw)
To: Andrew Duggan; +Cc: linux-input, linux-kernel, Benjamin Tissoires
In-Reply-To: <1419029143-20484-1-git-send-email-aduggan@synaptics.com>
On Fri, 19 Dec 2014, Andrew Duggan wrote:
> Allowing hid-rmi to bind to non rmi devices allows us to support composite USB
> devices which contain several HID devices one of which is a HID touchpad.
> Since all of the devices have the same VID and PID we can add the device
> to the hid_have_special_driver list and have hid-rmi handle all of the devices.
> Then hid-rmi's probe can look for the rmi specific HID report IDs and decide if
> it should handle the device as a rmi device or simply report that the events
> needs additional processing.
>
> Signed-off-by: Andrew Duggan <aduggan@synaptics.com>
> ---
> This patch series is my second attempt at getting the hid-rmi driver working on
> the Razer Blade 14 based on Benjamin's comments. I decided to break it up into
> three separate patches. This one allows hid-rmi to bind to all of the devices.
> Instead of adding a quirk I just look at the report IDs to see if it should
> do rmi or not.
I have now applied 1/3, and waiting for v2 once you sort out with Benjamin
the comments he had.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* [Question : drivers/input ] Fixing Event Filter Mechanism in input subsystem
From: Anshul Garg @ 2014-12-22 13:13 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: anshul.g@samsung.com, linux-input
Dear Mr. Dmitry and Linux Community,
I am Anshul Garg working on Linux Kernel from last 2 years .
I have one query regarding event filter mechanism in input subsystem.
Can you please help in answering my query as below:
=====================================================
In function input_pass_values in input.c file , input core sends all
events to each handler associated with
the input device ,
rcu_read_lock();
handle = rcu_dereference(dev->grab);
if (handle) {
count = input_to_handler(handle, vals, count);
} else {
list_for_each_entry_rcu(handle, &dev->h_list, d_node)
if (handle->open)
count = input_to_handler(handle, vals, count);
}
after this in input_to_handler function events are filtered and sent
to the handler.
for (v = vals; v != vals + count; v++) {
if (handler->filter &&
handler->filter(handle, v->type, v->code, v->value))
continue;
if (end != v)
*end = *v;
end++;
}
But as per previous event filter mechanism all the events should be
parsed from all
handlers after that remaining events should be sent to handlers list.
And in comments also its mentioned as
/*
* Pass event first through all filters and then, if event has not been
* filtered out, through all open handles.*/
So current approach to filter events seems to be incorrect.
Please help to clarify my query.
I have prepared one patch with new event filter mechanism which will
first filter all events from attached handlers then pass the remaining
events after being filtered
through all handlers unlike current implementation.
Once My query is resolved , I will send the patch.
Thanks
Anshul Garg
+91-9899777351
^ permalink raw reply
* [PATCH] Input: regulator-haptic: Make regulator_haptic_set_voltage call regulator_haptic_toggle
From: Axel Lin @ 2014-12-22 4:47 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Pankaj Dubey, Chanwoo Choi, Hyunhee Kim, Kyungmin Park,
Jaewon Kim, linux-input
All the use cases in this driver has a regulator_haptic_toggle() call after
regulator_haptic_set_voltage(). So make regulator_haptic_set_voltage() call
regulator_haptic_toggle() to simplify the code.
Signed-off-by: Axel Lin <axel.lin@ingics.com>
---
drivers/input/misc/regulator-haptic.c | 16 ++++------------
1 file changed, 4 insertions(+), 12 deletions(-)
diff --git a/drivers/input/misc/regulator-haptic.c b/drivers/input/misc/regulator-haptic.c
index 9426221..5b18de3 100644
--- a/drivers/input/misc/regulator-haptic.c
+++ b/drivers/input/misc/regulator-haptic.c
@@ -76,6 +76,8 @@ static int regulator_haptic_set_voltage(struct regulator_haptic *haptic,
return error;
}
+ regulator_haptic_toggle(haptic, !!magnitude);
+
return 0;
}
@@ -84,7 +86,6 @@ static void regulator_haptic_work(struct work_struct *work)
struct regulator_haptic *haptic = container_of(work,
struct regulator_haptic, work);
unsigned int magnitude;
- int error;
mutex_lock(&haptic->mutex);
@@ -93,12 +94,7 @@ static void regulator_haptic_work(struct work_struct *work)
magnitude = ACCESS_ONCE(haptic->magnitude);
- error = regulator_haptic_set_voltage(haptic, magnitude);
- if (error)
- goto out;
-
- regulator_haptic_toggle(haptic, magnitude != 0);
-
+ regulator_haptic_set_voltage(haptic, magnitude);
out:
mutex_unlock(&haptic->mutex);
}
@@ -123,7 +119,6 @@ static void regulator_haptic_close(struct input_dev *input)
cancel_work_sync(&haptic->work);
regulator_haptic_set_voltage(haptic, 0);
- regulator_haptic_toggle(haptic, false);
}
static int __maybe_unused
@@ -225,7 +220,6 @@ static int __maybe_unused regulator_haptic_suspend(struct device *dev)
return error;
regulator_haptic_set_voltage(haptic, 0);
- regulator_haptic_toggle(haptic, false);
haptic->suspended = true;
@@ -245,10 +239,8 @@ static int __maybe_unused regulator_haptic_resume(struct device *dev)
haptic->suspended = false;
magnitude = ACCESS_ONCE(haptic->magnitude);
- if (magnitude) {
+ if (magnitude)
regulator_haptic_set_voltage(haptic, magnitude);
- regulator_haptic_toggle(haptic, true);
- }
mutex_unlock(&haptic->mutex);
--
1.9.1
^ permalink raw reply related
* Re: [PATCHv3 0/5] ARM:sunxi:ps2 Added support for A10/A20 ps2 controller.
From: Vishnu Patekar @ 2014-12-22 3:30 UTC (permalink / raw)
To: Chen-Yu Tsai
Cc: Hans de Goede, mark.rutland@arm.com, devicetree@vger.kernel.org,
jdelvare@suse.de, linux@arm.linux.org.uk, pawel.moll@arm.com,
ijc+devicetree@hellion.org.uk, benh@kernel.crashing.org,
Dmitry Torokhov, linux-kernel@vger.kernel.org,
ralf@linux-mips.org, robh+dt@kernel.org, msalter@redhat.com,
linux-input@vger.kernel.org, Grant Likely, Kumar Gala,
maxime.ripard@free-electrons.com, linux-arm-kernel
In-Reply-To: <CAGb2v659jEj7cxPCu1UNPb-p6iaH6Sjcp4LCgsBOyBh-odSUhw@mail.gmail.com>
Sorry for delayed response.
Thanks, Chen-Yu.
So, I'll keep ps2 enabled for Lime2 board without any comment.
On Mon, Dec 15, 2014 at 9:11 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> Hi,
>
> On Mon, Dec 15, 2014 at 11:13 PM, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>>
>> On 15-12-14 15:13, Vishnu Patekar wrote:
>>>
>>> Hi,
>>>
>>> On Sun, Dec 14, 2014 at 2:31 PM, Hans de Goede <hdegoede@redhat.com>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 13-12-14 21:01, Vishnu Patekar wrote:
>>>>>
>>>>>
>>>>> Hello Hans,
>>>>> Please find my comments inlined.
>>>>>
>>>>> On 12/13/14, Hans de Goede <hdegoede@redhat.com> wrote:
>>>>>>
>>>>>>
>>>>>> Hi VishnuPatekar,
>>>>>>
>>>>>> The patch mangling for this set seems to have gone a bit wrong I'm
>>>>>> afraid
>>>>>
>>>>>
>>>>>
>>>>> No, this time I've corrected it. Infact, last version of patch did not
>>>>> used the status bit error macros.
>>>>>
>>>>>> a lot of the patches have my fixup commit messages (which should have
>>>>>> disappeared when squashing in the patches), please replace those by
>>>>>> proper
>>>>>> commit messages describing what the patch actually does.
>>>>>
>>>>>
>>>>> Yes, [PATCHv3 3/5] uses fixup. I'll correct it.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Also the adding of the commented nodes for the lime2 seems to be gone
>>>>>> entirely
>>>>>> from the set, instead now only a comment about the conflict with the
>>>>>> hdmi
>>>>>> pins is added, but it is above the i2c node instead of above a ps2
>>>>>> node.
>>>>>>
>>>>> Maxime's suggested that we should not add commented nodes specially
>>>>> when its trivial to apply. And just note saying ps20 pins conflict
>>>>> with HDMI.
>>>>
>>>>
>>>>
>>>> Ah, I see.
>>>>
>>>>> Should I remove the this comment as well?
>>>>> Or
>>>>> Put this note in start of DTS file?
>>>>
>>>>
>>>>
>>>> The comment should be added to where the pinctrl bits are, not to the
>>>> lime2
>>>> file, ps0 will conflict with hdmi on all boards.
>>>
>>>
>>> Well, In that case,PS2_0 pins conflicts with HDMI, PS2_1 pins
>>> conflicts with LCD. Every pin has multiplexing.
>>
>>
>> Almost every A10 board has a hdmi connector, and only the hdmi ddc pins
>> are multiplexed, so this is sort of special, but yes if we do not have
>> the commented nodes in the dts file, then this comment can be dropped too
>> I guess.
>
> All the HDMI pins have dedicated pins. In addition, the DDC pins are
> multiplexed. On the Lime, the dedicated pins (ball # R23, R22) are
> used. I just checked the schematics. There should be no conflict.
>
> ChenYu
^ permalink raw reply
* Re: randconfig build error with next-20141219, in drivers/input/misc/regulator-haptic.c
From: Dmitry Torokhov @ 2014-12-22 3:02 UTC (permalink / raw)
To: Jim Davis
Cc: Stephen Rothwell, linux-next, linux-kernel, linux-input,
Grant Likely, Rob Herring
In-Reply-To: <CA+r1Zhh3u_JMnvvYaXD81ew--H_t9exuX-xvuNw8n=OPA-PWNA@mail.gmail.com>
On Fri, Dec 19, 2014 at 09:13:02AM -0700, Jim Davis wrote:
> Building with the attached random configuration file,
>
> drivers/input/misc/regulator-haptic.c: In function ‘regulator_haptic_probe’:
> drivers/input/misc/regulator-haptic.c:184:2: error: implicit
> declaration of function ‘devm_regulator_get_exclusive’
> [-Werror=implicit-function-declaration]
> haptic->regulator = devm_regulator_get_exclusive(&pdev->dev, "haptic");
> ^
> drivers/input/misc/regulator-haptic.c:184:20: warning: assignment makes pointer
> from integer without a cast [enabled by default]
> haptic->regulator = devm_regulator_get_exclusive(&pdev->dev, "haptic");
> ^
> cc1: some warnings being treated as errors
> make[3]: *** [drivers/input/misc/regulator-haptic.o] Error 1
Thanks, I'll add the missing dependency on CONFIG_REGULATOR.
--
Dmitry
^ permalink raw reply
* RE: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
From: Dudley Du @ 2014-12-22 2:56 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Jeremiah Mahler, rydberg@euromail.se, bleung@google.com,
David Solda, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20141222023959.GA30082@dtor-ws>
Got it.
Thanks, Dmitry.
Dudley
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: 2014?12?22? 10:40
> To: Dudley Du
> Cc: Jeremiah Mahler; rydberg@euromail.se; bleung@google.com; David Solda;
> linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
>
> Hi Dudley,
>
> On Mon, Dec 22, 2014 at 02:09:36AM +0000, Dudley Du wrote:
> > Thanks, Dmitry and Jeremiah,
> >
> > I reproduced this issue in my side when putting fingers on trackpad when system
> booting up.
> > It only happened on gen3 trackpad device.
> > The root cause is, for gen3 TP, the cyapa->ops->sort_empty_output_data is not
> set, so when cyapa->input is not set,
> > the interrupt process should be passed, but since the logica error, it's not, so this
> issue happen.
> >
> > The fix code should be as below.
> > I will correct it and resubmited the patches.
>
> Please hold off resubmitting the patches just yet, let me go over the
> last version you posted.
>
> Thanks!
>
>
> --
> Dmitry
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
^ permalink raw reply
* Re: [PATCH v3] input: Add new sun4i-lradc-keys driver
From: Dmitry Torokhov @ 2014-12-22 2:51 UTC (permalink / raw)
To: Hans de Goede
Cc: Maxime Ripard, linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, devicetree,
linux-sunxi-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <54955315.3030603-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
On Sat, Dec 20, 2014 at 11:44:37AM +0100, Hans de Goede wrote:
> Hi Dmitry,
>
> On 18-12-14 18:51, Dmitry Torokhov wrote:
> >Hi Hans,
> >
> >On Thu, Dec 18, 2014 at 11:23:13AM +0100, Hans de Goede wrote:
> >>Allwinnner sunxi SoCs have a low resolution adc (called lradc) which is
> >>specifically designed to have various (tablet) keys (ie home, back, search,
> >>etc). attached to it using a resistor network. This adds a driver for this.
> >>
> >>There are 2 channels, currently this driver only supports chan0 since there
> >>are no boards known to use chan1.
> >>
> >>This has been tested on an olimex a10s-olinuxino-micro, a13-olinuxino, and
> >>a20-olinuxino-micro.
> >>
> >>Signed-off-by: Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> >>--
> >>Changes in v2:
> >>-Change devicetree bindings to use a per key subnode, like gpio-keys does
> >>Changes in v3:
> >>-Handle keyup irq flag before irqdown, in case we get both at once
> >
> >Thank you for making changes. Can you please tell me if the driver still
> >works if you drop the patch below on top of it? The changes are:
> >
> >- split DT parsing into a separate function;
> >- make sure keymap is not empty;
> >- change 'ret' variable to 'error';
>
> The proposed changes look good, and I've given them a test-spin and everything
> still works fine.
Excellent, folded and applied.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
From: Dmitry Torokhov @ 2014-12-22 2:39 UTC (permalink / raw)
To: Dudley Du
Cc: Jeremiah Mahler, rydberg@euromail.se, bleung@google.com,
David Solda, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <BN1PR06MB0701C428956C2E7F7A1DD76D1560@BN1PR06MB070.namprd06.prod.outlook.com>
Hi Dudley,
On Mon, Dec 22, 2014 at 02:09:36AM +0000, Dudley Du wrote:
> Thanks, Dmitry and Jeremiah,
>
> I reproduced this issue in my side when putting fingers on trackpad when system booting up.
> It only happened on gen3 trackpad device.
> The root cause is, for gen3 TP, the cyapa->ops->sort_empty_output_data is not set, so when cyapa->input is not set,
> the interrupt process should be passed, but since the logica error, it's not, so this issue happen.
>
> The fix code should be as below.
> I will correct it and resubmited the patches.
Please hold off resubmitting the patches just yet, let me go over the
last version you posted.
Thanks!
--
Dmitry
^ permalink raw reply
* RE: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
From: Dudley Du @ 2014-12-22 2:09 UTC (permalink / raw)
To: Dmitry Torokhov, Jeremiah Mahler, rydberg@euromail.se,
bleung@google.com, David Solda, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20141220073154.GB4637@dtor-ws>
Thanks, Dmitry and Jeremiah,
I reproduced this issue in my side when putting fingers on trackpad when system booting up.
It only happened on gen3 trackpad device.
The root cause is, for gen3 TP, the cyapa->ops->sort_empty_output_data is not set, so when cyapa->input is not set,
the interrupt process should be passed, but since the logica error, it's not, so this issue happen.
The fix code should be as below.
I will correct it and resubmited the patches.
Code to fix this issue.
@@ -585,9 +585,10 @@ static irqreturn_t cyapa_irq(int irq, void *dev_id)
/* Interrupt event maybe from trackpad device input reporting. */
if (cont && cyapa->ops->irq_handler) {
/* Still in probling or in firware image udpating or reading. */
- if (!cyapa->input && cyapa->ops->sort_empty_output_data) {
- cyapa->ops->sort_empty_output_data(cyapa,
- NULL, NULL, NULL);
+ if (!cyapa->input) {
+ if (cyapa->ops->sort_empty_output_data)
+ cyapa->ops->sort_empty_output_data(cyapa,
+ NULL, NULL, NULL);
goto out;
}
Thanks,
Dudley
> -----Original Message-----
> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
> Sent: 2014?12?20? 15:32
> To: Jeremiah Mahler; Dudley Du; rydberg@euromail.se; bleung@google.com;
> David Solda; linux-input@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH v16 00/12] input: cyapa: instruction of cyapa patches
>
> On Fri, Dec 19, 2014 at 11:15:33PM -0800, Jeremiah Mahler wrote:
> > Dudley,
> >
> > On Thu, Dec 18, 2014 at 06:00:44PM +0800, Dudley Du wrote:
> > > V16 patches have below updates, details of other updates see history list:
> > [...]
> >
> > This version has problems. I am getting an oops (below) and then things
> > quit working and usually my machine hangs.
> >
> > [ 2.388284] input: HDA Intel PCH Headphone as
> /devices/pci0000:00/0000:00:1b.0/sound/card1/input10
> > [ 2.412938] FS-Cache: Netfs 'nfs' registered for caching
> > [ 2.427645] [drm] Initialized i915 1.6.0 20141121 for 0000:00:02.0 on minor 0
> > [ 2.428320] __add_probed_i2c_device failed to register device 1-4a
> > [ 2.428331] platform chromeos_laptop: Driver chromeos_laptop requests
> probe deferral
> > [ 2.429126] fbcon: inteldrmfb (fb0) is primary device
> > [ 2.449066] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000160
> > [ 2.449073] IP: [<ffffffff813f7b2b>] input_mt_sync_frame+0xb/0x60
>
> Sounds like we got an interrupts before we had a chance to initialize
> input device...
>
> Thanks.
>
> --
> Dmitry
This message and any attachments may contain Cypress (or its subsidiaries) confidential information. If it has been received in error, please advise the sender and immediately delete this message.
^ 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