* Re: [PATCH] HID: input: fix input sysfs path for hid devices
From: David Herrmann @ 2014-01-08 16:46 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Benjamin Tissoires, open list:HID CORE LAYER,
linux-kernel
In-Reply-To: <alpine.LNX.2.00.1401081724440.31628@pobox.suse.cz>
Hi
On Wed, Jan 8, 2014 at 5:26 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Wed, 8 Jan 2014, David Herrmann wrote:
>
>> >> > I think this is valuable because it will give a better understanding of the
>> >> > actual mapping hardware/inputs. Like a touchscreen with pen + touch will have
>> >> > the same hid parent, and I expect X/Wayland to be able to detect this at some
>> >> > point to keep the mapping correctly between the two input devices and the screen.
>> >> >
>> >> > I also need that for hid-replay, so that I can be sure which input is attached
>> >> > to which uhid device, and give up the heuristics I currently use.
>> >>
>> >> I was just wondering where we have multiple HID devices on a single
>> >> parent, but yeah, uhid is a good example. I actually have no
>> >> objections to this patch and it looks fine. But I cannot tell whether
>> >> anyone relies on this.
>> >>
>> >> I'd say we should give it a try.
>> >
>> > Agreed, let's take it for 3.14, and if anyone complains about breakage
>> > caused by this (which I don't expect), we'll revert to the previous state.
>>
>> You dropped the "Reviewed-by:" part in your commit-msg:
>> http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bbe3175408cde792fbaa5bd1e41e430ea9e4fb4f
>>
>> Not sure, whether you sometimes rebase your tree. If you do, you might
>> wanna fix it, otherwise, I don't care. Just wanted to point it out.
>
> Gah, sorry for that. No idea what in my process ate the tag.
>
> I am really trying to make the tree non-rebasing. If you don't mind, I
> wouldn't take this as a reson to rebase.
>
> I can put you twice to some patch later to balance this out :p
>
> Thanks for understanding,
Haha, don't worry, just saw it during post-review and wanted to let you know.
Cheers
David
^ permalink raw reply
* Re: [PATCH] HID: input: fix input sysfs path for hid devices
From: Jiri Kosina @ 2014-01-08 16:26 UTC (permalink / raw)
To: David Herrmann
Cc: Benjamin Tissoires, Benjamin Tissoires, open list:HID CORE LAYER,
linux-kernel
In-Reply-To: <CANq1E4R4H5U6Hqv4ZWWj8cznf6gAbnScs9Cd61BGnH=Mtg1kpA@mail.gmail.com>
On Wed, 8 Jan 2014, David Herrmann wrote:
> >> > I think this is valuable because it will give a better understanding of the
> >> > actual mapping hardware/inputs. Like a touchscreen with pen + touch will have
> >> > the same hid parent, and I expect X/Wayland to be able to detect this at some
> >> > point to keep the mapping correctly between the two input devices and the screen.
> >> >
> >> > I also need that for hid-replay, so that I can be sure which input is attached
> >> > to which uhid device, and give up the heuristics I currently use.
> >>
> >> I was just wondering where we have multiple HID devices on a single
> >> parent, but yeah, uhid is a good example. I actually have no
> >> objections to this patch and it looks fine. But I cannot tell whether
> >> anyone relies on this.
> >>
> >> I'd say we should give it a try.
> >
> > Agreed, let's take it for 3.14, and if anyone complains about breakage
> > caused by this (which I don't expect), we'll revert to the previous state.
>
> You dropped the "Reviewed-by:" part in your commit-msg:
> http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bbe3175408cde792fbaa5bd1e41e430ea9e4fb4f
>
> Not sure, whether you sometimes rebase your tree. If you do, you might
> wanna fix it, otherwise, I don't care. Just wanted to point it out.
Gah, sorry for that. No idea what in my process ate the tag.
I am really trying to make the tree non-rebasing. If you don't mind, I
wouldn't take this as a reson to rebase.
I can put you twice to some patch later to balance this out :p
Thanks for understanding,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Gaëtan Carlier @ 2014-01-08 12:58 UTC (permalink / raw)
To: Peter Meerwald
Cc: linux-input, linux-arm-kernel@lists.infradead.org, Joonyoung Shim
In-Reply-To: <alpine.DEB.2.01.1401081344451.1454@pmeerw.net>
Hello,
> just ask harder; I got it from them
I am going to ask to another dealer.
> you need to understand the object table and see what object leads to the
> invalid object message; there is some mismatch between the driver and the
> chip
But you have to admit that without Protocol Guide, it is a little bit
harder ;-)
> if I remember correctly, the mxt224 does periodic interrupts (200ms?)
> when something is wrong with the config
That's explain why I previously saw Interrupts running free (100ms or
200ms).
Thank you,
Gaëtan Carlier
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Peter Meerwald @ 2014-01-08 12:50 UTC (permalink / raw)
To: Gaëtan Carlier
Cc: linux-input, linux-arm-kernel@lists.infradead.org, Joonyoung Shim
In-Reply-To: <52CD4376.50305@gmail.com>
Hello,
> I am in Belgium and we deal with Gleichmann & Co. Electronics in Germany to
> have their devkit (SMT-C-T10). I have signed a NDA with them to have MXT224
> protocol guide but they never send me Protocol Guide.
> I will try another distributor.
just ask harder; I got it from them
> > something goes wrong in the initialization; the object table of the
> > chip doesn't match the register data fed in -- the mxt224 can be a bitch
> > and play dead
> So what can I do ? Maybe a problem with the embedded firmware that need an
> update (atmel_mxt_ts 0-004b: Family ID: 129 Variant ID: 1 Major.Minor.Build:
> 2.0.AB)
you need to understand the object table and see what object leads to the
invalid object message; there is some mismatch between the driver and the
chip
> When I do cat /proc/interrupts and I short-circuit /CHG to ground, number
> increases so low-level handling of interrupt is working.
if I remember correctly, the mxt224 does periodic interrupts (200ms?)
when something is wrong with the config
regards, p.
--
Peter Meerwald
+43-664-2444418 (mobile)
^ permalink raw reply
* Re: [PATCH v1 1/2] Input: gpio_keys - use dev instead of pdev in gpio_keys_setup_key()
From: Andy Shevchenko @ 2014-01-08 12:42 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input
In-Reply-To: <1386684237-31013-1-git-send-email-andriy.shevchenko@linux.intel.com>
On Tue, 2013-12-10 at 16:03 +0200, Andy Shevchenko wrote:
> The platform device is not used in gpio_keys_setup_key(). This patch
> substitutes it by struct device.
Dmitry do you have any comments on the series? Could it be applied then?
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
> ---
> drivers/input/keyboard/gpio_keys.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/input/keyboard/gpio_keys.c b/drivers/input/keyboard/gpio_keys.c
> index 2db1324..209d4c6 100644
> --- a/drivers/input/keyboard/gpio_keys.c
> +++ b/drivers/input/keyboard/gpio_keys.c
> @@ -424,13 +424,12 @@ out:
> return IRQ_HANDLED;
> }
>
> -static int gpio_keys_setup_key(struct platform_device *pdev,
> +static int gpio_keys_setup_key(struct device *dev,
> struct input_dev *input,
> struct gpio_button_data *bdata,
> const struct gpio_keys_button *button)
> {
> const char *desc = button->desc ? button->desc : "gpio_keys";
> - struct device *dev = &pdev->dev;
> irq_handler_t isr;
> unsigned long irqflags;
> int irq, error;
> @@ -719,7 +718,7 @@ static int gpio_keys_probe(struct platform_device *pdev)
>
> input->name = pdata->name ? : pdev->name;
> input->phys = "gpio-keys/input0";
> - input->dev.parent = &pdev->dev;
> + input->dev.parent = dev;
> input->open = gpio_keys_open;
> input->close = gpio_keys_close;
>
> @@ -736,7 +735,7 @@ static int gpio_keys_probe(struct platform_device *pdev)
> const struct gpio_keys_button *button = &pdata->buttons[i];
> struct gpio_button_data *bdata = &ddata->data[i];
>
> - error = gpio_keys_setup_key(pdev, input, bdata, button);
> + error = gpio_keys_setup_key(dev, input, bdata, button);
> if (error)
> goto fail2;
>
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH] HID: input: fix input sysfs path for hid devices
From: David Herrmann @ 2014-01-08 12:33 UTC (permalink / raw)
To: Jiri Kosina
Cc: Benjamin Tissoires, Benjamin Tissoires, open list:HID CORE LAYER,
linux-kernel
In-Reply-To: <alpine.LNX.2.00.1312202335300.11949@pobox.suse.cz>
Hi Jiri
On Fri, Dec 20, 2013 at 11:36 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Thu, 19 Dec 2013, David Herrmann wrote:
>
>> <benjamin.tissoires@redhat.com> wrote:
>> > we used to set the parent of the input device as the parent of
>> > the hid bus. This was introduced when we created hid as a real bus, and
>> > to keep backward compatibility. Now, it's time to proper set the parent
>> > so that sysfs has an idea of which input device is attached to
>> > which hid device.
>> >
>> > Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
>> > ---
>> >
>> > Hi Jiri,
>> >
>> > well, the regression test did not showed anything bad, and a look at the hid
>> > drivers also showed that no drivers should be armed by that.
>> >
>> > I think this is valuable because it will give a better understanding of the
>> > actual mapping hardware/inputs. Like a touchscreen with pen + touch will have
>> > the same hid parent, and I expect X/Wayland to be able to detect this at some
>> > point to keep the mapping correctly between the two input devices and the screen.
>> >
>> > I also need that for hid-replay, so that I can be sure which input is attached
>> > to which uhid device, and give up the heuristics I currently use.
>>
>> I was just wondering where we have multiple HID devices on a single
>> parent, but yeah, uhid is a good example. I actually have no
>> objections to this patch and it looks fine. But I cannot tell whether
>> anyone relies on this.
>>
>> I'd say we should give it a try.
>
> Agreed, let's take it for 3.14, and if anyone complains about breakage
> caused by this (which I don't expect), we'll revert to the previous state.
You dropped the "Reviewed-by:" part in your commit-msg:
http://git.kernel.org/cgit/linux/kernel/git/jikos/hid.git/commit/?h=for-next&id=bbe3175408cde792fbaa5bd1e41e430ea9e4fb4f
Not sure, whether you sometimes rebase your tree. If you do, you might
wanna fix it, otherwise, I don't care. Just wanted to point it out.
Cheers
David
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Gaëtan Carlier @ 2014-01-08 12:24 UTC (permalink / raw)
To: Peter Meerwald
Cc: linux-input, linux-arm-kernel@lists.infradead.org, Joonyoung Shim
In-Reply-To: <alpine.DEB.2.01.1401081228580.1454@pmeerw.net>
On 01/08/2014 12:42 PM, Peter Meerwald wrote:
> you need to request them from the distributor I guess, they docs are
> pretty good
I am in Belgium and we deal with Gleichmann & Co. Electronics in Germany
to have their devkit (SMT-C-T10). I have signed a NDA with them to have
MXT224 protocol guide but they never send me Protocol Guide.
I will try another distributor.
> shouldn't this be 16/14?
You are right, I already try this and test it again but this does not
change anything.
> something goes wrong in the initialization; the object table of the
> chip doesn't match the register data fed in -- the mxt224 can be a bitch
> and play dead
So what can I do ? Maybe a problem with the embedded firmware that need
an update (atmel_mxt_ts 0-004b: Family ID: 129 Variant ID: 1
Major.Minor.Build: 2.0.AB)
When I do cat /proc/interrupts and I short-circuit /CHG to ground,
number increases so low-level handling of interrupt is working.
Thanks,
Gaëtan Carlier.
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Peter Meerwald @ 2014-01-08 11:42 UTC (permalink / raw)
To: Gaëtan Carlier
Cc: linux-input, linux-arm-kernel@lists.infradead.org, Joonyoung Shim
In-Reply-To: <52CD04F1.8090100@gmail.com>
> I have tried atmel_mxt_ts driver (original driver from kernel 3.6.0 and
> driver from linux-next/master branch copied to kernel 3.6.0) on i.MX27
> board. The capacitive glass used is a "GE Touch"
> SMT-F-057G007-B011-4:3-NP. It has 16 pads in X and 14 pads in Y. It is
> correctly detected (with one warning/error).
> Does someone has some informations or the protocol guide, please ?
you need to request them from the distributor I guess, they docs are
pretty good
> /* TSP */
> static struct mxt_platform_data mxt_platform_data = {
> .x_line = 18,
> .y_line = 11,
> .x_size = 480,
shouldn't this be 16/14?
> .y_size = 640,
> .blen = 0x1,
> .threshold = 0x28,
> .voltage = 2800000, /* 2.8V */
> .orient = MXT_DIAGONAL_COUNTER,
> .irqflags = IRQF_TRIGGER_FALLING,
> };
> atmel_mxt_ts 0-004b: No cfg data defined, skipping reg init
> atmel_mxt_ts 0-004b: Invalid object type
something goes wrong in the initialization; the object table of the
chip doesn't match the register data fed in -- the mxt224 can be a bitch
and play dead
regards, p.
--
Peter Meerwald
+43-664-2444418 (mobile)
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Gaëtan Carlier @ 2014-01-08 11:24 UTC (permalink / raw)
To: Alexander Shiyan
Cc: linux-input, linux-arm-kernel@lists.infradead.org, Joonyoung Shim
In-Reply-To: <1389171897.588258801@f329.i.mail.ru>
Hi,
On 01/08/2014 10:04 AM, Alexander Shiyan wrote:
> Do not forget about setup IOMUX for IRQ pin?
I don't think so. I follow the same canvas than PMIC_INT. I send my
email too fast. The init function was incomplete. Below all I do with
MXT_KEY (PB16) connected to /CHG pin of MXT224.
(Of course, PB16 (CSI_PIXCLK) is not used by another driver)
The problem is not interrupt in Kernel. It is MXT224 that does not send
it. /CHG pin stay High.
I can send you all source code of board declaration if you want.
Thanks a lot.
Gaëtan Carlier.
8---------------------------------------------------------
#define MXT_KEY IMX_GPIO_NR(2, 16)
static const int imx27gc_pins[] __initconst = {
/* UART1 */
PE12_PF_UART1_TXD,
PE13_PF_UART1_RXD,
PE14_PF_UART1_CTS,
PE15_PF_UART1_RTS,
/* UART3 */
PE8_PF_UART3_TXD,
PE9_PF_UART3_RXD,
PE10_PF_UART3_CTS,
PE11_PF_UART3_RTS,
/* FEC */
PD0_AIN_FEC_TXD0,
PD1_AIN_FEC_TXD1,
PD2_AIN_FEC_TXD2,
PD3_AIN_FEC_TXD3,
PD4_AOUT_FEC_RX_ER,
PD5_AOUT_FEC_RXD1,
PD6_AOUT_FEC_RXD2,
PD7_AOUT_FEC_RXD3,
PD8_AF_FEC_MDIO,
PD9_AIN_FEC_MDC,
PD10_AOUT_FEC_CRS,
PD11_AOUT_FEC_TX_CLK,
PD12_AOUT_FEC_RXD0,
PD13_AOUT_FEC_RX_DV,
PD14_AOUT_FEC_RX_CLK,
PD15_AOUT_FEC_COL,
PD16_AIN_FEC_TX_ER,
PF23_AIN_FEC_TX_EN,
/* CSPI2 */
PD22_PF_CSPI2_SCLK,
PD23_PF_CSPI2_MISO,
PD24_PF_CSPI2_MOSI,
SPI2_SS0 | GPIO_GPIO | GPIO_OUT,
/* I2C1 */
PD17_PF_I2C_DATA,
PD18_PF_I2C_CLK,
/* I2C2 */
PC5_PF_I2C2_SDA,
PC6_PF_I2C2_SCL,
/* PMIC INT */
PMIC_INT | GPIO_GPIO | GPIO_IN,
/* SLCD */
PA6_AIN_SLCDC_DAT0,
PA7_AIN_SLCDC_DAT1,
PA8_AIN_SLCDC_DAT2,
PA9_AIN_SLCDC_DAT3,
PA10_AIN_SLCDC_DAT4,
PA11_AIN_SLCDC_DAT5,
PA12_AIN_SLCDC_DAT6,
PA13_AIN_SLCDC_DAT7,
PA25_AIN_SLCDC_CLS, /* D/C */
PA26_AIN_SLCDC_CS,
PA27_AIN_SLCDC_CLK, /* E/RD */
SLCDC_RESET | GPIO_GPIO | GPIO_OUT,
SLCDC_BL_POWER | GPIO_GPIO | GPIO_OUT,
SLCDC_RW | GPIO_GPIO | GPIO_OUT, /* only for manual reading operation */
/* MXT */
MXT_KEY | GPIO_GPIO | GPIO_IN, /* Key */
/* SSI4 */
PC16_PF_SSI4_FS,
PC17_PF_SSI4_RXD,
PC18_PF_SSI4_TXD,
PC19_PF_SSI4_CLK,
/* Flash Led */
FLASH_ENABLE | GPIO_GPIO | GPIO_OUT,
THT_ENABLE | GPIO_GPIO | GPIO_OUT,
HP_ENABLE | GPIO_GPIO | GPIO_OUT,
HEATING_ENABLE | GPIO_GPIO | GPIO_OUT,
BTNLIGHT_ENABLE | GPIO_GPIO | GPIO_OUT,
/* GPIO KEY */
GPIO_KEY1 | GPIO_GPIO | GPIO_IN,
GPIO_KEY2 | GPIO_GPIO | GPIO_IN,
GPIO_KEY3 | GPIO_GPIO | GPIO_IN,
};
static void __init imx27gc_init(void)
{
mxc_gpio_setup_multiple_pins(imx27gc_pins, ARRAY_SIZE(imx27gc_pins),
"imx27gc");
...
imx27gc_i2c0_devices[0].irq = gpio_to_irq(MXT_KEY);
i2c_register_board_info(0, imx27gc_i2c0_devices,
ARRAY_SIZE(imx27gc_i2c0_devices));
imx27_add_imx_i2c(0, &imx27gc_i2c0_data);
....
}
8---------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Information about Atmel MXT224
From: Alexander Shiyan @ 2014-01-08 9:04 UTC (permalink / raw)
To: Gaëtan Carlier
Cc: Joonyoung Shim, linux-arm-kernel@lists.infradead.org, linux-input
In-Reply-To: <52CD04F1.8090100@gmail.com>
Среда, 8 января 2014, 8:57 +01:00 от Gaëtan Carlier <gcembed@gmail.com>:
> Hello,
> I have tried atmel_mxt_ts driver (original driver from kernel 3.6.0 and
> driver from linux-next/master branch copied to kernel 3.6.0) on i.MX27
> board. The capacitive glass used is a "GE Touch"
> SMT-F-057G007-B011-4:3-NP. It has 16 pads in X and 14 pads in Y. It is
> correctly detected (with one warning/error).
> The power supply of VDD and AVDD is 2.8V. AVDD will be raised later to 3.3V.
> When I push on glass, nothing occurs in evetst nor on /CHG pin of MXT224.
Do not forget about setup IOMUX for IRQ pin?
---
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: am335x: IIO/ADC fixes if used together with TSC, v2
From: Lee Jones @ 2014-01-08 8:08 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Sebastian Andrzej Siewior, Samuel Ortiz, Jonathan Cameron,
Zubair Lutfullah, Felipe Balbi, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140108080359.GA16527-WlK9ik9hQGAhIp7JRqBPierSzoNAToWh@public.gmane.org>
> > Dmitry, Jonathan,
> >
> > This is for you.
> >
> > The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
> >
> > Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
> >
> > are available in the git repository at:
> >
> > git://git.linaro.org/people/ljones/mfd.git tags/ib-iio-input-3.13-1
> >
> > for you to fetch changes up to 7ca6740cd1cd410828a01151a044b51910d06eff:
> >
> > mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization (2014-01-07 08:45:00 +0000)
> >
> > ----------------------------------------------------------------
> > Immutable branch for IIO and Input
> >
> > ----------------------------------------------------------------
> > Sebastian Andrzej Siewior (5):
> > iio: ti_am335x_adc: Adjust the closing bracket in tiadc_read_raw()
> > mfd: ti_am335x_tscadc: Make am335x_tsc_se_update() local
> > mfd: ti_am335x_tscadc: Don't read back REG_SE
> > mfd: ti_am335x: Drop am335x_tsc_se_update() from resume path
> > mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization
> >
> > drivers/iio/adc/ti_am335x_adc.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++-------------------
> > drivers/input/touchscreen/ti_am335x_tsc.c | 4 ++--
> > drivers/mfd/ti_am335x_tscadc.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
> > include/linux/mfd/ti_am335x_tscadc.h | 8 ++++++--
> > 4 files changed, 117 insertions(+), 34 deletions(-)
>
> I do not have any pending changes to ti_am335x_tsc.c so it can all go
> through Jonathan's tree.
Well the patches are going through my tree, but in case either of you
have any changes to the above files you can merge this and Git will do
the rest during the merge-window. If neither of you do then no need to
pull. :)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: am335x: IIO/ADC fixes if used together with TSC, v2
From: Dmitry Torokhov @ 2014-01-08 8:03 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Andrzej Siewior, Samuel Ortiz, Jonathan Cameron,
Zubair Lutfullah, Felipe Balbi, linux-iio-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20140107085456.GD3182@lee--X1>
On Tue, Jan 07, 2014 at 08:54:56AM +0000, Lee Jones wrote:
> Dmitry, Jonathan,
>
> This is for you.
>
> The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:
>
> Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)
>
> are available in the git repository at:
>
> git://git.linaro.org/people/ljones/mfd.git tags/ib-iio-input-3.13-1
>
> for you to fetch changes up to 7ca6740cd1cd410828a01151a044b51910d06eff:
>
> mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization (2014-01-07 08:45:00 +0000)
>
> ----------------------------------------------------------------
> Immutable branch for IIO and Input
>
> ----------------------------------------------------------------
> Sebastian Andrzej Siewior (5):
> iio: ti_am335x_adc: Adjust the closing bracket in tiadc_read_raw()
> mfd: ti_am335x_tscadc: Make am335x_tsc_se_update() local
> mfd: ti_am335x_tscadc: Don't read back REG_SE
> mfd: ti_am335x: Drop am335x_tsc_se_update() from resume path
> mfd: input: iio: ti_amm335x: Rework TSC/ADC synchronization
>
> drivers/iio/adc/ti_am335x_adc.c | 68 +++++++++++++++++++++++++++++++++++++++++++++++++-------------------
> drivers/input/touchscreen/ti_am335x_tsc.c | 4 ++--
> drivers/mfd/ti_am335x_tscadc.c | 71 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-----------
> include/linux/mfd/ti_am335x_tscadc.h | 8 ++++++--
> 4 files changed, 117 insertions(+), 34 deletions(-)
I do not have any pending changes to ti_am335x_tsc.c so it can all go
through Jonathan's tree.
Thanks.
--
Dmitry
^ permalink raw reply
* Information about Atmel MXT224
From: Gaëtan Carlier @ 2014-01-08 7:57 UTC (permalink / raw)
To: linux-input, linux-arm-kernel@lists.infradead.org; +Cc: Joonyoung Shim
Hello,
I have tried atmel_mxt_ts driver (original driver from kernel 3.6.0 and
driver from linux-next/master branch copied to kernel 3.6.0) on i.MX27
board. The capacitive glass used is a "GE Touch"
SMT-F-057G007-B011-4:3-NP. It has 16 pads in X and 14 pads in Y. It is
correctly detected (with one warning/error).
The power supply of VDD and AVDD is 2.8V. AVDD will be raised later to 3.3V.
When I push on glass, nothing occurs in evetst nor on /CHG pin of MXT224.
Does someone has some informations or the protocol guide, please ?
Thanks a lot for your help.
Gaëtan Carlier.
Below some code and logs.
Here is my initialization :
8---------------------------------------------------------
/* TSP */
static struct mxt_platform_data mxt_platform_data = {
.x_line = 18,
.y_line = 11,
.x_size = 480,
.y_size = 640,
.blen = 0x1,
.threshold = 0x28,
.voltage = 2800000, /* 2.8V */
.orient = MXT_DIAGONAL_COUNTER,
.irqflags = IRQF_TRIGGER_FALLING,
};
static struct i2c_board_info imx27gc_i2c0_devices[] = {
{
I2C_BOARD_INFO("atmel_mxt_ts", 0x4b),
.platform_data = &mxt_platform_data,
/* irq number is run-time assigned */
},
/* more devices can be added using expansion connectors */
};
static void __init dvip01_init(void)
{
dvip01_i2c0_devices[0].irq = gpio_to_irq(MXT_KEY);
}
8---------------------------------------------------------
Here is log of start-up:
8---------------------------------------------------------
atmel_mxt_ts 0-004b: Type 37 Start 106 Size 130 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 44 Start 236 Size 1 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 5 Start 237 Size 9 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 6 Start 246 Size 6 Instances 1 ReportIDs
1 : 1
atmel_mxt_ts 0-004b: Type 38 Start 252 Size 8 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 7 Start 260 Size 3 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 8 Start 263 Size 10 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 9 Start 273 Size 35 Instances 1 ReportIDs
2 : 11
atmel_mxt_ts 0-004b: Type 18 Start 308 Size 2 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 19 Start 310 Size 6 Instances 1 ReportIDs
12 : 12
atmel_mxt_ts 0-004b: Type 25 Start 316 Size 6 Instances 1 ReportIDs
13 : 13
atmel_mxt_ts 0-004b: Type 42 Start 322 Size 8 Instances 1 ReportIDs
14 : 14
atmel_mxt_ts 0-004b: Type 46 Start 330 Size 9 Instances 1 ReportIDs
15 : 15
atmel_mxt_ts 0-004b: Type 47 Start 339 Size 10 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: Type 48 Start 349 Size 54 Instances 1 ReportIDs
16 : 16
atmel_mxt_ts 0-004b: Type 55 Start 403 Size 4 Instances 1 ReportIDs
0 : 0
atmel_mxt_ts 0-004b: No cfg data defined, skipping reg init
atmel_mxt_ts 0-004b: Invalid object type
atmel_mxt_ts 0-004b: Family ID: 129 Variant ID: 1 Major.Minor.Build: 2.0.AB
atmel_mxt_ts 0-004b: Matrix X Size: 16 Matrix Y Size: 14 Object Num: 16
input: Atmel maXTouch Touchscreen as
/devices/platform/imx-i2c.0/i2c-0/0-004b/input/input0
8---------------------------------------------------------
Here is evtest information :
8---------------------------------------------------------
Input driver version is 1.0.1evdev: (EVIOCGBIT): Suspicious buffer size
511, limiting output to 64 bytes. See http://userweb.kernel.org/~dtorl
Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0
Input device name: "Atmel maXTouch Touchscreen"
Supported events:
Event type 0 (Sync)
Event type 1 (Key)
Event code 330 (Touch)
Event type 3 (Absolute)
Event code 0 (X)
Value 0
Min 0
Max 479
Event code 1 (Y)
Value 0
Min 0
Max 639
Event code 24 (Pressure)
Value 0
Min 0
Max 255
Event code 47 (?)
Value 0
Min 0
Max 9
Event code 48 (?)
Value 0
Min 0
Max 255
Event code 53 (?)
Value 0
Min 0
Max 479
Event code 54 (?)
Value 0
Min 0
Max 639
Event code 57 (?)
Value 0
Min 0
Max 65535
Event code 58 (?)
Value 0
Min 0
Max 255
Testing ... (interrupt to exit)
8---------------------------------------------------------
Here is /proc/interrupts:
8---------------------------------------------------------
128: 0 gpio-mxc atmel_mxt_ts
8---------------------------------------------------------
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] input synaptics-rmi4: move rmi_f01 query register parsing to its own function
From: Christopher Heiny @ 2014-01-08 1:02 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
In the near future, query register parsing is going to get a lot more
complicated. It's also going to be needed by the reflash code. Now is the
time to move this from the F01 initialization into its own function,
while the code is still fairly simple.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_f01.c | 71 +++++++++++++++++++++++++++-----------------
1 file changed, 43 insertions(+), 28 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index d547633..1cb11ea 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -167,6 +167,46 @@ static int rmi_f01_alloc_memory(struct rmi_function *fn,
return 0;
}
+static int rmi_f01_read_properties(struct rmi_device *rmi_dev,
+ u16 query_base_addr,
+ struct f01_basic_properties *props)
+{
+ u8 basic_query[RMI_F01_BASIC_QUERY_LEN];
+ int error;
+
+ error = rmi_read_block(rmi_dev, query_base_addr,
+ basic_query, sizeof(basic_query));
+ if (error < 0) {
+ dev_err(&rmi_dev->dev, "Failed to read device query registers.\n");
+ return error;
+ }
+
+ /* Now parse what we got */
+ props->manufacturer_id = basic_query[0];
+
+ props->has_lts = basic_query[1] & RMI_F01_QRY1_HAS_LTS;
+ props->has_adjustable_doze =
+ basic_query[1] & RMI_F01_QRY1_HAS_ADJ_DOZE;
+ props->has_adjustable_doze_holdoff =
+ basic_query[1] & RMI_F01_QRY1_HAS_ADJ_DOZE_HOFF;
+
+ snprintf(props->dom, sizeof(props->dom),
+ "20%02x%02x%02x",
+ basic_query[5] & RMI_F01_QRY5_YEAR_MASK,
+ basic_query[6] & RMI_F01_QRY6_MONTH_MASK,
+ basic_query[7] & RMI_F01_QRY7_DAY_MASK);
+
+ memcpy(props->product_id, &basic_query[11],
+ RMI_PRODUCT_ID_LENGTH);
+ props->product_id[RMI_PRODUCT_ID_LENGTH] = '\0';
+
+ props->productinfo =
+ ((basic_query[2] & RMI_F01_QRY2_PRODINFO_MASK) << 7) |
+ (basic_query[3] & RMI_F01_QRY2_PRODINFO_MASK);
+
+ return 0;
+}
+
static int rmi_f01_initialize(struct rmi_function *fn)
{
u8 temp;
@@ -176,7 +216,6 @@ static int rmi_f01_initialize(struct rmi_function *fn)
struct rmi_driver_data *driver_data = dev_get_drvdata(&rmi_dev->dev);
struct f01_data *data = fn->data;
struct rmi_device_platform_data *pdata = to_rmi_platform_data(rmi_dev);
- u8 basic_query[RMI_F01_BASIC_QUERY_LEN];
mutex_init(&data->control_mutex);
@@ -248,36 +287,12 @@ static int rmi_f01_initialize(struct rmi_function *fn)
return error;
}
- error = rmi_read_block(rmi_dev, fn->fd.query_base_addr,
- basic_query, sizeof(basic_query));
+ error = rmi_f01_read_properties(rmi_dev, fn->fd.query_base_addr,
+ &data->properties);
if (error < 0) {
- dev_err(&fn->dev, "Failed to read device query registers.\n");
+ dev_err(&fn->dev, "Failed to read F01 properties.\n");
return error;
}
-
- /* Now parse what we got */
- data->properties.manufacturer_id = basic_query[0];
-
- data->properties.has_lts = basic_query[1] & RMI_F01_QRY1_HAS_LTS;
- data->properties.has_adjustable_doze =
- basic_query[1] & RMI_F01_QRY1_HAS_ADJ_DOZE;
- data->properties.has_adjustable_doze_holdoff =
- basic_query[1] & RMI_F01_QRY1_HAS_ADJ_DOZE_HOFF;
-
- snprintf(data->properties.dom, sizeof(data->properties.dom),
- "20%02x%02x%02x",
- basic_query[5] & RMI_F01_QRY5_YEAR_MASK,
- basic_query[6] & RMI_F01_QRY6_MONTH_MASK,
- basic_query[7] & RMI_F01_QRY7_DAY_MASK);
-
- memcpy(data->properties.product_id, &basic_query[11],
- RMI_PRODUCT_ID_LENGTH);
- data->properties.product_id[RMI_PRODUCT_ID_LENGTH] = '\0';
-
- data->properties.productinfo =
- ((basic_query[2] & RMI_F01_QRY2_PRODINFO_MASK) << 7) |
- (basic_query[3] & RMI_F01_QRY2_PRODINFO_MASK);
-
dev_info(&fn->dev, "found RMI device, manufacturer: %s, product: %s\n",
data->properties.manufacturer_id == 1 ?
"Synaptics" : "unknown",
^ permalink raw reply related
* [PATCH] input synaptics-rmi4 trivial: rmi_f01.c tidy-up
From: Christopher Heiny @ 2014-01-08 0:07 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
This has two trivial changes:
1) use CONFIG_PM_SLEEP instead of CONFIG_PM for consistency.
2) Update the copyright date.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_f01.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/input/rmi4/rmi_f01.c b/drivers/input/rmi4/rmi_f01.c
index 628b082..d547633 100644
--- a/drivers/input/rmi4/rmi_f01.c
+++ b/drivers/input/rmi4/rmi_f01.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2012 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This program is free software; you can redistribute it and/or modify it
@@ -138,7 +138,7 @@ struct f01_data {
int irq_count;
int num_of_irq_regs;
-#ifdef CONFIG_PM
+#ifdef CONFIG_PM_SLEEP
bool suspended;
bool old_nosleep;
#endif
^ permalink raw reply related
* [PATCH] input synaptics-rmi4: Add rmi_version.h
From: Christopher Heiny @ 2014-01-07 21:37 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
Adds a file containing driver versioning #defines, allowing convenient
script-based tweakage of various versioning info. This is helpful to
differentiate various custom and/or development versions of the driver from
the main branch of the code.
Since rmi_driver.h changes as a result, its copyright date gets updated.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_driver.h | 5 ++---
drivers/input/rmi4/rmi_version.h | 24 ++++++++++++++++++++++++
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index df9ddd8..4438b20 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2013 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This program is free software; you can redistribute it and/or modify it
@@ -14,8 +14,7 @@
#include <linux/hrtimer.h>
#include <linux/ktime.h>
#include "rmi_bus.h"
-
-#define RMI_DRIVER_VERSION "1.6"
+#include "rmi_version.h"
#define SYNAPTICS_INPUT_DEVICE_NAME "Synaptics RMI4 Touch Sensor"
#define SYNAPTICS_VENDOR_ID 0x06cb
diff --git a/drivers/input/rmi4/rmi_version.h b/drivers/input/rmi4/rmi_version.h
new file mode 100644
index 0000000..ed001fa
--- /dev/null
+++ b/drivers/input/rmi4/rmi_version.h
@@ -0,0 +1,24 @@
+/*
+ * Copyright (c) 2014 Synaptics Incorporated
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#ifndef RMI_VERSION_H
+#define RMI_VERSION_H
+
+#define RMI_VERSION_MAJOR "1"
+#define RMI_VERSION_MINOR "19"
+#define RMI_VERSION_SUBMINOR "0"
+
+#define RMI_VERSION_BRANCH "synaptics-rmi4"
+#define RMI_EXTRA_NUMBER "0"
+#define RMI_EXTRA_STRING "0"
+
+#define RMI_DRIVER_VERSION RMI_VERSION_MAJOR "." \
+ RMI_VERSION_MINOR "." RMI_VERSION_SUBMINOR "-" \
+ RMI_EXTRA_STRING
+
+#endif
^ permalink raw reply related
* [PATCH] input synaptics-rmi4: PDT scan cleanup
From: Christopher Heiny @ 2014-01-07 20:33 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Linux Input, Christopher Heiny, Andrew Duggan, Vincent Huang,
Vivian Ly, Daniel Rosenberg, Jean Delvare, Joerie de Gram,
Linus Walleij, Benjamin Tissoires
Eliminates copy-paste code that handled scans of the Page Descriptor Table,
replacing it with a single PDT scan routine that invokes a callback function.
The scan routine is not static so that it can be used by the firmware update
code (under development, not yet submitted).
Updated the copyright dates while we were at it.
Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/rmi4/rmi_driver.c | 155 ++++++++++++++++++++--------------------
drivers/input/rmi4/rmi_driver.h | 6 +-
2 files changed, 83 insertions(+), 78 deletions(-)
diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
index eb790ff..cbd6485 100644
--- a/drivers/input/rmi4/rmi_driver.c
+++ b/drivers/input/rmi4/rmi_driver.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2013 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This driver provides the core support for a single RMI4-based device.
@@ -566,85 +566,80 @@ err_free_mem:
return error;
}
-/*
- * Scan the PDT for F01 so we can force a reset before anything else
- * is done. This forces the sensor into a known state, and also
- * forces application of any pending updates from reflashing the
- * firmware or configuration.
- *
- * We have to do this before actually building the PDT because the reflash
- * updates (if any) might cause various registers to move around.
- */
-static int rmi_initial_reset(struct rmi_device *rmi_dev)
+
+#define RMI_SCAN_CONTINUE 0
+#define RMI_SCAN_DONE 1
+
+static int rmi_initial_reset(struct rmi_device *rmi_dev,
+ void *clbk_ctx, struct pdt_entry *pdt_entry, int page)
{
- struct pdt_entry pdt_entry;
- int page;
- struct device *dev = &rmi_dev->dev;
- bool done = false;
- bool has_f01 = false;
- int i;
int retval;
- const struct rmi_device_platform_data *pdata =
- to_rmi_platform_data(rmi_dev);
- dev_dbg(dev, "Initial reset.\n");
+ if (pdt_entry->function_number == 0x01) {
+ u16 cmd_addr = page + pdt_entry->command_base_addr;
+ u8 cmd_buf = RMI_DEVICE_RESET_CMD;
+ const struct rmi_device_platform_data *pdata =
+ to_rmi_platform_data(rmi_dev);
- for (page = 0; (page <= RMI4_MAX_PAGE) && !done; page++) {
- u16 page_start = RMI4_PAGE_SIZE * page;
- u16 pdt_start = page_start + PDT_START_SCAN_LOCATION;
- u16 pdt_end = page_start + PDT_END_SCAN_LOCATION;
+ retval = rmi_write_block(rmi_dev, cmd_addr, &cmd_buf, 1);
+ if (retval < 0) {
+ dev_err(&rmi_dev->dev,
+ "Initial reset failed. Code = %d.\n", retval);
+ return retval;
+ }
+ mdelay(pdata->reset_delay_ms);
- done = true;
- for (i = pdt_start; i >= pdt_end; i -= RMI_PDT_ENTRY_SIZE) {
- retval = rmi_read_pdt_entry(rmi_dev, &pdt_entry, i);
- if (retval < 0)
- return retval;
+ return RMI_SCAN_DONE;
+ }
- if (RMI4_END_OF_PDT(pdt_entry.function_number))
- break;
- done = false;
+ /* F01 should always be on page 0. If we don't find it there, fail. */
+ return (!page) ? RMI_SCAN_CONTINUE : -ENODEV;
+}
- if (pdt_entry.function_number == 0x01) {
- u16 cmd_addr = page_start +
- pdt_entry.command_base_addr;
- u8 cmd_buf = RMI_DEVICE_RESET_CMD;
- retval = rmi_write_block(rmi_dev, cmd_addr,
- &cmd_buf, 1);
- if (retval < 0) {
- dev_err(dev, "Initial reset failed. Code = %d.\n",
- retval);
- return retval;
- }
- mdelay(pdata->reset_delay_ms);
- done = true;
- has_f01 = true;
- break;
- }
- }
- }
+static int rmi_create_functions_clbk(struct rmi_device *rmi_dev,
+ void *clbk_ctx, struct pdt_entry *entry, int page)
+{
+ int *irq_count = (int *)clbk_ctx;
- if (!has_f01) {
- dev_warn(dev, "WARNING: Failed to find F01 for initial reset.\n");
- return -ENODEV;
- }
+ return create_function(rmi_dev, entry, irq_count,
+ RMI4_PAGE_SIZE * page);
+}
+
+static int rmi_create_functions(struct rmi_device *rmi_dev)
+{
+ struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
+ struct device *dev = &rmi_dev->dev;
+ int irq_count = 0;
+ int retval;
+
+ // XXX need to make sure we create F01 first...
+ // XXX or do we? It might not be required in the updated structure.
+ retval = rmi_scan_pdt(rmi_dev, &irq_count, rmi_create_functions_clbk);
+
+ if (retval)
+ return retval;
+
+ // TODO: I think we need to count the IRQs before creating the
+ // functions.
+ data->irq_count = irq_count;
+ data->num_of_irq_regs = (irq_count + 7) / 8;
return 0;
}
-static int rmi_scan_pdt(struct rmi_device *rmi_dev)
+int rmi_scan_pdt(struct rmi_device *rmi_dev, void *ctx,
+ int (*rmi_pdt_scan_clbk)(struct rmi_device *rmi_dev,
+ void *clbk_ctx, struct pdt_entry *entry, int page))
{
- struct rmi_driver_data *data;
+ struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
struct pdt_entry pdt_entry;
int page;
- struct device *dev = &rmi_dev->dev;
- int irq_count = 0;
- bool done = false;
int i;
- int retval;
-
- dev_dbg(dev, "Scanning PDT...\n");
+ bool done = false;
+ int retval = 0;
- data = dev_get_drvdata(&rmi_dev->dev);
+ // TODO: With F01 and reflash as part of the core now, is this
+ // lock still required?
mutex_lock(&data->pdt_mutex);
for (page = 0; (page <= RMI4_MAX_PAGE) && !done; page++) {
@@ -656,27 +651,27 @@ static int rmi_scan_pdt(struct rmi_device *rmi_dev)
for (i = pdt_start; i >= pdt_end; i -= RMI_PDT_ENTRY_SIZE) {
retval = rmi_read_pdt_entry(rmi_dev, &pdt_entry, i);
if (retval < 0)
- goto error_exit;
+ return retval;
if (RMI4_END_OF_PDT(pdt_entry.function_number))
break;
- dev_dbg(dev, "Found F%02X on page %#04x\n",
+ dev_dbg(&rmi_dev->dev, "Found F%02X on page %#04x\n",
pdt_entry.function_number, page);
done = false;
- // XXX need to make sure we create F01 first...
- retval = create_function(rmi_dev,
- &pdt_entry, &irq_count, page_start);
-
- if (retval)
+ retval = rmi_pdt_scan_clbk(rmi_dev, ctx,
+ &pdt_entry, page);
+ if (retval < 0) {
goto error_exit;
+ } else if (retval == RMI_SCAN_DONE) {
+ done = true;
+ break;
+ }
}
done = done || data->f01_bootloader_mode;
}
- data->irq_count = irq_count;
- data->num_of_irq_regs = (irq_count + 7) / 8;
- dev_dbg(dev, "%s: Done with PDT scan.\n", __func__);
+
retval = 0;
error_exit:
@@ -684,6 +679,7 @@ error_exit:
return retval;
}
+
#ifdef CONFIG_PM_SLEEP
static int rmi_driver_suspend(struct device *dev)
{
@@ -797,10 +793,15 @@ static int rmi_driver_probe(struct device *dev)
/*
* Right before a warm boot, the sensor might be in some unusual state,
- * such as F54 diagnostics, or F34 bootloader mode. In order to clear
- * the sensor to a known state, we issue a initial reset to clear any
+ * such as F54 diagnostics, or F34 bootloader mode after a firmware
+ * or configuration update. In order to clear the sensor to a known
+ * state and/or apply any updates, we issue a initial reset to clear any
* previous settings and force it into normal operation.
*
+ * We have to do this before actually building the PDT because
+ * the reflash updates (if any) might cause various registers to move
+ * around.
+ *
* For a number of reasons, this initial reset may fail to return
* within the specified time, but we'll still be able to bring up the
* driver normally after that failure. This occurs most commonly in
@@ -813,11 +814,11 @@ static int rmi_driver_probe(struct device *dev)
*/
if (!pdata->reset_delay_ms)
pdata->reset_delay_ms = DEFAULT_RESET_DELAY_MS;
- retval = rmi_initial_reset(rmi_dev);
+ retval = rmi_scan_pdt(rmi_dev, NULL, rmi_initial_reset);
if (retval)
dev_warn(dev, "RMI initial reset failed! Continuing in spite of this.\n");
- retval = rmi_scan_pdt(rmi_dev);
+ retval = rmi_create_functions(rmi_dev);
if (retval) {
dev_err(dev, "PDT scan for %s failed with code %d.\n",
pdata->sensor_name, retval);
diff --git a/drivers/input/rmi4/rmi_driver.h b/drivers/input/rmi4/rmi_driver.h
index df9ddd8..f73be73 100644
--- a/drivers/input/rmi4/rmi_driver.h
+++ b/drivers/input/rmi4/rmi_driver.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2011-2013 Synaptics Incorporated
+ * Copyright (c) 2011-2014 Synaptics Incorporated
* Copyright (c) 2011 Unixphere
*
* This program is free software; you can redistribute it and/or modify it
@@ -108,6 +108,10 @@ struct pdt_entry {
int rmi_read_pdt_entry(struct rmi_device *rmi_dev, struct pdt_entry *entry,
u16 pdt_address);
+int rmi_scan_pdt(struct rmi_device *rmi_dev, void *ctx,
+ int (*rmi_pdt_scan_clbk)(struct rmi_device *rmi_dev,
+ void *clbk_ctx, struct pdt_entry *entry, int page));
+
bool rmi_is_physical_driver(struct device_driver *);
int rmi_register_physical_driver(void);
void rmi_unregister_physical_driver(void);
^ permalink raw reply related
* Re: [PATCH v2] ims-pcu: Add commands supported by the new version of the FW
From: Andrey Smirnov @ 2014-01-07 19:14 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: linux-input, linux-kernel
In-Reply-To: <20140107071436.GB20074@core.coreip.homeip.net>
Sorry, haven't had the chance yet. I'll try to do this and hopefully
send v3 of the patch by the end of this week
On Mon, Jan 6, 2014 at 11:14 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Fri, Jan 03, 2014 at 09:41:33PM -0800, Dmitry Torokhov wrote:
>> On Fri, Jan 03, 2014 at 09:03:11PM -0800, Andrey Smirnov wrote:
>> > On Fri, Jan 3, 2014 at 8:44 PM, Dmitry Torokhov
>> > <dmitry.torokhov@gmail.com> wrote:
>> > > On Fri, Jan 03, 2014 at 08:24:17PM -0800, Andrey Smirnov wrote:
>> > >> On Fri, Jan 3, 2014 at 5:39 PM, Dmitry Torokhov
>> > >> <dmitry.torokhov@gmail.com> wrote:
>> > >> > Hi Andrey,
>> > >> >
>> > >> > On Wed, Jan 01, 2014 at 04:47:01PM -0800, Andrey Smirnov wrote:
>> > >> >> New version of the PCU firmware supports two new commands:
>> > >> >> - IMS_PCU_CMD_OFN_SET_CONFIG which allows to write data to the
>> > >> >> registers of one finger navigation(OFN) chip present on the device
>> > >> >> - IMS_PCU_CMD_OFN_GET_CONFIG which allows to read data form the
>> > >> >> registers of said chip.
>> > >> >>
>> > >> >> This commit adds two helper functions to use those commands and sysfs
>> > >> >> attributes to use them. It also exposes some OFN configuration
>> > >> >> parameters via sysfs.
>> > >> >
>> > >> > Thank you for making the changes. I do not still quite like the games we
>> > >> > play with the OFN attributes, how about the patch below (on top of
>> > >> > yours)?
>> > >> >
>> > >>
>> > >> Yeah, I agree I like it the "two separate sysfs groups" group approach
>> > >> better. The only small nitpick about your patch is that I think we
>> > >> should use "get_unaligned_le16" instead of "le16_to_cpup"(In case
>> > >> anyone decides to run the driver on SuperH or C6x DSPs from TI :-)).
>> > >> Let me test it and if everything works as expected I'll apply you
>> > >> patch, convert it to "get_unaligned_le16", squash and send v3 of the
>> > >> patch.
>> > >
>> > > Why do we need get_unaligned_le16()? As far as I can see pcu->cmd_buf is
>> > > aligned and therefore pcu->cmd_buf[2] is also aligned on word boundary.
>> >
>> > * The "pcu" structure is allocated with kmalloc which doesn't give any
>> > guarantees about address alignment.
>> > * I am not sure if the cmd_buf field in that structure is aligned, and
>> > even if it is, any future changes to that structure may shift its
>> > offset.
>> > * Also even if the data we are interested in is aligned on 2-byte
>> > border, I think all those architectures require 4-byte border
>> > alignment.
>>
>> As far as I know word access only requires word alignment. Please see
>> the other patch I just posted that adds alignment check in balcklight
>> handling code.
>
> Andrey, were you able to test the patch?
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: [PATCH] Input: ALPS - Recognise "Dolphin V2" touchpads
From: Dmitry Torokhov @ 2014-01-07 18:59 UTC (permalink / raw)
To: Chris Diamand
Cc: Tommy Will, Kevin Cernekee, Yunkang Tang, david turvene,
linux-input
In-Reply-To: <52CC47C5.4090307@diamand.org>
Hi Chris,
On Tue, Jan 07, 2014 at 06:30:29PM +0000, Chris Diamand wrote:
> Hi, and thanks for your reply.
>
> >Umm, however, I had submited a similar patch for supporting dolphin v2
> >device last month and it was now applied into latest mainline.
>
> Do you mean commit 'ee65d4...add support for "Dolphin" devices'?
>
> It's in the dtor/input.git kernel but I don't think it's been merged
> into mainline (torvalds/linux.git).
>
> Running 'git log drivers/input/mouse/alps.c' with the latest
> mainline kernel shows the last commit as '95f75e...add support for
> DualPoint device on Dell XT2 model', which doesn't work with my
> device (Dell Vostro 3360).
>
> Are there any plans for it to be merged? It looks like your patch
> fixes it much better than mine ;)
Yes, it will be merged together with all other changes to the input
subsystem when the next merge window opens.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH] Input: ALPS - Recognise "Dolphin V2" touchpads
From: Chris Diamand @ 2014-01-07 18:30 UTC (permalink / raw)
To: Tommy Will
Cc: Dmitry Torokhov, Kevin Cernekee, Yunkang Tang, david turvene,
linux-input
In-Reply-To: <CA+F6ckNx8nxjtXLrgzYyNUBnnmb09tFx8zSe=y0JxtMiVrTooQ@mail.gmail.com>
Hi, and thanks for your reply.
> Umm, however, I had submited a similar patch for supporting dolphin v2
> device last month and it was now applied into latest mainline.
Do you mean commit 'ee65d4...add support for "Dolphin" devices'?
It's in the dtor/input.git kernel but I don't think it's been merged
into mainline (torvalds/linux.git).
Running 'git log drivers/input/mouse/alps.c' with the latest mainline
kernel shows the last commit as '95f75e...add support for DualPoint
device on Dell XT2 model', which doesn't work with my device (Dell
Vostro 3360).
Are there any plans for it to be merged? It looks like your patch fixes
it much better than mine ;)
Regards,
Chris
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-01-07 17:13 UTC (permalink / raw)
To: David Herrmann
Cc: Marcel Holtmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan
In-Reply-To: <CANq1E4SxrDnbOCsohZXYoYL-HQjEc-xcOnXfAm=npHG2QfMS9A@mail.gmail.com>
On Tue, 7 Jan 2014, David Herrmann wrote:
> > So doing kzalloc(rsize, GFP_ATOMIC) in the HID-core for now, and copying
> > the buffer around, seems like only viable solution for now, with the
> > outlook of removing this ugliness once hid-core honors 'size' properly.
>
> Should I resend the patches and move it to hid_input_report() for now?
> Or are you getting something in yourself?
Due to various reasons I will not have access to any testing HW for the
upcoming 2-3 days, so if you can cook something up in that timeframe, it'd
be appreciated.
Otherwise I'll be working on it by the end of this week.
> Given the amount of reports on the list and bugzilla, I think we should
> get this fix in asap. We can always fix it properly in -next.
Agreed.
Thanks,
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: David Herrmann @ 2014-01-07 16:34 UTC (permalink / raw)
To: Jiri Kosina
Cc: Marcel Holtmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan
In-Reply-To: <alpine.LNX.2.00.1401071308020.4962@pobox.suse.cz>
Hi Jiri
On Tue, Jan 7, 2014 at 1:11 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Fri, 27 Dec 2013, David Herrmann wrote:
>
>> >> I also haven't figured out a nice way to make HID-core honor the
>> >> "size" parameter. hid-input depends on getting the whole
>> >> input-report.
>> >
>> > I think this needs clearly fixing.
>>
>> And we have a volunteer, yippie! ;)
>>
>> I think hid_input_report() in hid-core.c is the only place that relies
>> on this. Maybe it really is easier to fix it. But I am not even
>> slightly familiar with that code. So if no-one of the HID core
>> developers steps up to fix it, we should take the transport-driver
>> fixes instead. As nearly all transport-drivers are affected by this,
>> maybe we should even move this buffer into hid_device and provide
>> hid_input_truncated_report() which does this.
>>
>> Anyhow, waiting for Jiri's comments on this.
>
> Hmm, this is really unfortunate situation.
>
> I am now looking into making hid_input_report() honor 'size' properly, but
> no matter how it'll be done in the end, it'll absolutely not be a simple
> 'fix'. So definitely can be done for 3.15 or so, but not as a fix for
> current kernels.
>
> So doing kzalloc(rsize, GFP_ATOMIC) in the HID-core for now, and copying
> the buffer around, seems like only viable solution for now, with the
> outlook of removing this ugliness once hid-core honors 'size' properly.
Should I resend the patches and move it to hid_input_report() for now?
Or are you getting something in yourself?
Given the amount of reports on the list and bugzilla, I think we
should get this fix in asap. We can always fix it properly in -next.
Thanks
David
> I will keep looking into this and maybe some easy way how to hack this
> together will materialize, but I don't currently see it.
>
> Hmm ...
>
> --
> Jiri Kosina
> SUSE Labs
^ permalink raw reply
* Re: [PATCH] Input: ALPS - Recognise "Dolphin V2" touchpads
From: Tommy Will @ 2014-01-07 16:24 UTC (permalink / raw)
To: Chris Diamand, Dmitry Torokhov, Kevin Cernekee, Yunkang Tang,
david turvene
Cc: linux-input
In-Reply-To: <CAKvfdtK18rQ4TOqwKCj1P3oQs-BQZr2h3db5NH18WdtNjjnH=g@mail.gmail.com>
Hi Chris,
> This is the touchpad used on the Dell Vostro 3360. Without
> this change, the driver reports this as follows:
> psmouse serio1: alps: Unknown ALPS touchpad: E7=73 03 50, EC=73 02 02
> It seems to use the ALPS V5 protocol, so identify it
> as such by allowing ec[1] == 0x02.
> This is based on src/alps.c from the DKMS driver here:
> http://www.dahetral.com/public-download/alps-psmouse-dlkm-for-3-2-and-3-5/
Thanks for your patch!
Umm, however, I had submited a similar patch for supporting dolphin v2
device last month and it was now applied into latest mainline. Detail
please check the source code in below link.
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
Thanks
--
Best Regards,
Tommy
^ permalink raw reply
* Patch from down stream which has been forgotten
From: Jonathan Aquilina @ 2014-01-07 13:56 UTC (permalink / raw)
To: linux-input
I have a down stream bug from ubuntu which has been forgotten.
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/967399
This fixes multitouch track pads issue where the track pad doesnt work at all.
Can I get an update as to the status of the patch which was upstreamed.
Thanks
Jonathan
^ permalink raw reply
* Re: [PATCH] Bluetooth: hidp: make sure input buffers are big enough
From: Jiri Kosina @ 2014-01-07 12:11 UTC (permalink / raw)
To: David Herrmann
Cc: Marcel Holtmann, open list:HID CORE LAYER,
linux-bluetooth@vger.kernel.org development, Gustavo F. Padovan
In-Reply-To: <CANq1E4TOHvb3--H6SoRhB09sUwuYkrvSAXCNN2Y0PaVSOEte=w@mail.gmail.com>
On Fri, 27 Dec 2013, David Herrmann wrote:
> >> I also haven't figured out a nice way to make HID-core honor the
> >> "size" parameter. hid-input depends on getting the whole
> >> input-report.
> >
> > I think this needs clearly fixing.
>
> And we have a volunteer, yippie! ;)
>
> I think hid_input_report() in hid-core.c is the only place that relies
> on this. Maybe it really is easier to fix it. But I am not even
> slightly familiar with that code. So if no-one of the HID core
> developers steps up to fix it, we should take the transport-driver
> fixes instead. As nearly all transport-drivers are affected by this,
> maybe we should even move this buffer into hid_device and provide
> hid_input_truncated_report() which does this.
>
> Anyhow, waiting for Jiri's comments on this.
Hmm, this is really unfortunate situation.
I am now looking into making hid_input_report() honor 'size' properly, but
no matter how it'll be done in the end, it'll absolutely not be a simple
'fix'. So definitely can be done for 3.15 or so, but not as a fix for
current kernels.
So doing kzalloc(rsize, GFP_ATOMIC) in the HID-core for now, and copying
the buffer around, seems like only viable solution for now, with the
outlook of removing this ugliness once hid-core honors 'size' properly.
I will keep looking into this and maybe some easy way how to hack this
together will materialize, but I don't currently see it.
Hmm ...
--
Jiri Kosina
SUSE Labs
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox