* [PATCH 0/3] HID: low level transport cleanup, series 3
From: Benjamin Tissoires @ 2014-02-20 20:24 UTC (permalink / raw)
To: benjamin.tissoires, jkosina, dh.herrmann, linux-input,
linux-kernel
Hi guys,
this is a new round in the low level HID transport cleanup.
These are the formely 7/14 an 12/14 only.
I add in between a patch which makes .raw_request mandatory, to cleanup
the old 12/14 (so 3/3 here).
There is only two patches 2 merge after these 3... We are approaching the end!
Cheers,
Benjamin
Benjamin Tissoires (3):
HID: input: hid-input remove hid_output_raw_report call
HID: make .raw_request mandatory
HID: hidraw: replace hid_output_raw_report() calls by appropriates
ones
Documentation/hid/hid-transport.txt | 3 ++-
drivers/hid/hid-core.c | 11 ++++++++---
drivers/hid/hid-input.c | 10 ++++++----
drivers/hid/hidraw.c | 19 ++++++++++++++-----
include/linux/hid.h | 5 +----
5 files changed, 31 insertions(+), 17 deletions(-)
--
1.8.5.3
^ permalink raw reply
* Re: USB keyboard occasional key stuck
From: Daniel J Blueman @ 2014-02-21 3:44 UTC (permalink / raw)
To: linux-usb, linux-input, Dmitry Torokhov, Peter Stuge; +Cc: Clinton Sprain
In-Reply-To: <20140218022105.14422.qmail@stuge.se>
Peter, Dmitry et al,
This is a real bug that dents the usability of Linux against Windows
or MacOS. We can enable model-specific workarounds, but what approach
would catch phantom stuck keys in the input stack?
On 18 February 2014 10:21, Peter Stuge <peter@stuge.se> wrote:
> Clinton Sprain wrote:
>> I noticed your examples are both fn combos. I'm seeing something like
>> this and it seems specifically related to the fn key. Reproducible on a
>> Macbook (3,1) and a Lenovo Yoga 13. Sequence is simple:
>>
>> Press key
>> Press fn
>> Release key
>> Release fn
>>
>> The key will be 'stuck' until you press another key. It seems to only
>> apply to keys that are part of a fn combo
>
> Fn is handled by the embedded controller (H8 as per Intel reference
> design in case of Macbook or Thinkpad) which has its own closed
> firmware which is rarely perfectly bug-free.
>
>
> //Peter
--
Daniel J Blueman
^ permalink raw reply
* [patch] Input: remove a duplicative NULL test
From: Dan Carpenter @ 2014-02-21 8:55 UTC (permalink / raw)
To: Dmitry Torokhov
Cc: Paul Gortmaker, Jingoo Han, Fugang Duan, Benson Leung,
Daniel Kurtz, linux-input, kernel-janitors
"pdata" is non-NULL here. We verified that at the start of the
function.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c b/drivers/input/touchscreen/atmel_mxt_ts.c
index a70400754e92..40abe90cc924 100644
--- a/drivers/input/touchscreen/atmel_mxt_ts.c
+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
@@ -1146,7 +1146,7 @@ static int mxt_probe(struct i2c_client *client,
goto err_free_mem;
}
- data->is_tp = pdata && pdata->is_tp;
+ data->is_tp = pdata->is_tp;
input_dev->name = (data->is_tp) ? "Atmel maXTouch Touchpad" :
"Atmel maXTouch Touchscreen";
^ permalink raw reply related
* RE: [patch] Input: remove a duplicative NULL test
From: fugang.duan @ 2014-02-21 9:14 UTC (permalink / raw)
To: Dan Carpenter, Dmitry Torokhov
Cc: Paul Gortmaker, Jingoo Han, Benson Leung, Daniel Kurtz,
linux-input@vger.kernel.org, kernel-janitors@vger.kernel.org
In-Reply-To: <20140221085506.GB13185@elgon.mountain>
From: Dan Carpenter <dan.carpenter@oracle.com>
Data: Friday, February 21, 2014 4:55 PM
>To: Dmitry Torokhov
>Cc: Paul Gortmaker; Jingoo Han; Duan Fugang-B38611; Benson Leung; Daniel Kurtz;
>linux-input@vger.kernel.org; kernel-janitors@vger.kernel.org
>Subject: [patch] Input: remove a duplicative NULL test
>
>"pdata" is non-NULL here. We verified that at the start of the function.
>
>Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
>
>diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
>b/drivers/input/touchscreen/atmel_mxt_ts.c
>index a70400754e92..40abe90cc924 100644
>--- a/drivers/input/touchscreen/atmel_mxt_ts.c
>+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
>@@ -1146,7 +1146,7 @@ static int mxt_probe(struct i2c_client *client,
> goto err_free_mem;
> }
>
>- data->is_tp = pdata && pdata->is_tp;
>+ data->is_tp = pdata->is_tp;
>
> input_dev->name = (data->is_tp) ? "Atmel maXTouch Touchpad" :
> "Atmel maXTouch Touchscreen";
>
Agree, it is redundant. And if you have free time, you can convert the driver to support devicetree.
Acked-by: Fugang Duan <B38611@freescale.com>
^ permalink raw reply
* Re: [PATCH 1/3] mfd: fsl imx25 Touchscreen ADC driver
From: Markus Pargmann @ 2014-02-21 9:18 UTC (permalink / raw)
To: Fabio Estevam
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov, Samuel Ortiz,
Lee Jones, Jonathan Cameron,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer
In-Reply-To: <CAOMZO5BDyyvXs9CxJQOkuEpxZ8fqamCPB67sNhJxES+XU2XkXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 8010 bytes --]
Hi Fabio,
On Thu, Feb 20, 2014 at 02:17:33PM -0300, Fabio Estevam wrote:
> Hi Markus,
>
> On Thu, Feb 20, 2014 at 1:21 PM, Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > This is the core driver for imx25 touchscreen/adc driver. The module
> > has one shared ADC and two different conversion queues which use the
> > ADC. The two queues are identical. Both can be used for general purpose
> > ADC but one is meant to be used for touchscreens.
> >
> > This driver is the core which manages the central components and
> > registers of the TSC/ADC unit. It manages the IRQs and forwards them to
> > the correct components.
> >
> > Signed-off-by: Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> That's great :-) Nice work!
Thanks :)
> > ---
> > .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt | 46 ++++
> > drivers/mfd/Kconfig | 9 +
> > drivers/mfd/Makefile | 2 +
> > drivers/mfd/fsl-imx25-tsadc.c | 234 +++++++++++++++++++++
> > include/linux/mfd/imx25-tsadc.h | 138 ++++++++++++
> > 5 files changed, 429 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> > create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
> > create mode 100644 include/linux/mfd/imx25-tsadc.h
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> > new file mode 100644
> > index 0000000..a857af0e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> > @@ -0,0 +1,46 @@
> > +Freescale mx25 ADC/TSC multifunction device
> > +
> > +This device combines two general purpose conversion queues one used for general
> > +ADC and the other used for touchscreens.
> > +
> > +Required properties:
> > + - compatible: Should be "fsl,imx25-tsadc".
> > + - reg: Memory range of the device.
> > + - interrupts: Interrupt for this device as described in
> > + interrupts/interrupts.txt
> > + - clocks: An 'ipg' clock defined as described in clocks/clock.txt
> > + - interrupt-controller: This device is an interrupt controller. It controls
> > + the interrupts of both conversion queues.
> > + - #interrupt-cells: Should be '<1>'.
> > + - #address-cells: Should be '<1>'.
> > + - #size-cells: Should be '<1>'.
> > + - ranges
> > +
> > +This device includes two conversion queues which can be added as subnodes.
> > +The first queue is for the touchscreen, the second for general purpose ADC.
> > +
> > +Example:
> > + tscadc: tscadc@50030000 {
> > + compatible = "fsl,imx25-tsadc";
> > + reg = <0x50030000 0xc>;
> > + interrupts = <46>;
> > + clocks = <&clks 119>;
> > + clock-names = "ipg";
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + tsc: tcq@50030400 {
> > + compatible = "fsl,imx25-tcq";
> > + reg = <0x50030400 0x60>;
> > + ...
> > + };
> > +
> > + adc: gcq@50030800 {
> > + compatible = "fsl,imx25-gcq";
> > + reg = <0x50030800 0x60>;
> > + ...
> > + };
> > + };
>
> The meaning of 'tcq' and 'gcq' acronyms are not obvious. Could they be
> written more explicitily?
I assume you mean the node names? Perhaps something like 'adcqueue'?
>
> Also, what does the '...' mean?
>
> > +static int mx25_tsadc_domain_map(struct irq_domain *d, unsigned int irq,
> > + irq_hw_number_t hwirq)
> > +{
> > + struct mx25_tsadc_priv *priv = d->host_data;
> > +
> > + irq_set_chip_data(irq, priv);
> > + irq_set_chip_and_handler(irq, &mx25_tsadc_irq_chip,
> > + handle_level_irq);
> > +
> > +#ifdef CONFIG_ARM
> > + set_irq_flags(irq, IRQF_VALID);
> > +#else
> > + irq_set_noprobe(irq);
> > +#endif
>
> Do we really need these ifdef's? Can't we just assume that CONFIG_ARM
> is always selected for this driver?
Yes right, this is not necessary here.
>
> > +static int mx25_tsadc_probe(struct platform_device *pdev)
> > +{
> > + struct device *dev = &pdev->dev;
> > + struct device_node *np = dev->of_node;
> > + struct mx25_tsadc_priv *priv;
> > + struct resource *iores;
> > + int ret;
> > + void __iomem *iomem;
> > +
> > + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> > + if (!priv)
> > + return -ENOMEM;
> > +
> > + iores = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> > + iomem = devm_ioremap_resource(dev, iores);
> > + if (IS_ERR(iomem)) {
> > + dev_err(dev, "Failed to remap iomem\n");
> > + return PTR_ERR(iomem);
> > + }
> > +
> > + priv->regs = regmap_init_mmio(dev, iomem, &mx25_tsadc);
> > + if (IS_ERR(priv->regs)) {
> > + dev_err(dev, "Failed to initialize regmap\n");
> > + return PTR_ERR(priv->regs);
> > + }
> > +
> > + priv->clk = devm_clk_get(dev, "ipg");
> > + if (IS_ERR(priv->clk)) {
> > + dev_err(dev, "Failed to get ipg clock\n");
> > + return PTR_ERR(priv->clk);
> > + }
> > +
> > + /* Enable clock and reset the component */
> > + regmap_update_bits(priv->regs, MX25_TSC_TGCR, MX25_TGCR_CLK_EN,
> > + MX25_TGCR_CLK_EN);
> > + regmap_update_bits(priv->regs, MX25_TSC_TGCR, MX25_TGCR_TSC_RST,
> > + MX25_TGCR_TSC_RST);
> > +
> > + /* Setup powersaving mode, but enable internal reference voltage */
> > + regmap_update_bits(priv->regs, MX25_TSC_TGCR, MX25_TGCR_POWERMODE_MASK,
> > + MX25_TGCR_POWERMODE_SAVE);
> > + regmap_update_bits(priv->regs, MX25_TSC_TGCR, MX25_TGCR_INTREFEN,
> > + MX25_TGCR_INTREFEN);
> > +
> > + ret = mx25_tsadc_setup_irq(pdev, priv);
> > + if (ret) {
> > + dev_err(dev, "Failed to setup irqs\n");
> > + return ret;
> > + }
> > +
> > + platform_set_drvdata(pdev, priv);
> > +
> > + of_platform_populate(np, NULL, NULL, dev);
> > +
> > + dev_info(dev, "i.MX25/25 Touchscreen and ADC core driver loaded\n");
>
> You could remove the double '25/25'.
Yes, fixed.
>
> > +
> > + return 0;
> > +}
> > +
> > +static const struct of_device_id mx25_tsadc_ids[] = {
> > + { .compatible = "fsl,imx25-tsadc", },
> > + { /* Sentinel */ }
> > +};
> > +
> > +static struct platform_driver mx25_tsadc_driver = {
> > + .driver = {
> > + .name = "mx25-tsadc",
> > + .owner = THIS_MODULE,
> > + .of_match_table = mx25_tsadc_ids,
> > + },
> > + .probe = mx25_tsadc_probe,
> > +};
> > +module_platform_driver(mx25_tsadc_driver);
> > +
> > +MODULE_DESCRIPTION("MFD for ADC/TSC for Freescale mx25");
> > +MODULE_AUTHOR("Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>");
> > +MODULE_LICENSE("GPL v2");
>
> MODULE_ALIAS() as well?
I am not sure if this is necessary, but I added
MODULE_ALIAS("platform:mx25-tsadc")
Thanks,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/3] iio: adc: fsl,imx25-gcq driver
From: Markus Pargmann @ 2014-02-21 10:12 UTC (permalink / raw)
To: Lars-Peter Clausen
Cc: devicetree, linux-input, linux-iio, Dmitry Torokhov, Samuel Ortiz,
Lee Jones, Jonathan Cameron, linux-arm-kernel, kernel
In-Reply-To: <53063F72.9070006@metafoo.de>
[-- Attachment #1: Type: text/plain, Size: 8952 bytes --]
Hi,
On Thu, Feb 20, 2014 at 06:46:26PM +0100, Lars-Peter Clausen wrote:
> On 02/20/2014 05:21 PM, Markus Pargmann wrote:
> >This is a conversion queue driver for the mx25 SoC. It uses the central
> >ADC which is used by two seperate independent queues. This driver
> >prepares different conversion configurations for each possible input.
> >For a conversion it creates a conversionqueue of one item with the
> >correct configuration for the chosen channel. It then executes the queue
> >once and disables the conversion queue afterwards.
> >
> >The reference voltages are configurable through devicetree subnodes,
> >depending on the connections of the ADC inputs.
> >
> >Signed-off-by: Markus Pargmann <mpa@pengutronix.de>
>
> Looks good mostly. Just a couple of minor code-style issues. Try to
> run checkpatch, sparse and friends on your driver before submission.
> They catch most of the stuff that needs to be fixed in this driver.
I used checkpatch and will have a look at sparse.
>
> [..]
> >diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
> >index 2209f28..a421445 100644
> >--- a/drivers/iio/adc/Kconfig
> >+++ b/drivers/iio/adc/Kconfig
> >@@ -113,6 +113,13 @@ config EXYNOS_ADC
> > of SoCs for drivers such as the touchscreen and hwmon to use to share
> > this resource.
> >
> >+config MX25_ADC
> >+ tristate "Freescale MX25 ADC driver"
> >+ depends on MFD_MX25_TSADC
> >+ help
> >+ Generic Conversion Queue driver used for general purpose ADC in the
> >+ MX25. This driver supports single measurements using the MX25 ADC.
> >+
>
> alphabetical order
I changed the config option name to "FSL_MX25_ADC" to have it in
alphabetical order for the user visible menuconfig and the config
symbols.
>
> > config LP8788_ADC
> > bool "LP8788 ADC driver"
> > depends on MFD_LP8788
> >diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
> >index ba9a10a..63daa2c 100644
> >--- a/drivers/iio/adc/Makefile
> >+++ b/drivers/iio/adc/Makefile
> >@@ -22,3 +22,4 @@ obj-$(CONFIG_TI_ADC081C) += ti-adc081c.o
> > obj-$(CONFIG_TI_AM335X_ADC) += ti_am335x_adc.o
> > obj-$(CONFIG_TWL6030_GPADC) += twl6030-gpadc.o
> > obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o
> >+obj-$(CONFIG_MX25_ADC) += fsl-imx25-gcq.o
>
> Here too
Fixed.
>
> [...]
>
> >+const struct iio_chan_spec mx25_gcq_channels[MX25_NUM_CFGS] = {
>
> static
Fixed.
>
> >+ MX25_IIO_CHAN(0, "xp"),
> >+ MX25_IIO_CHAN(1, "yp"),
> >+ MX25_IIO_CHAN(2, "xn"),
> >+ MX25_IIO_CHAN(3, "yn"),
> >+ MX25_IIO_CHAN(4, "wiper"),
> >+ MX25_IIO_CHAN(5, "inaux0"),
> >+ MX25_IIO_CHAN(6, "inaux1"),
> >+ MX25_IIO_CHAN(7, "inaux2"),
> >+};
> >+
>
> >+struct iio_info mx25_gcq_iio_info = {
>
> static const
Fixed.
>
> >+ .read_raw = mx25_gcq_read_raw,
> >+};
> >+
> >+static struct regmap_config mx25_gcq_regconfig = {
>
> const
Fixed.
>
> >+ .fast_io = true,
>
> You don't need to set fast_io since this is already done at the
> regmap_bus level.
Okay, I removed it.
>
> >+ .max_register = 0x5c,
> >+ .reg_bits = 32,
> >+ .val_bits = 32,
> >+ .reg_stride = 4,
> >+};
> >+
> >+static void mx25_gcq_iio_dev_setup(struct platform_device *pdev,
> >+ struct iio_dev *idev)
> >+{
> >+ idev->dev.parent = &pdev->dev;
> >+ idev->channels = mx25_gcq_channels;
> >+ idev->num_channels = ARRAY_SIZE(mx25_gcq_channels);
> >+ idev->info = &mx25_gcq_iio_info;
>
> Any reason why this needs to be in a separate function and can't be
> inlined in probe()?
No reason for that. I moved it back to probe().
>
> >+}
> >+
> >+static int mx25_gcq_setup_cfgs(struct platform_device *pdev,
> >+ struct mx25_gcq_priv *priv)
> >+{
> >+ struct device_node *np = pdev->dev.of_node;
> >+ struct device_node *child;
> >+ struct device *dev = &pdev->dev;
> >+ int ret;
> >+ int i;
> >+
> >+ /* Setup all configurations registers with a default conversion
> >+ * configuration for each input */
> >+ for (i = 0; i != MX25_NUM_CFGS; ++i)
> >+ regmap_write(priv->regs, MX25_ADCQ_CFG(i),
> >+ MX25_ADCQ_CFG_YPLL_OFF |
> >+ MX25_ADCQ_CFG_XNUR_OFF |
> >+ MX25_ADCQ_CFG_XPUL_OFF |
> >+ MX25_ADCQ_CFG_REFP_INT |
> >+ (i << 4) |
> >+ MX25_ADCQ_CFG_REFN_NGND2);
> >+
> >+ for_each_child_of_node(np, child) {
> >+ u32 reg;
> >+ u32 refn;
> >+ u32 refp;
> >+
> >+ ret = of_property_read_u32(child, "reg", ®);
> >+ if (ret) {
> >+ dev_err(dev, "Failed to get reg property\n");
> >+ return ret;
> >+ }
> >+ if (reg > MX25_NUM_CFGS) {
> >+ dev_err(dev, "reg value is greater than the number of available configuration registers\n");
> >+ return -EINVAL;
> >+ }
> >+
> >+ ret = of_property_read_u32(child, "fsl,adc-refn", &refn);
> >+ if (ret) {
> >+ dev_err(dev, "Failed to get fsl,adc-refn property\n");
> >+ return ret;
> >+ }
> >+
> >+ ret = of_property_read_u32(child, "fsl,adc-refp", &refp);
> >+ if (ret) {
> >+ dev_err(dev, "Failed to get fsl,adc-refp property\n");
> >+ return ret;
> >+ }
>
> Range check for refp and refn?
Range check added for both.
>
> >+
> >+ regmap_update_bits(priv->regs, MX25_ADCQ_CFG(reg),
> >+ MX25_ADCQ_CFG_REFP_MASK |
> >+ MX25_ADCQ_CFG_REFN_MASK,
> >+ (refp << 7) | (refn << 2));
> >+ }
> >+ regmap_update_bits(priv->regs, MX25_ADCQ_CR,
> >+ MX25_ADCQ_CR_FRST | MX25_ADCQ_CR_QRST,
> >+ MX25_ADCQ_CR_FRST | MX25_ADCQ_CR_QRST);
> >+
> >+ regmap_write(priv->regs, MX25_ADCQ_CR,
> >+ MX25_ADCQ_CR_PDMSK |
> >+ MX25_ADCQ_CR_QSM_FQS);
> >+
> >+ return 0;
> >+}
> >+
> >+static int mx25_gcq_probe(struct platform_device *pdev)
> >+{
> >+ struct iio_dev *idev;
> >+ struct mx25_gcq_priv *priv;
> >+ struct resource *res;
> >+ struct device *dev = &pdev->dev;
> >+ int ret;
> >+ int irq;
> >+ void __iomem *mem;
> >+
> >+ idev = devm_iio_device_alloc(&pdev->dev, sizeof(*priv));
> >+ if (!idev)
> >+ return -ENOMEM;
> >+
> >+ priv = iio_priv(idev);
> >+
> >+ res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >+ mem = devm_ioremap_resource(dev, res);
> >+ if (!mem) {
> >+ dev_err(dev, "Failed to get iomem");
>
> devm_ioremap_resource already prints a error message for you
Okay, I removed dev_err.
>
> >+ return -ENOMEM;
> >+ }
> >+
> >+ priv->regs = devm_regmap_init_mmio(dev, mem, &mx25_gcq_regconfig);
> >+ if (IS_ERR(priv->regs)) {
> >+ dev_err(dev, "Failed to initialize regmap\n");
> >+ return PTR_ERR(priv->regs);
> >+ }
> >+
> >+ irq = platform_get_irq(pdev, 0);
> >+ if (irq < 0) {
>
> 0 is not a valid IRQ number either
Fixed.
>
> >+ dev_err(dev, "Failed to get IRQ\n");
> >+ return irq;
> >+ }
> >+
> >+ ret = devm_request_irq(dev, irq, mx25_gcq_irq, IRQF_ONESHOT, pdev->name,
> >+ priv);
>
> IRQF_ONESHOT does not make much sense for non-threaded IRQs. Also it
> is probably safer to use the non managed variant of request_irq
> here.
Right, I removed the IRQF_ONESHOT flag. Why is it safer to use the non
managed request_irq?
>
> >+ if (ret) {
> >+ dev_err(dev, "Failed requesting IRQ\n");
>
> It usually makes sense to include the error number in the message.
> Same for the other error messages in probe.
The error values are returned from the probe function, so the error
number should be displayed by really_probe() in drivers/base/dd.c .
>
> >+ return ret;
> >+ }
> >+
> >+ ret = mx25_gcq_setup_cfgs(pdev, priv);
> >+ if (ret)
> >+ return ret;
> >+
> >+ mx25_gcq_iio_dev_setup(pdev, idev);
> >+
> >+ ret = iio_device_register(idev);
> >+ if (ret) {
> >+ dev_err(dev, "Failed to register iio device\n");
> >+ return ret;
> >+ }
> >+
> >+ init_completion(&priv->completed);
>
> Should be done before the interrupt handler is registered. You
> reference it in there.
>
> >+
> >+ priv->clk = mx25_tsadc_get_ipg(pdev->dev.parent);
> >+ ret = clk_prepare_enable(priv->clk);
>
> The clock should probably also be enabled before the interrupt
> handler and the IIO device are registered.
Fixed. The last two items are request_irq() and iio_device_register().
>
> >+ if (ret) {
> >+ dev_err(dev, "Failed to enable clock\n");
> >+ return ret;
> >+ }
> >+
> >+ platform_set_drvdata(pdev, priv);
> >+
> >+ return 0;
> >+}
> >+
> >+static int mx25_gcq_remove(struct platform_device *pdev)
> >+{
> >+ struct mx25_gcq_priv *priv = platform_get_drvdata(pdev);
> >+
>
> iio_device_unregister().
Fixed.
>
> >+ clk_disable_unprepare(priv->clk);
> >+
> >+ return 0;
> >+}
>
>
Thanks,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] mfd: fsl imx25 Touchscreen ADC driver
From: Markus Pargmann @ 2014-02-21 10:18 UTC (permalink / raw)
To: Fabio Estevam
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Dmitry Torokhov, Samuel Ortiz,
Lee Jones, Jonathan Cameron,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org,
Sascha Hauer
In-Reply-To: <CAOMZO5BDyyvXs9CxJQOkuEpxZ8fqamCPB67sNhJxES+XU2XkXQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 4217 bytes --]
Hi Fabio,
On Thu, Feb 20, 2014 at 02:17:33PM -0300, Fabio Estevam wrote:
> Hi Markus,
>
> On Thu, Feb 20, 2014 at 1:21 PM, Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org> wrote:
> > This is the core driver for imx25 touchscreen/adc driver. The module
> > has one shared ADC and two different conversion queues which use the
> > ADC. The two queues are identical. Both can be used for general purpose
> > ADC but one is meant to be used for touchscreens.
> >
> > This driver is the core which manages the central components and
> > registers of the TSC/ADC unit. It manages the IRQs and forwards them to
> > the correct components.
> >
> > Signed-off-by: Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
>
> That's great :-) Nice work!
>
> > ---
> > .../devicetree/bindings/mfd/fsl-imx25-tsadc.txt | 46 ++++
> > drivers/mfd/Kconfig | 9 +
> > drivers/mfd/Makefile | 2 +
> > drivers/mfd/fsl-imx25-tsadc.c | 234 +++++++++++++++++++++
> > include/linux/mfd/imx25-tsadc.h | 138 ++++++++++++
> > 5 files changed, 429 insertions(+)
> > create mode 100644 Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> > create mode 100644 drivers/mfd/fsl-imx25-tsadc.c
> > create mode 100644 include/linux/mfd/imx25-tsadc.h
> >
> > diff --git a/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> > new file mode 100644
> > index 0000000..a857af0e
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/mfd/fsl-imx25-tsadc.txt
> > @@ -0,0 +1,46 @@
> > +Freescale mx25 ADC/TSC multifunction device
> > +
> > +This device combines two general purpose conversion queues one used for general
> > +ADC and the other used for touchscreens.
> > +
> > +Required properties:
> > + - compatible: Should be "fsl,imx25-tsadc".
> > + - reg: Memory range of the device.
> > + - interrupts: Interrupt for this device as described in
> > + interrupts/interrupts.txt
> > + - clocks: An 'ipg' clock defined as described in clocks/clock.txt
> > + - interrupt-controller: This device is an interrupt controller. It controls
> > + the interrupts of both conversion queues.
> > + - #interrupt-cells: Should be '<1>'.
> > + - #address-cells: Should be '<1>'.
> > + - #size-cells: Should be '<1>'.
> > + - ranges
> > +
> > +This device includes two conversion queues which can be added as subnodes.
> > +The first queue is for the touchscreen, the second for general purpose ADC.
> > +
> > +Example:
> > + tscadc: tscadc@50030000 {
> > + compatible = "fsl,imx25-tsadc";
> > + reg = <0x50030000 0xc>;
> > + interrupts = <46>;
> > + clocks = <&clks 119>;
> > + clock-names = "ipg";
> > + interrupt-controller;
> > + #interrupt-cells = <1>;
> > + #address-cells = <1>;
> > + #size-cells = <1>;
> > + ranges;
> > +
> > + tsc: tcq@50030400 {
> > + compatible = "fsl,imx25-tcq";
> > + reg = <0x50030400 0x60>;
> > + ...
> > + };
> > +
> > + adc: gcq@50030800 {
> > + compatible = "fsl,imx25-gcq";
> > + reg = <0x50030800 0x60>;
> > + ...
> > + };
> > + };
>
> The meaning of 'tcq' and 'gcq' acronyms are not obvious. Could they be
> written more explicitily?
>
> Also, what does the '...' mean?
I forgot to answer this one. The bindings for tcq and gcq are described
in the other files, so I didn't want to show any details that are not
relevant for this driver.
Regards,
Markus
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* [PATCH 3.14-rc3] input: Add device id for Thrustmaster GPX Gamepad for joystick/xpad.c driver
From: Marcin Lulek @ 2014-02-21 21:59 UTC (permalink / raw)
To: Dmitry Torokhov, Thomaz de Oliveira dos Reis, Paul Gortmaker
Cc: linux-input, linux-kernel
Hello,
It seems xpad driver misses quite a few newer device id's for gamepads
which leads to wrong recognition.
From 18d5a1b290e4b39596e200449aaac6b93c035d63 Mon Sep 17 00:00:00 2001
From: Marcin Lulek <info@webreactor.eu>
Date: Fri, 21 Feb 2014 22:11:46 +0100
Subject: [PATCH 1/1] Add device id for Thrustmaster GPX Gamepad for
joystick/xpad.c driver
Signed-off-by: Marcin Lulek <info@webreactor.eu>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Thomaz de Oliveira dos Reis <thor27@gmail.com>
Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
Cc: linux-input@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 603fe0d..b94668f 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -124,6 +124,7 @@ static const struct xpad_device {
{ 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)",
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver",
MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
+ { 0x24c6, 0x5b02, "Thrustmaster, Inc. GPX Controller", 0,
XTYPE_XBOX360 },
{ 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc242, "Logitech Chillstream Controller", 0,
XTYPE_XBOX360 },
--
1.8.3.2
^ permalink raw reply related
* [PATCH 1/1] Add device id for Thrustmaster GPX Gamepad for joystick/xpad.c driver
From: Marcin Lulek @ 2014-02-21 22:51 UTC (permalink / raw)
To: Marcin Lulek, Dmitry Torokhov, Thomaz de Oliveira dos Reis,
Paul Gortmaker, linux-input
Cc: linux-kernel
Signed-off-by: Marcin Lulek <info@webreactor.eu>
---
drivers/input/joystick/xpad.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
index 603fe0d..b94668f 100644
--- a/drivers/input/joystick/xpad.c
+++ b/drivers/input/joystick/xpad.c
@@ -124,6 +124,7 @@ static const struct xpad_device {
{ 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
{ 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
+ { 0x24c6, 0x5b02, "Thrustmaster, Inc. GPX Controller", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
{ 0x046d, 0xc242, "Logitech Chillstream Controller", 0, XTYPE_XBOX360 },
--
1.8.3.2
^ permalink raw reply related
* RE: [PATCH] input synaptics-rmi4: Use put_device() and device_type.release() to free storage.
From: Christopher Heiny @ 2014-02-21 23:29 UTC (permalink / raw)
To: Dmitry Torokhov, Courtney Cavin
Cc: Linux Input, Andrew Duggan, Vincent Huang, Vivian Ly,
Daniel Rosenberg, Jean Delvare, Joerie de Gram, Linus Walleij,
Benjamin Tissoires, David Herrmann, Jiri Kosina
In-Reply-To: <20140213221048.GA6650@core.coreip.homeip.net>
Sorry for top posting - using web mail right now.
I think something like allocate_device and free_device will be needed sooner rather than later. I'll get a patch out for that in the next couple of days.
Chris
________________________________________
From: linux-input-owner@vger.kernel.org [linux-input-owner@vger.kernel.org] on behalf of Dmitry Torokhov [dmitry.torokhov@gmail.com]
Sent: Thursday, February 13, 2014 2:10 PM
To: Courtney Cavin
Cc: Christopher Heiny; Linux Input; Andrew Duggan; Vincent Huang; Vivian Ly; Daniel Rosenberg; Jean Delvare; Joerie de Gram; Linus Walleij; Benjamin Tissoires; David Herrmann; Jiri Kosina
Subject: Re: [PATCH] input synaptics-rmi4: Use put_device() and device_type.release() to free storage.
On Thu, Feb 13, 2014 at 01:59:31PM -0800, Courtney Cavin wrote:
> On Thu, Feb 13, 2014 at 07:15:24AM +0100, Dmitry Torokhov wrote:
> > On Wed, Feb 12, 2014 at 06:31:04PM -0800, Christopher Heiny wrote:
> > > Input: synaptics-rmi4 - Use put_device() and device_type.release()
> > > to free storage.
> > >
> > > From: Christopher Heiny <cheiny@synaptics.com>
> > >
> > > For rmi_sensor and rmi_function device_types, use put_device() and
> > > the assocated device_type.release() function to clean up related
> > > structures and storage in the correct and safe order.
> > >
> > > Allocate irq_mask as part of struct rmi_function.
> > >
> > > Delete unused rmi_driver_irq_get_mask() function.
> [...]
> > Input: synaptics-rmi4 - use put_device() to free devices
> >
> > From: Christopher Heiny <cheiny@synaptics.com>
> >
> > For rmi_sensor and rmi_function device_types, use put_device() and
> > the associated device_type->release() function to clean up related
> > structures and storage in the correct and safe order.
> >
> > Allocate irq_mask as part of struct rmi_function.
> >
> > Suggested-by: Courtney Cavin <courtney.cavin@sonymobile.com>
> > Signed-off-by: Christopher Heiny <cheiny@synaptics.com>
> > Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> > ---
> > drivers/input/rmi4/rmi_bus.c | 30 +++++++++++++++++++++---------
> > drivers/input/rmi4/rmi_bus.h | 7 ++++---
> > drivers/input/rmi4/rmi_driver.c | 25 +++++++------------------
> > 3 files changed, 32 insertions(+), 30 deletions(-)
> >
> > diff --git a/drivers/input/rmi4/rmi_bus.c b/drivers/input/rmi4/rmi_bus.c
> [...]
> > @@ -142,6 +150,7 @@ EXPORT_SYMBOL(rmi_unregister_transport_device);
> > static void rmi_release_function(struct device *dev)
> > {
> > struct rmi_function *fn = to_rmi_function(dev);
> > +
> > kfree(fn);
> > }
>
> Ownership of this memory is a bit weird...
>
> [...]
> > void rmi_unregister_function(struct rmi_function *fn)
> > {
> > + device_del(&fn->dev);
> > rmi_function_teardown_debugfs(fn);
> > - device_unregister(&fn->dev);
> > + put_device(&fn->dev);
> > }
>
> Here clearly the bus code owns it...
>
> > diff --git a/drivers/input/rmi4/rmi_driver.c b/drivers/input/rmi4/rmi_driver.c
> [...]
> > static int rmi_create_function(struct rmi_device *rmi_dev,
> > - void *ctx, const struct pdt_entry *pdt)
> > + void *ctx, const struct pdt_entry *pdt)
> > {
> > struct device *dev = &rmi_dev->dev;
> > struct rmi_driver_data *data = dev_get_drvdata(&rmi_dev->dev);
> > @@ -630,7 +629,9 @@ static int rmi_create_function(struct rmi_device *rmi_dev,
> > dev_dbg(dev, "Initializing F%02X for %s.\n",
> > pdt->function_number, pdata->sensor_name);
> >
> > - fn = kzalloc(sizeof(struct rmi_function), GFP_KERNEL);
> > + fn = kzalloc(sizeof(struct rmi_function) +
> > + BITS_TO_LONGS(data->irq_count) * sizeof(unsigned long),
> > + GFP_KERNEL);
>
> But it's allocated in the chip driver...
>
> > if (!fn) {
> > dev_err(dev, "Failed to allocate memory for F%02X\n",
> > pdt->function_number);
> > @@ -646,22 +647,12 @@ static int rmi_create_function(struct rmi_device *rmi_dev,
> > fn->irq_pos = *current_irq_count;
> > *current_irq_count += fn->num_of_irqs;
> >
> > - fn->irq_mask = kzalloc(
> > - BITS_TO_LONGS(data->irq_count) * sizeof(unsigned long),
> > - GFP_KERNEL);
> > - if (!fn->irq_mask) {
> > - dev_err(dev, "%s: Failed to create irq_mask for F%02X.\n",
> > - __func__, pdt->function_number);
> > - error = -ENOMEM;
> > - goto err_free_mem;
> > - }
> > -
> > for (i = 0; i < fn->num_of_irqs; i++)
> > set_bit(fn->irq_pos + i, fn->irq_mask);
> >
> > error = rmi_register_function(fn);
> > if (error)
> > - goto err_free_irq_mask;
> > + goto err_put_fn;
> >
> > if (pdt->function_number == 0x01)
> > data->f01_container = fn;
> > @@ -670,10 +661,8 @@ static int rmi_create_function(struct rmi_device *rmi_dev,
> >
> > return RMI_SCAN_CONTINUE;
> >
> > -err_free_irq_mask:
> > - kfree(fn->irq_mask);
> > -err_free_mem:
> > - kfree(fn);
> > +err_put_fn:
> > + put_device(&fn->dev);
>
> And the chip driver now is expected to know it's a device, and trust
> that the bus code knows how to free the memory.
Yeah. That is why for input devices I have a separate
input_allocate_device and input_free_device... But given that RMI is
pretty-much self-contained I think we can live with this.
>
> As this clearly fixes a bug or two, I say we should take this patch
> as-is and worry about proper ownership at some other time.
>
> -Courtney
--
Dmitry
--
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
* I-Tech tablet PC manufacturer
From: angelafan @ 2014-02-22 2:53 UTC (permalink / raw)
To: linux-input; +Cc: username
Dear Sir ，
How are you?
This is Angela from i-tech company,our company was founded in 2003,existing staff of more than 100 people.
We are commited to research, develope and manufacture fashion digital products, like Tablet PC, game player and so on.
Now please allowed me to introduce some hot sale models and popular product to you and your colleagues for tablet PC.
We do promotion for tablets for July:
7 inch Dual core IPS 3G and without 3G
7 inch Quadcore IPS screen
7.85 inch dual core IPS with 3G Bluetooth and GPS
8.1 inch dual core with 3G Bluetooth and GPS
9 inch dual core
10.1 inch quadcore IPS
10.1 inch Quadcore
10.1 inch MTK 3G bluetooth GPS
Variety of competitive products and solutions looking forward to you to visit our factory and consulting.
We will provide the best product quality and service to win the trust of customers
more info,please visit our website：www.i-techglobal.com.
If you are interested in please contact me by Skype angelafan714,MSN angelafanteg@hotmail.com or email at sales@i-techglobal.com，
we will be pleased to send it to you offer.
--------------------------------------------------------------------------------
thanks and warm regards,
Angela Fan
Sales director
i-Tech Shenzhen Electronics Co.,Limited
TeL:0086-755-61679830
Tel:0086-755-27791864
FAX: 86-755-61679829
Skype:angelafan714
Website:www.i-techglobal.com
^ permalink raw reply
* (unknown),
From: christy walton @ 2014-02-22 15:00 UTC (permalink / raw)
Good day i am Mrs christy walton
I brought to you a proposal worth $ 9,000,000,000.00(Nine Billion United
State
Dollars) which i intend to use for CHARITY. Please reply me back if you
are interested.
----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
^ permalink raw reply
* is it possible to temporarily not let user mode get hid input event
From: loody @ 2014-02-22 16:35 UTC (permalink / raw)
To: linux-input, linux-usb@vger.kernel.org
hi all:
is there any kernel hid module parameter or test program can
temporarily not letting user mode program not receiving hid event?
1. My hid kos are still inserted in.
2. the kernel usb driver is working well; that mean kernel usb driver
still handle interrupt transaction.
I just not want user mode program see the hid event for a while,
Appreciate your kind help in advance,
^ permalink raw reply
* Re: is it possible to temporarily not let user mode get hid input event
From: David Herrmann @ 2014-02-22 16:56 UTC (permalink / raw)
To: loody; +Cc: open list:HID CORE LAYER, linux-usb@vger.kernel.org
In-Reply-To: <CANudz+smSLiEtTRC4t7VxzshDAdR6D4E=zYVJHT8xw0w4JiwGw@mail.gmail.com>
Hi
On Sat, Feb 22, 2014 at 5:35 PM, loody <miloody@gmail.com> wrote:
> hi all:
> is there any kernel hid module parameter or test program can
> temporarily not letting user mode program not receiving hid event?
> 1. My hid kos are still inserted in.
> 2. the kernel usb driver is working well; that mean kernel usb driver
> still handle interrupt transaction.
>
> I just not want user mode program see the hid event for a while,
For each connected HID device, there is a driver bound to it that
reads the events and forwards them to HID core. What you can do, is to
unbind a driver on a given device:
echo "<your-device-name>" >/sys/bus/hid/drivers/<driver-name>/unbind
The device-name is the directory name in:
/sys/bus/hid/devices/
The driver name is usually "hid-generic" but can be figured out for
each device by looking at the "driver" symlink in it's directry.
However, this is *really* just meant for debugging. This is not
recommended for anything serious. There is no support for that and if
you don't know what all this does, you shouldn't use it.
There is no proper way to disable a single device in the kernel.
User-space is supposed to control device-access so we probably won't
add such features to the kernel. If you describe your use-case in more
details, we can try to give hints how to get that working.
Thanks
David
^ permalink raw reply
* Re: Mixed HID descriptors
From: David Herrmann @ 2014-02-22 17:04 UTC (permalink / raw)
To: Nuno Santos
Cc: open list:HID CORE LAYER, Benjamin Tissoires, Jiri Kosina,
Henrik Rydberg
In-Reply-To: <5305E327.2020504@displax.com>
Hi
CC Jiri, Benjamin and Henrik
On Thu, Feb 20, 2014 at 12:12 PM, Nuno Santos <nsantos@displax.com> wrote:
> Hi,
>
> We are developing an HID multitouch device and we want to make it fully
> compatible with Linux and Windows.
>
> The device descriptor describes a mouse, keyboard and multitouch digitizer
> as well as a set of features. When we have mouse or keyboard descriptor
> along the touch device I can no longer get or set features. It gives me a
> timeout error:
>
> ioctl (GFEATURE): Connection timed out
>
> This only happens in Linux.
>
> I would like to know if this is normal, or if there is anyway of getting
> more information about the parsing itself in order to understand the
> problem.
>
> Below is the device report descriptor
I don't have much time to test it myself, but you can get a lot of
debug information via debugfs. Most distros enable it by default. Try
looking into /sys/kernel/debug/hid/<dev>/
These debugfs files contain runtime information about HID internals.
Thanks
David
> __ALIGN_BEGIN
> static uint8_t HID_ReportDesc[]
> __ALIGN_END =
> {
> #if 0 // IS MESSING HID ON LINUX
> 0x05, 0x01, // Usage Page (Generic Desktop)
> 0x09, 0x06, // Usage (Keyboard)
> 0xA1, 0x01, // Collection (Application)
> 0x85, REPORTID_KEYBOARD, // REPORT_ID (Mouse)
> 0x05, 0x07, // Usage page (Key Codes)
> 0x19, 0xE0, // Usage minimum (224)
> 0x29, 0xE7, // Usage maximum (231)
> 0x15, 0x00, // Logical minimum (0)
> 0x25, 0x01, // Logical maximum (1)
> 0x75, 0x01, // Report size (1)
> 0x95, 0x08, // Report count (8)
> 0x81, 0x02, // Input (data, variable,
> absolute)
> 0x95, 0x01, // Report count (1)
> 0x75, 0x08, // Report size (8)
> 0x81, 0x01, // Input (constant)
> 0x95, 0x06, // Report count (6)
> 0x75, 0x08, // Report size (8)
> 0x15, 0x00, // Logical minimum (0)
> 0x25, 0x65, // Logical maximum (101)
> 0x05, 0x07, // Usage page (key codes)
> 0x19, 0x00, // Usage minimum (0)
> 0x29, 0x65, // Usage maximum (101)
> 0x81, 0x00, // Input (data, array)
> 0xC0,
> #endif
>
> #if 0 // IS MESSING HID ON LINUX
> 0x05, 0x01, // USAGE_PAGE (Generic Desktop)
> 0x09, 0x01, // USAGE (Pointer)
> 0xa1, 0x01, // COLLECTION (Application)
> 0x85, REPORTID_MOUSE, // REPORT_ID (Mouse)
> 0x09, 0x01, // USAGE (Pointer)
> 0xa1, 0x00, // COLLECTION (Physical)
> 0x05, 0x09, // USAGE_PAGE (Buttons)
> 0x09, 0x01, // USAGE (Button 1)
> 0x95, 0x01, // REPORT_COUNT (1)
> 0x75, 0x01, // REPORT_SIZE (1)
> 0x15, 0x00, // LOGICAL_MINIMUM (0)
> 0x25, 0x01, // LOGICAL_MAXIMUM (1)
> 0x81, 0x02, // INPUT (Data,Var,Abs)
> 0x95, 0x07, // REPORT_COUNT (7)
> 0x75, 0x01, // REPORT_SIZE (1)
> 0x81, 0x03, // INPUT (Const,Var,Abs)
> 0x95, 0x08, // REPORT_COUNT (8)
> 0x75, 0x01, // REPORT_SIZE (1)
> 0x81, 0x03, // INPUT (Const,Var,Abs)
> 0x05, 0x01, // USAGE_PAGE (Generic Desktop)
> 0x09, 0x30, // USAGE (X)
> 0x09, 0x31, // USAGE (Y)
> 0x15, 0x00, // LOGICAL_MINIMUM (0)
> 0x26, 0xff, 0x7f, // LOGICAL_MAXIMUM (32767)
> 0x35, 0x00, // PHYSICAL_MINIMUM (0)
> 0x46, 0x00, 0x00, // PHYSICAL_MAXIMUM (0)
> 0x95, 0x02, // REPORT_COUNT (2)
> 0x75, 0x10, // REPORT_SIZE (16)
> 0x81, 0x02, // INPUT (Data,Var,Abs)
> 0xc0, // END_COLLECTION
> 0xa1, 0x02, // COLLECTION (Logical)
> 0x15, 0x00, // LOGICAL_MINIMUM (0)
> 0x26, 0xff, 0x00, // LOGICAL_MAXIMUM (255)
> 0x09, 0x01, // USAGE (Pointer)
> 0x95, 0x39, // REPORT_COUNT (57)
> 0x75, 0x08, // REPORT_SIZE (8)
> 0x81, 0x01, // INPUT (Data,Var,Abs)
> 0xc0, // END_COLLECTION
> 0xc0, // END_COLLECTION
> #endif
>
> #if 1
> 0x05, 0x0d, // USAGE_PAGE (Digitizers)
> 0x09, 0x0E, // USAGE (Configuration)
> 0xa1, 0x01, // COLLECTION (Application)
> 0x85, REPORTID_MODE, // REPORT_ID (Feature)
> 0x09, 0x23, // USAGE (Device Settings)
> 0xa1, 0x02, // COLLECTION (logical)
> 0x09, 0x52, // USAGE (Device Mode)
> 0x09, 0x53, // USAGE (Device Index)
> 0x15, 0x00, // LOGICAL_MINIMUM (0)
> 0x25, 0x28, // LOGICAL_MAXIMUM (40)
> 0x75, 0x08, // REPORT_SIZE (8)
> 0x95, 0x02, // REPORT_COUNT (2)
> 0xb1, 0x02, // FEATURE (Data,Var,Abs)
> 0xc0, // END_COLLECTION
> 0xc0, // END_COLLECTION
>
> 0x09, 0x04, // USAGE (Touch Screen)
> 0xa1, 0x01, // COLLECTION (Application)
> 0x85, REPORTID_TOUCH, // REPORT_ID (Touch)
> 0x09, 0x22, // USAGE (Finger)
>
> 0x05, 0x0d, /* USAGE_PAGE (Digitizers)
> */
> 0xa1, 0x02, /* COLLECTION (Logical)
> */
> 0x09, 0x42, /* USAGE (Tip Switch)
> */
> 0x15, 0x00, /* LOGICAL_MINIMUM (0)
> */
> 0x25, 0x01, /* LOGICAL_MAXIMUM (1)
> */
> 0x75, 0x01, /* REPORT_SIZE (1)
> */
> 0x95, 0x01, /* REPORT_COUNT (1)
> */
> 0x81, 0x02, /* INPUT (Data,Var,Abs)
> */
> 0x09, 0x32, /* USAGE (In Range)
> */
> 0x81, 0x02, /* INPUT (Data,Var,Abs)
> */
> 0x09, 0x47, /* USAGE (Confidence)
> */
> 0x81, 0x02, /* INPUT (Data,Var,Abs)
> */
> 0x95, 0x05, /* REPORT_COUNT (5)
> */
> 0x81, 0x03, /* INPUT (Cnst,Ary,Abs)
> */
> 0x09, 0x51, /* USAGE (Contact Identifier)
> */
> 0x75, 0x08, /* REPORT_SIZE (8)
> */
> 0x95, 0x01, /* REPORT_COUNT (1)
> */
> 0x81, 0x02, /* INPUT (Data,Var,Abs)
> */
> 0xa1, 0x00, /* COLLECTION (Physical)
> */
> 0x05, 0x01, /* USAGE_PAGE (Generic
> Desktop) */
> 0x15, 0x00, /* LOGICAL_MINIMUM (0)
> */
> 0x26, 0x3A, 0x20, /* LOGICAL_MAXIMUM (8200)
> */
> 0x75, 0x10, /* REPORT_SIZE (16)
> */
> 0x09, 0x30, /* USAGE (X)
> */
> 0x81, 0x02, /* INPUT (Data,Var,Abs)
> */
> 0x15, 0x00, /* LOGICAL_MINIMUM (0)
> */
> 0x26, 0x5C, 0x12, /* LOGICAL_MAXIMUM (4700)
> */
> 0x09, 0x31, /* USAGE (Y)
> */
> 0x81, 0x02, /* INPUT (Data,Var,Abs)
> */
> 0x05, 0x0d, /* USAGE_PAGE (Digitizers)
> */
> 0x09, 0x30, /* USAGE (X)
> */
> 0x75, 0x10, /* REPORT_SIZE (16)
> */
> 0x95, 0x01, /* REPORT_COUNT (1)
> */
> 0x81, 0x02, /* INPUT (Data,Var,Abs)
> */
> 0xc0, /* END_COLLECTION
> */
> 0xc0, /* END_COLLECTION
> */
>
> 0x05, 0x0d, // USAGE_PAGE (Digitizers)
> 0x09, 0x54, // USAGE (Actual count)
> 0x15, 0x00, // LOGICAL_MAXIMUM (0)
> 0x25, 0x14, // LOGICAL_MAXIMUM (20)
> 0x95, 0x01, // REPORT_COUNT (1)
> 0x75, 0x08, // REPORT_SIZE (8)
> 0x81, 0x02, // INPUT (Data,Var,Abs)
>
> 0x85, REPORTID_MAX_COUNT, // REPORT_ID (Feature)
> 0x09, 0x55, // USAGE(Maximum Count)
> 0x15, 0x00, // LOGICAL_MINIMUM (0)
> 0x25, 0x14, // LOGICAL_MAXIMUM (20)
> 0x95, 0x01, // REPORT_COUNT (1)
> 0x75, 0x08, // REPORT_SIZE (8)
> 0xb1, 0x02, // FEATURE (Data,Var,Abs)
> 0xc0, // END_COLLECTION
> #endif
>
> #if 1
> 0x09, 0x00, // USAGE (Undefined)
> 0xa1, 0x01, // COLLECTION (Application)
> 0x85, REPORTID_ENABLE, // REPORT_ID (Feature)
> 0x09, 0x00, // USAGE(Undefined)
> 0x95, 0x01, // REPORT_COUNT (1)
> 0x75, 0x08, // REPORT_SIZE (8)
> 0xb1, 0x02, // FEATURE (Data,Var,Abs)
> 0x85, REPORTID_GAIN, // REPORT_ID (Feature)
> 0x09, 0x00, // USAGE(Undefined)
> 0x15, 0x00, // LOGICAL_MINIMUM (0)
> 0x25, 0x07, // LOGICAL_MAXIMUM (7)
> 0x95, 0x01, // REPORT_COUNT (1)
> 0x75, 0x08, // REPORT_SIZE (8)
> 0xb1, 0x02, // FEATURE (Data,Var,Abs)
> 0xc0, // END_COLLECTION
> #endif
> };
>
> With my best regards,
>
> Nuno Santos
> www.displax.com
> --
> 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: [PATCH 1/1] Add device id for Thrustmaster GPX Gamepad for joystick/xpad.c driver
From: Dmitry Torokhov @ 2014-02-23 6:28 UTC (permalink / raw)
To: Marcin Lulek
Cc: Marcin Lulek, Thomaz de Oliveira dos Reis, Paul Gortmaker,
linux-input, linux-kernel
In-Reply-To: <1393023081-31679-1-git-send-email-info@webreactor.eu>
On Fri, Feb 21, 2014 at 11:51:21PM +0100, Marcin Lulek wrote:
> Signed-off-by: Marcin Lulek <info@webreactor.eu>
> ---
> drivers/input/joystick/xpad.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/input/joystick/xpad.c b/drivers/input/joystick/xpad.c
> index 603fe0d..b94668f 100644
> --- a/drivers/input/joystick/xpad.c
> +++ b/drivers/input/joystick/xpad.c
> @@ -124,6 +124,7 @@ static const struct xpad_device {
> { 0x045e, 0x0291, "Xbox 360 Wireless Receiver (XBOX)", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
> { 0x045e, 0x0719, "Xbox 360 Wireless Receiver", MAP_DPAD_TO_BUTTONS, XTYPE_XBOX360W },
> { 0x044f, 0x0f07, "Thrustmaster, Inc. Controller", 0, XTYPE_XBOX },
> + { 0x24c6, 0x5b02, "Thrustmaster, Inc. GPX Controller", 0, XTYPE_XBOX360 },
> { 0x046d, 0xc21d, "Logitech Gamepad F310", 0, XTYPE_XBOX360 },
> { 0x046d, 0xc21f, "Logitech Gamepad F710", 0, XTYPE_XBOX360 },
> { 0x046d, 0xc242, "Logitech Chillstream Controller", 0, XTYPE_XBOX360 },
> --
> 1.8.3.2
>
Applied, thank you.
--
Dmitry
^ permalink raw reply
* Re: ff-core effect id handling in case of a failed effect upload
From: Dmitry Torokhov @ 2014-02-23 6:30 UTC (permalink / raw)
To: Elias Vanderstuyft; +Cc: Anssi Hannula, linux-input, wine-devel
In-Reply-To: <CADbOyBSR+CWouAQ+f7VjJcoqiC_J++O7cnjkx+2DqmQorhQ7wg@mail.gmail.com>
On Wed, Feb 19, 2014 at 11:14:18PM +0100, Elias Vanderstuyft wrote:
> On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote:
> >> (added Dmitry to CC)
> >>
> >> 19.02.2014 13:42, Elias Vanderstuyft kirjoitti:
> >> > Hi,
> >> >
> >>
> >> Hi,
> >>
> >> > In the process of reviewing the Wine DInput translation layer, I
> >> > noticed an inconvenience (in the ff-core implementation?) that can
> >> > possibly lead to confusing problems to application developers (not
> >> > only for Wine), in short:
> >> > If a new (id==-1) effect was uploaded (look at
> >> > ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL),
> >> > ff-core will have assigned a positive number to the effect id. This
> >> > can be confusing because the dev->ff->effects[] array will not contain
> >> > an element at the index of that new effect id.
> >>
> >> I agree that this is a bit confusing, and the kernel code should
> >> probably be modified to not clobber the ioctl-provided effect on failure
> >> (effect->id is set to an "undefined" value, i.e. next free effect slot).
> >>
> >> Dmitry, WDYT?
> >
> > Yeah, it looks like we need to change evdev.c to read:
> >
> > error = input_ff_upload(dev, &effect, file);
> > if (error)
> > return error;
> >
> > if (put_user(effect.id, &(((struct ff_effect __user *)p)->id)))
> > return -EFAULT;
> >
> > return 0;
>
> Alright, who will create the patch?
> Do I may / have to do it?
If you could create the patch that would be appreciated.
Thanks.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 2/3] input: touchscreen: imx25 tcq driver
From: Dmitry Torokhov @ 2014-02-23 6:44 UTC (permalink / raw)
To: Markus Pargmann
Cc: devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-input-u79uwXL29TY76Z2rM5mHXA,
linux-iio-u79uwXL29TY76Z2rM5mHXA, Samuel Ortiz, Lee Jones,
Jonathan Cameron,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
kernel-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1392913312-9030-3-git-send-email-mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hi Marjus,
On Thu, Feb 20, 2014 at 05:21:51PM +0100, Markus Pargmann wrote:
> This is a driver for the imx25 ADC/TSC module. It controls the
> touchscreen conversion queue and creates a touchscreen input device.
> The driver currently only supports 4 wire touchscreens. The driver uses
> a simple conversion queue of precharge, touch detection, X measurement,
> Y measurement, precharge and another touch detection.
>
> This driver uses the regmap from the parent to setup some touch specific
> settings in the core driver and setup a idle configuration with touch
> detection.
>
> Signed-off-by: Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> ---
> .../bindings/input/touchscreen/fsl-mx25-tcq.txt | 29 +
> drivers/input/touchscreen/Kconfig | 6 +
> drivers/input/touchscreen/Makefile | 1 +
> drivers/input/touchscreen/fsl-imx25-tcq.c | 589 +++++++++++++++++++++
> 4 files changed, 625 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> create mode 100644 drivers/input/touchscreen/fsl-imx25-tcq.c
>
> diff --git a/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> new file mode 100644
> index 0000000..4214a99
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/input/touchscreen/fsl-mx25-tcq.txt
> @@ -0,0 +1,29 @@
> +Freescale mx25 TS conversion queue module
> +
> +mx25 touchscreen conversion queue module which controls the ADC unit of the
> +mx25 for attached touchscreens.
> +
> +Required properties:
> + - compatible: Should be "fsl,imx25-tcq".
> + - reg: Memory range of the device.
> + - interrupts: Should be the interrupt number associated with this module within
> + the tscadc unit (<0>).
> + - interrupt-parent: Should be a phandle to the tscadc unit.
> + - fsl,wires: Should be '<4>' or '<5>'
> +
> +Optional properties:
> + - fsl,pen-debounce: Pen debounce time.
> + - fsl,pen-threshold: Pen-down threshold for the touchscreen.
> + - fsl,settling-time: Settling time in nanoseconds.
> +
> +This device includes two conversion queues which can be added as subnodes.
> +The first queue is for the touchscreen, the second for general purpose ADC.
> +
> +Example:
> + tsc: tcq@50030400 {
> + compatible = "fsl,imx25-tcq";
> + reg = <0x50030400 0x60>;
> + interrupt-parent = <&tscadc>;
> + interrupts = <0>;
> + fsl,wires = <4>;
> + };
> diff --git a/drivers/input/touchscreen/Kconfig b/drivers/input/touchscreen/Kconfig
> index 07e9e82..d52c055 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -715,6 +715,12 @@ config TOUCHSCREEN_USB_COMPOSITE
> To compile this driver as a module, choose M here: the
> module will be called usbtouchscreen.
>
> +config TOUCHSCREEN_MX25
> + tristate "Freescale i.MX25 touchscreen input driver"
> + depends on MFD_MX25_TSADC
> + help
> + Enable support for touchscreen connected to your i.MX25.
> +
> config TOUCHSCREEN_MC13783
> tristate "Freescale MC13783 touchscreen input driver"
> depends on MFD_MC13XXX
> diff --git a/drivers/input/touchscreen/Makefile b/drivers/input/touchscreen/Makefile
> index 62801f2..c891f30 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -38,6 +38,7 @@ obj-$(CONFIG_TOUCHSCREEN_INEXIO) += inexio.o
> obj-$(CONFIG_TOUCHSCREEN_INTEL_MID) += intel-mid-touch.o
> obj-$(CONFIG_TOUCHSCREEN_LPC32XX) += lpc32xx_ts.o
> obj-$(CONFIG_TOUCHSCREEN_MAX11801) += max11801_ts.o
> +obj-$(CONFIG_TOUCHSCREEN_MX25) += fsl-imx25-tcq.o
> obj-$(CONFIG_TOUCHSCREEN_MC13783) += mc13783_ts.o
> obj-$(CONFIG_TOUCHSCREEN_MCS5000) += mcs5000_ts.o
> obj-$(CONFIG_TOUCHSCREEN_MIGOR) += migor_ts.o
> diff --git a/drivers/input/touchscreen/fsl-imx25-tcq.c b/drivers/input/touchscreen/fsl-imx25-tcq.c
> new file mode 100644
> index 0000000..436cc8b
> --- /dev/null
> +++ b/drivers/input/touchscreen/fsl-imx25-tcq.c
> @@ -0,0 +1,589 @@
> +/*
> + * Copyright 2014 Markus Pargmann, Pengutronix <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> + * Based on driver from 2011 Juergen Beisert, Pengutronix <kernel-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + *
> + * This is the driver for the imx25 TCQ (Touchscreen Conversion Queue)
> + * connected to the imx25 ADC.
> + */
> +
> +#include <linux/clk.h>
> +#include <linux/interrupt.h>
> +#include <linux/input.h>
> +#include <linux/mfd/imx25-tsadc.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
> +
> +static const char mx25_tcq_name[] = "mx25-tcq";
> +
> +enum mx25_tcq_mode {
> + MX25_TS_4WIRE,
> +};
> +
> +struct mx25_tcq_priv {
> + struct regmap *regs;
> + struct regmap *core_regs;
> + struct input_dev *idev;
> + enum mx25_tcq_mode mode;
> + unsigned int pen_threshold;
> + unsigned int sample_count;
> + unsigned int expected_samples;
> + unsigned int repeat_wait;
> + unsigned int pen_debounce;
> + unsigned int settling_time;
> + struct clk *clk;
> +};
> +
> +static struct regmap_config mx25_tcq_regconfig = {
> + .fast_io = true,
> + .max_register = 0x5c,
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static struct of_device_id mx25_tcq_ids[] = {
> + { .compatible = "fsl,imx25-tcq", },
> + { /* Senitel */ }
> +};
> +
> +#define TSC_4WIRE_PRE_INDEX 0
> +#define TSC_4WIRE_X_INDEX 1
> +#define TSC_4WIRE_Y_INDEX 2
> +#define TSC_4WIRE_POST_INDEX 3
> +#define TSC_4WIRE_LEAVE 4
> +
> +#define MX25_TSC_DEF_THRESHOLD 80
> +#define TSC_MAX_SAMPLES 16
> +
> +
> +enum mx25_adc_configurations {
> + MX25_CFG_PRECHARGE = 0,
> + MX25_CFG_TOUCH_DETECT,
> + MX25_CFG_X_MEASUREMENT,
> + MX25_CFG_Y_MEASUREMENT,
> +};
> +
> +#define MX25_PRECHARGE_VALUE (\
> + MX25_ADCQ_CFG_YPLL_OFF | \
> + MX25_ADCQ_CFG_XNUR_OFF | \
> + MX25_ADCQ_CFG_XPUL_HIGH | \
> + MX25_ADCQ_CFG_REFP_INT | \
> + MX25_ADCQ_CFG_IN_XP | \
> + MX25_ADCQ_CFG_REFN_NGND2 | \
> + MX25_ADCQ_CFG_IGS)
> +
> +#define MX25_TOUCH_DETECT_VALUE (\
> + MX25_ADCQ_CFG_YNLR | \
> + MX25_ADCQ_CFG_YPLL_OFF | \
> + MX25_ADCQ_CFG_XNUR_OFF | \
> + MX25_ADCQ_CFG_XPUL_OFF | \
> + MX25_ADCQ_CFG_REFP_INT | \
> + MX25_ADCQ_CFG_IN_XP | \
> + MX25_ADCQ_CFG_REFN_NGND2 | \
> + MX25_ADCQ_CFG_PENIACK)
> +
> +static void imx25_setup_queue_cfgs(struct mx25_tcq_priv *priv,
> + unsigned int settling_time)
> +{
> + u32 precharge_cfg =
> + MX25_PRECHARGE_VALUE |
> + MX25_ADCQ_CFG_SETTLING_TIME(settling_time);
> + u32 touch_detect_cfg =
> + MX25_TOUCH_DETECT_VALUE |
> + MX25_ADCQ_CFG_NOS(1) |
> + MX25_ADCQ_CFG_SETTLING_TIME(settling_time);
> +
> + regmap_write(priv->core_regs, MX25_TSC_TICR, precharge_cfg);
> +
> + /* PRECHARGE */
> + regmap_write(priv->regs, MX25_ADCQ_CFG(MX25_CFG_PRECHARGE),
> + precharge_cfg);
> +
> + /* TOUCH_DETECT */
> + regmap_write(priv->regs, MX25_ADCQ_CFG(MX25_CFG_TOUCH_DETECT),
> + touch_detect_cfg);
> +
> + /* X Measurement */
> + regmap_write(priv->regs, MX25_ADCQ_CFG(MX25_CFG_X_MEASUREMENT),
> + MX25_ADCQ_CFG_YPLL_OFF |
> + MX25_ADCQ_CFG_XNUR_LOW |
> + MX25_ADCQ_CFG_XPUL_HIGH |
> + MX25_ADCQ_CFG_REFP_XP |
> + MX25_ADCQ_CFG_IN_YP |
> + MX25_ADCQ_CFG_REFN_XN |
> + MX25_ADCQ_CFG_NOS(priv->sample_count) |
> + MX25_ADCQ_CFG_SETTLING_TIME(settling_time));
> +
> + /* Y Measurement */
> + regmap_write(priv->regs, MX25_ADCQ_CFG(MX25_CFG_Y_MEASUREMENT),
> + MX25_ADCQ_CFG_YNLR |
> + MX25_ADCQ_CFG_YPLL_HIGH |
> + MX25_ADCQ_CFG_XNUR_OFF |
> + MX25_ADCQ_CFG_XPUL_OFF |
> + MX25_ADCQ_CFG_REFP_YP |
> + MX25_ADCQ_CFG_IN_XP |
> + MX25_ADCQ_CFG_REFN_YN |
> + MX25_ADCQ_CFG_NOS(priv->sample_count) |
> + MX25_ADCQ_CFG_SETTLING_TIME(settling_time));
> +
> + /* Enable the touch detection right now */
> + regmap_write(priv->core_regs, MX25_TSC_TICR, touch_detect_cfg |
> + MX25_ADCQ_CFG_IGS);
> +}
> +
> +static int imx25_setup_queue_4wire(struct mx25_tcq_priv *priv,
> + unsigned settling_time, int *items)
> +{
> + imx25_setup_queue_cfgs(priv, settling_time);
> +
> + /* Setup the conversion queue */
> + regmap_write(priv->regs, MX25_ADCQ_ITEM_7_0,
> + MX25_ADCQ_ITEM(0, MX25_CFG_PRECHARGE) |
> + MX25_ADCQ_ITEM(1, MX25_CFG_TOUCH_DETECT) |
> + MX25_ADCQ_ITEM(2, MX25_CFG_X_MEASUREMENT) |
> + MX25_ADCQ_ITEM(3, MX25_CFG_Y_MEASUREMENT) |
> + MX25_ADCQ_ITEM(4, MX25_CFG_PRECHARGE) |
> + MX25_ADCQ_ITEM(5, MX25_CFG_TOUCH_DETECT));
> +
> + /* We measure X/Y with 'sample_count' number of samples and execute a
> + * touch detection twice, with 1 sample each */
> + priv->expected_samples = priv->sample_count * 2 + 2;
> + *items = 6;
> +
> + return 0;
> +}
> +
> +static void mx25_tcq_disable_touch_irq(struct mx25_tcq_priv *priv)
> +{
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_PDMSK,
> + MX25_ADCQ_CR_PDMSK);
> +}
> +
> +static void mx25_tcq_enable_touch_irq(struct mx25_tcq_priv *priv)
> +{
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_PDMSK, 0);
> +}
> +
> +static void mx25_tcq_disable_fifo_irq(struct mx25_tcq_priv *priv)
> +{
> + regmap_update_bits(priv->regs, MX25_ADCQ_MR, MX25_ADCQ_MR_FDRY_IRQ,
> + MX25_ADCQ_MR_FDRY_IRQ);
> +}
> +
> +static void mx25_tcq_enable_fifo_irq(struct mx25_tcq_priv *priv)
> +{
> + regmap_update_bits(priv->regs, MX25_ADCQ_MR, MX25_ADCQ_MR_FDRY_IRQ, 0);
> +}
> +
> +static void mx25_tcq_force_queue_start(struct mx25_tcq_priv *priv)
> +{
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FQS,
> + MX25_ADCQ_CR_FQS);
> +
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FQS, 0);
> +}
> +
> +static void mx25_tcq_force_queue_stop(struct mx25_tcq_priv *priv)
> +{
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FQS, 0);
> +}
> +
> +static void mx25_tcq_fifo_reset(struct mx25_tcq_priv *priv)
> +{
> + u32 tcqcr;
> +
> + regmap_read(priv->regs, MX25_ADCQ_CR, &tcqcr);
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FRST,
> + MX25_ADCQ_CR_FRST);
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_FRST,
> + 0);
> + regmap_write(priv->regs, MX25_ADCQ_CR, tcqcr);
> +}
> +
> +static void mx25_tcq_re_enable_touch_detection(struct mx25_tcq_priv *priv)
> +{
> + /* stop the queue from looping */
> + mx25_tcq_force_queue_stop(priv);
> +
> + /* for a clean touch detection, preload the X plane */
> + regmap_write(priv->core_regs, MX25_TSC_TICR, MX25_PRECHARGE_VALUE);
> +
> + /* waste some time now to pre-load the X plate to high voltage */
> + mx25_tcq_fifo_reset(priv);
> +
> + /* re-enable the detection right now */
> + regmap_write(priv->core_regs, MX25_TSC_TICR, MX25_TOUCH_DETECT_VALUE |
> + MX25_ADCQ_CFG_IGS);
> +
> + regmap_update_bits(priv->regs, MX25_ADCQ_SR, MX25_ADCQ_SR_PD,
> + MX25_ADCQ_SR_PD);
> +
> + /* enable the pen down event to be a source for the interrupt */
> + regmap_update_bits(priv->regs, MX25_ADCQ_MR, MX25_ADCQ_MR_PD_IRQ, 0);
> +
> + /* lets fire the next IRQ if someone touches the touchscreen */
> + mx25_tcq_enable_touch_irq(priv);
> +}
> +
> +static int mx25_tcq_create_event_for_4wire(struct mx25_tcq_priv *priv,
> + u32 *sample_buf, int samples)
> +{
> + unsigned int x_pos = 0;
> + unsigned int y_pos = 0;
> + unsigned int touch_pre = 0;
> + unsigned int touch_post = 0;
> + unsigned i;
> + int ret = 0;
> +
> + for (i = 0; i < samples; i++) {
> + unsigned int index = MX25_ADCQ_FIFO_ID(sample_buf[i]);
> + unsigned int val = MX25_ADCQ_FIFO_DATA(sample_buf[i]);
> +
> + switch (index) {
> + case 1:
> + touch_pre = val;
> + break;
> + case 2:
> + x_pos = val;
> + break;
> + case 3:
> + y_pos = val;
> + break;
> + case 5:
> + touch_post = val;
> + break;
> + default:
> + ret = -EINVAL;
> + break;
> + }
> + }
> +
> + if (ret == 0 && samples != 0) {
> + /*
> + * only if both touch measures are below a treshold,
> + * the position is valid
> + */
> + if (touch_pre < priv->pen_threshold &&
> + touch_post < priv->pen_threshold) {
> + /* valid samples, generate a report */
> + x_pos /= priv->sample_count;
> + y_pos /= priv->sample_count;
> + input_report_abs(priv->idev, ABS_X, x_pos);
> + input_report_abs(priv->idev, ABS_Y, y_pos);
> + input_report_key(priv->idev, BTN_TOUCH,
> + 0xfff - ((touch_pre + touch_post) / 2));
Hmm, are you trying to report pressure here?
> + input_sync(priv->idev);
> +
> + /* get next sample */
> + mx25_tcq_force_queue_start(priv);
> + mx25_tcq_enable_fifo_irq(priv);
> + } else {
> + if (touch_pre >= priv->pen_threshold &&
You can convert this to "else if" and save indentation level here.
> + touch_post >= priv->pen_threshold) {
> + /*
> + * if both samples are invalid,
> + * generate a release report
> + */
> + input_report_key(priv->idev, BTN_TOUCH, 0);
> + input_sync(priv->idev);
> + mx25_tcq_re_enable_touch_detection(priv);
> + } else {
> + /*
> + * if only one of both touch measurements are
> + * below the threshold, still some bouncing
> + * happens. Take additional samples in this
> + * case to be sure
> + */
> + mx25_tcq_force_queue_start(priv);
> + mx25_tcq_enable_fifo_irq(priv);
> + }
> + }
> + }
> +
> + return ret;
> +}
> +
> +static irqreturn_t mx25_tcq_irq_thread(int irq, void *dev_id)
> +{
> + struct mx25_tcq_priv *priv = (struct mx25_tcq_priv *) dev_id;
> + u32 sample_buf[TSC_MAX_SAMPLES];
> + int samples = 0;
> +
> + /* read all samples */
> + while (1) {
> + u32 stats;
> +
> + regmap_read(priv->regs, MX25_ADCQ_SR, &stats);
Error handling for I/O operations?
> + if (stats & MX25_ADCQ_SR_EMPT)
> + break;
> +
> + if (samples < TSC_MAX_SAMPLES) {
> + regmap_read(priv->regs, MX25_ADCQ_FIFO,
> + &sample_buf[samples]);
> + ++samples;
> + } else {
> + u32 discarded;
> + /* discard samples */
> + regmap_read(priv->regs, MX25_ADCQ_FIFO, &discarded);
Should there be some upper bound for number of discarded samples?
> + }
> + }
> +
> + mx25_tcq_create_event_for_4wire(priv, sample_buf, samples);
> +
> + return IRQ_HANDLED;
> +}
> +
> +static irqreturn_t mx25_tcq_irq(int irq, void *dev_id)
> +{
> + struct mx25_tcq_priv *priv = (struct mx25_tcq_priv *)dev_id;
> + u32 stat;
> + int ret = IRQ_HANDLED;
> +
> + regmap_read(priv->regs, MX25_ADCQ_SR, &stat);
> +
> + if (stat & (MX25_ADCQ_SR_FRR | MX25_ADCQ_SR_FUR | MX25_ADCQ_SR_FOR))
> + mx25_tcq_fifo_reset(priv);
> +
> + if (stat & MX25_ADCQ_SR_PD) {
> + mx25_tcq_disable_touch_irq(priv);
> + mx25_tcq_force_queue_start(priv);
> + mx25_tcq_enable_fifo_irq(priv);
> + }
> +
> + if (stat & MX25_ADCQ_SR_FDRY) {
> + mx25_tcq_disable_fifo_irq(priv);
> + ret = IRQ_WAKE_THREAD;
> + }
> +
> + regmap_update_bits(priv->regs, MX25_ADCQ_SR, MX25_ADCQ_SR_FRR |
> + MX25_ADCQ_SR_FUR | MX25_ADCQ_SR_FOR | MX25_ADCQ_SR_PD |
> + MX25_ADCQ_SR_EOQ,
> + MX25_ADCQ_SR_FRR |
> + MX25_ADCQ_SR_FUR | MX25_ADCQ_SR_FOR | MX25_ADCQ_SR_PD |
> + MX25_ADCQ_SR_EOQ);
> +
> + return ret;
> +}
> +
> +/* configure the statemachine for a 4-wire touchscreen */
> +static int mx25_tcq_init(struct mx25_tcq_priv *priv)
> +{
> + u32 tgcr;
> + unsigned int ipg_div;
> + unsigned int adc_period;
> + unsigned int repeat_wait;
> + unsigned int debounce_cnt;
> + unsigned int settling_time;
> + int itemct;
> + int ret;
> +
> + regmap_read(priv->core_regs, MX25_TSC_TGCR, &tgcr);
> + ipg_div = max_t(unsigned int, 4, MX25_TGCR_GET_ADCCLK(tgcr));
> + adc_period = clk_get_rate(priv->clk) / (ipg_div * 2 + 2);
> + repeat_wait = fls(DIV_ROUND_UP(priv->repeat_wait, adc_period));
> + debounce_cnt = DIV_ROUND_UP(priv->pen_debounce, adc_period * 8) - 1;
> + settling_time = DIV_ROUND_UP(priv->settling_time, adc_period);
> +
> +
> + /* Reset */
> + regmap_write(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_QRST |
> + MX25_ADCQ_CR_FRST);
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_QRST |
> + MX25_ADCQ_CR_FRST, 0);
> +
> + /* up to 128 * 8 ADC clocks are possible */
> + if (debounce_cnt > 127)
> + debounce_cnt = 127;
> +
> + if (repeat_wait > 15)
> + repeat_wait = 15;
> +
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_RWAIT_MASK,
> + MX25_ADCQ_CR_RWAIT(repeat_wait));
> +
> + ret = imx25_setup_queue_4wire(priv, 0x0, &itemct);
> + if (ret)
> + return ret;
> +
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_LITEMID_MASK |
> + MX25_ADCQ_CR_WMRK_MASK,
> + MX25_ADCQ_CR_LITEMID(itemct - 1) |
> + MX25_ADCQ_CR_WMRK(priv->expected_samples - 1));
> +
> + /* setup debounce count */
> + regmap_update_bits(priv->core_regs, MX25_TSC_TGCR,
> + MX25_TGCR_PDBTIME_MASK,
> + MX25_TGCR_PDBTIME(debounce_cnt));
> +
> + /* enable debounce */
> + regmap_update_bits(priv->core_regs, MX25_TSC_TGCR, MX25_TGCR_PDBEN,
> + MX25_TGCR_PDBEN);
> + regmap_update_bits(priv->core_regs, MX25_TSC_TGCR, MX25_TGCR_PDEN,
> + MX25_TGCR_PDEN);
> +
> + /* enable the engine on demand */
> + regmap_update_bits(priv->regs, MX25_ADCQ_CR, MX25_ADCQ_CR_QSM_FQS,
> + MX25_ADCQ_CR_QSM_FQS);
> +
> + mx25_tcq_re_enable_touch_detection(priv);
> +
> + return 0;
> +}
> +
> +static int mx25_tcq_parse_dt(struct platform_device *pdev,
> + struct mx25_tcq_priv *priv)
> +{
> + struct device_node *np = pdev->dev.of_node;
> + u32 wires;
> + int ret;
> +
> + /* Setup defaults */
> + priv->pen_threshold = 500;
> + priv->sample_count = 3;
> + priv->repeat_wait = 15000000;
> + priv->pen_debounce = 1000000;
> + priv->settling_time = 250000;
> +
> + ret = of_property_read_u32(np, "fsl,wires", &wires);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to find fsl,wires properties\n");
> + return ret;
> + }
> +
> + if (wires == 4) {
> + priv->mode = MX25_TS_4WIRE;
> + } else {
> + dev_err(&pdev->dev, "%u-wire mode not supported\n", wires);
> + return -EINVAL;
> + }
> +
> + /* These are optional, we don't care about the return values */
> + of_property_read_u32(np, "fsl,pen-threshold", &priv->pen_threshold);
> + of_property_read_u32(np, "fsl,settling-time", &priv->settling_time);
> + of_property_read_u32(np, "fsl,pen-debounce", &priv->pen_debounce);
> +
> + return 0;
> +}
> +
> +static int mx25_tcq_probe(struct platform_device *pdev)
> +{
> + struct device *dev = &pdev->dev;
> + struct input_dev *idev;
> + struct mx25_tcq_priv *priv;
> + struct resource *res;
> + void __iomem *mem;
> + int ret;
> + int irq;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + mem = devm_ioremap_resource(dev, res);
> + if (!mem) {
> + dev_err(dev, "Failed to get iomem");
> + return -ENOMEM;
> + }
> +
> + ret = mx25_tcq_parse_dt(pdev, priv);
> + if (ret)
> + return ret;
> +
> + priv->regs = devm_regmap_init_mmio(dev, mem, &mx25_tcq_regconfig);
> + if (IS_ERR(priv->regs)) {
> + dev_err(dev, "Failed to initialize regmap\n");
> + return PTR_ERR(priv->regs);
> + }
> +
> + irq = platform_get_irq(pdev, 0);
> + if (irq < 0) {
> + dev_err(dev, "Failed to get IRQ\n");
> + return irq;
> + }
> +
> + ret = devm_request_threaded_irq(dev, irq, mx25_tcq_irq,
> + mx25_tcq_irq_thread, IRQF_ONESHOT, pdev->name, priv);
> + if (ret) {
> + dev_err(dev, "Failed requesting IRQ\n");
> + return ret;
> + }
Are we sure the device is quiesce here? Otherwise interrupts will start
coming but input device is not there yet.
> +
> + idev = devm_input_allocate_device(dev);
> + if (!idev) {
> + dev_err(dev, "Failed to allocate input device\n");
> + return -ENOMEM;
> + }
> +
> + idev->name = mx25_tcq_name;
> + idev->evbit[0] = BIT_MASK(EV_KEY) | BIT_MASK(EV_ABS);
> + idev->keybit[BIT_WORD(BTN_TOUCH)] = BIT_MASK(BTN_TOUCH);
> + input_set_abs_params(idev, ABS_X, 0, 0xfff, 0, 0);
> + input_set_abs_params(idev, ABS_Y, 0, 0xfff, 0, 0);
> +
> + idev->id.bustype = BUS_HOST;
> +
> + ret = input_register_device(idev);
> + if (ret) {
> + dev_err(dev, "Failed to register input device\n");
> + return ret;
> + }
> +
> + priv->idev = idev;
> +
> + priv->core_regs = mx25_tsadc_get_regmap(pdev->dev.parent);
> + priv->clk = mx25_tsadc_get_ipg(pdev->dev.parent);
> +
> + ret = clk_prepare_enable(priv->clk);
> + if (ret) {
> + dev_err(dev, "Failed to enable ipg clock\n");
> + return ret;
> + }
> +
> + ret = mx25_tcq_init(priv);
> + if (ret) {
> + dev_err(dev, "Failed to init tcq\n");
> + goto error_tcq_init;
> + }
> +
> + platform_set_drvdata(pdev, priv);
> +
> + return 0;
> +
> +error_tcq_init:
> + clk_disable_unprepare(priv->clk);
> + return ret;
> +}
> +
> +static int mx25_tcq_remove(struct platform_device *pdev)
> +{
> + struct mx25_tcq_priv *priv = platform_get_drvdata(pdev);
> +
> + clk_disable_unprepare(priv->clk);
Hmm, if you disable clk all other operations will likely to fail. We
really need devm clk interface, I guess I need to dust off my old
patch...
> +
> + return 0;
> +}
> +
> +static struct platform_driver mx25_tcq_driver = {
> + .driver = {
> + .name = "mx25-tcq",
> + .owner = THIS_MODULE,
> + .of_match_table = mx25_tcq_ids,
> + },
> + .probe = mx25_tcq_probe,
> + .remove = mx25_tcq_remove,
> +};
> +module_platform_driver(mx25_tcq_driver);
> +
> +MODULE_DESCRIPTION("TS input driver for Freescale mx25");
> +MODULE_AUTHOR("Markus Pargmann <mpa-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>");
> +MODULE_LICENSE("GPL v2");
> --
> 1.8.5.3
>
Thanks.
--
Dmitry
^ permalink raw reply
* Re: is it possible to temporarily not let user mode get hid input event
From: loody @ 2014-02-23 6:52 UTC (permalink / raw)
To: David Herrmann; +Cc: open list:HID CORE LAYER, linux-usb@vger.kernel.org
In-Reply-To: <CANq1E4SJDz2q0Rgn1f7u_b0w-mjVTte8=G2_qL38QnahDkUC1Q@mail.gmail.com>
hi David:
Thanks for your suggestion.
2014-02-23 0:56 GMT+08:00 David Herrmann <dh.herrmann@gmail.com>:
> Hi
>
> On Sat, Feb 22, 2014 at 5:35 PM, loody <miloody@gmail.com> wrote:
>> hi all:
>> is there any kernel hid module parameter or test program can
>> temporarily not letting user mode program not receiving hid event?
>> 1. My hid kos are still inserted in.
>> 2. the kernel usb driver is working well; that mean kernel usb driver
>> still handle interrupt transaction.
>>
>> I just not want user mode program see the hid event for a while,
>
> For each connected HID device, there is a driver bound to it that
> reads the events and forwards them to HID core. What you can do, is to
> unbind a driver on a given device:
> echo "<your-device-name>" >/sys/bus/hid/drivers/<driver-name>/unbind
> The device-name is the directory name in:
> /sys/bus/hid/devices/
> The driver name is usually "hid-generic" but can be figured out for
> each device by looking at the "driver" symlink in it's directry.
> However, this is *really* just meant for debugging. This is not
> recommended for anything serious. There is no support for that and if
> you don't know what all this does, you shouldn't use it.
>
> There is no proper way to disable a single device in the kernel.
> User-space is supposed to control device-access so we probably won't
> add such features to the kernel. If you describe your use-case in more
> details, we can try to give hints how to get that working.
Sorry for not describing our situation clearer previously,
The problem we met like below
a. once plug in usb hid mouse and fast moving mouse
b. the screen will get blur.
We want to know whether the screen blur is caused by
1. the interrupt frequency of usb mouse is too high for our embedded
system that make video decode slow
2. something wrong between hw cursor and video overlay.
if we can deceive user mode program there is no mouse event, but
kernel usb level still get hid interrupt transaction.
We may clarify whether above 1) conclusion is correct.
Appreciate your kind help :-)
^ permalink raw reply
* [PATCH 1/1] Input: don't modify the id of ioctl-provided ff effect on upload failure
From: Elias Vanderstuyft @ 2014-02-23 14:18 UTC (permalink / raw)
To: Dmitry Torokhov, Anssi Hannula; +Cc: linux-input, Michal Malý
From: Elias Vanderstuyft <elias.vds@gmail.com>
If a new (id == -1) ff effect was uploaded from userspace,
ff-core.c::input_ff_upload() will have assigned
a positive number to the new effect id.
Currently, evdev.c::evdev_do_ioctl() will save this new id to userspace,
regardless of whether the upload succeeded or not.
On upload failure, this can be confusing because the dev->ff->effects[] array
will not contain an element at the index of that new effect id.
Note: Unfortunately applications should still expect changed effect id for
quite some time.
This has been discussed on:
http://www.mail-archive.com/linux-input@vger.kernel.org/msg08513.html
("ff-core effect id handling in case of a failed effect upload")
Suggested-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Elias Vanderstuyft <elias.vds@gmail.com>
---
drivers/input/evdev.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/input/evdev.c 2014-02-23 14:21:19.980606615 +0100
+++ b/drivers/input/evdev.c 2014-02-23 14:25:04.417118859 +0100
@@ -954,11 +954,13 @@ static long evdev_do_ioctl(struct file *
return -EFAULT;
error = input_ff_upload(dev, &effect, file);
+ if (error)
+ return error;
if (put_user(effect.id, &(((struct ff_effect __user *)p)->id)))
return -EFAULT;
- return error;
+ return 0;
}
/* Multi-number variable-length handlers */
^ permalink raw reply
* Re: ff-core effect id handling in case of a failed effect upload
From: Elias Vanderstuyft @ 2014-02-23 14:27 UTC (permalink / raw)
To: Dmitry Torokhov; +Cc: Anssi Hannula, linux-input, wine-devel
In-Reply-To: <20140223063043.GB10151@core.coreip.homeip.net>
I sent a patch, see:
http://www.mail-archive.com/linux-input@vger.kernel.org/msg08572.html
("[PATCH 1/1] Input: don't modify the id of ioctl-provided ff effect
on upload failure")
Elias
On Sun, Feb 23, 2014 at 7:30 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Wed, Feb 19, 2014 at 11:14:18PM +0100, Elias Vanderstuyft wrote:
>> On Wed, Feb 19, 2014 at 10:05 PM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Wed, Feb 19, 2014 at 06:49:36PM +0200, Anssi Hannula wrote:
>> >> (added Dmitry to CC)
>> >>
>> >> 19.02.2014 13:42, Elias Vanderstuyft kirjoitti:
>> >> > Hi,
>> >> >
>> >>
>> >> Hi,
>> >>
>> >> > In the process of reviewing the Wine DInput translation layer, I
>> >> > noticed an inconvenience (in the ff-core implementation?) that can
>> >> > possibly lead to confusing problems to application developers (not
>> >> > only for Wine), in short:
>> >> > If a new (id==-1) effect was uploaded (look at
>> >> > ff-core.c::input_ff_upload(...)) that failed (e.g. returning EINVAL),
>> >> > ff-core will have assigned a positive number to the effect id. This
>> >> > can be confusing because the dev->ff->effects[] array will not contain
>> >> > an element at the index of that new effect id.
>> >>
>> >> I agree that this is a bit confusing, and the kernel code should
>> >> probably be modified to not clobber the ioctl-provided effect on failure
>> >> (effect->id is set to an "undefined" value, i.e. next free effect slot).
>> >>
>> >> Dmitry, WDYT?
>> >
>> > Yeah, it looks like we need to change evdev.c to read:
>> >
>> > error = input_ff_upload(dev, &effect, file);
>> > if (error)
>> > return error;
>> >
>> > if (put_user(effect.id, &(((struct ff_effect __user *)p)->id)))
>> > return -EFAULT;
>> >
>> > return 0;
>>
>> Alright, who will create the patch?
>> Do I may / have to do it?
>
> If you could create the patch that would be appreciated.
>
> Thanks.
>
> --
> Dmitry
^ permalink raw reply
* Re: is it possible to temporarily not let user mode get hid input event
From: David Herrmann @ 2014-02-23 15:16 UTC (permalink / raw)
To: loody; +Cc: open list:HID CORE LAYER, linux-usb@vger.kernel.org
In-Reply-To: <CANudz+tdWrCLpARFQznQfhkF-r2J-STY68xdBJc+BK5C=tKsjA@mail.gmail.com>
Hi
On Sun, Feb 23, 2014 at 7:52 AM, loody <miloody@gmail.com> wrote:
> hi David:
>
> Thanks for your suggestion.
> 2014-02-23 0:56 GMT+08:00 David Herrmann <dh.herrmann@gmail.com>:
>> Hi
>>
>> On Sat, Feb 22, 2014 at 5:35 PM, loody <miloody@gmail.com> wrote:
>>> hi all:
>>> is there any kernel hid module parameter or test program can
>>> temporarily not letting user mode program not receiving hid event?
>>> 1. My hid kos are still inserted in.
>>> 2. the kernel usb driver is working well; that mean kernel usb driver
>>> still handle interrupt transaction.
>>>
>>> I just not want user mode program see the hid event for a while,
>>
>> For each connected HID device, there is a driver bound to it that
>> reads the events and forwards them to HID core. What you can do, is to
>> unbind a driver on a given device:
>> echo "<your-device-name>" >/sys/bus/hid/drivers/<driver-name>/unbind
>> The device-name is the directory name in:
>> /sys/bus/hid/devices/
>> The driver name is usually "hid-generic" but can be figured out for
>> each device by looking at the "driver" symlink in it's directry.
>> However, this is *really* just meant for debugging. This is not
>> recommended for anything serious. There is no support for that and if
>> you don't know what all this does, you shouldn't use it.
>>
>> There is no proper way to disable a single device in the kernel.
>> User-space is supposed to control device-access so we probably won't
>> add such features to the kernel. If you describe your use-case in more
>> details, we can try to give hints how to get that working.
>
> Sorry for not describing our situation clearer previously,
>
> The problem we met like below
> a. once plug in usb hid mouse and fast moving mouse
> b. the screen will get blur.
>
> We want to know whether the screen blur is caused by
> 1. the interrupt frequency of usb mouse is too high for our embedded
> system that make video decode slow
> 2. something wrong between hw cursor and video overlay.
>
> if we can deceive user mode program there is no mouse event, but
> kernel usb level still get hid interrupt transaction.
> We may clarify whether above 1) conclusion is correct.
>
> Appreciate your kind help :-)
You can unload the HID driver as described above, but that's unlikely
to fix any interrupt issues. How about you compile your kernel without
usbhid support? (CONFIG_USB_HID)
David
^ permalink raw reply
* [PATCH] input: Use platform-provided devices as i8042 serio parents
From: Matthew Garrett @ 2014-02-23 17:03 UTC (permalink / raw)
To: dmitry.torokhov
Cc: linux-input, linux-kernel, benjamin.tissoires, Matthew Garrett
i8042 devices exposed via platform firmware interfaces such as ACPI or
Device Tree may provide additional information of use to userspace. Right
now we don't associate the serio devices with the firmware device, and so
there's no straightforward way for userspace to make use of that
information. This patch simply moves the serio parent device to the firmware
provided device.
Signed-off-by: Matthew Garrett <matthew.garrett@nebula.com>
Tested-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
---
drivers/input/serio/i8042-sparcio.h | 2 ++
drivers/input/serio/i8042-x86ia64io.h | 2 ++
drivers/input/serio/i8042.c | 12 ++++++++++--
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/input/serio/i8042-sparcio.h b/drivers/input/serio/i8042-sparcio.h
index d6aa4c6..7bd8e2c 100644
--- a/drivers/input/serio/i8042-sparcio.h
+++ b/drivers/input/serio/i8042-sparcio.h
@@ -65,6 +65,7 @@ static int sparc_i8042_probe(struct platform_device *op)
kbd_iobase = of_ioremap(&kbd->resource[0],
0, 8, "kbd");
kbd_res = &kbd->resource[0];
+ i8042_kbd_parent = &kbd->dev;
} else if (!strcmp(dp->name, OBP_PS2MS_NAME1) ||
!strcmp(dp->name, OBP_PS2MS_NAME2)) {
struct platform_device *ms = of_find_device_by_node(dp);
@@ -72,6 +73,7 @@ static int sparc_i8042_probe(struct platform_device *op)
if (irq == 0xffffffff)
irq = op->archdata.irqs[0];
i8042_aux_irq = irq;
+ i8042_aux_parent = &ms->dev;
}
dp = dp->sibling;
diff --git a/drivers/input/serio/i8042-x86ia64io.h b/drivers/input/serio/i8042-x86ia64io.h
index 0ec9abb..47dcdf1 100644
--- a/drivers/input/serio/i8042-x86ia64io.h
+++ b/drivers/input/serio/i8042-x86ia64io.h
@@ -723,6 +723,7 @@ static int i8042_pnp_kbd_probe(struct pnp_dev *dev, const struct pnp_device_id *
device_set_wakeup_enable(&dev->dev, true);
i8042_pnp_kbd_devices++;
+ i8042_kbd_parent = &dev->dev;
return 0;
}
@@ -744,6 +745,7 @@ static int i8042_pnp_aux_probe(struct pnp_dev *dev, const struct pnp_device_id *
}
i8042_pnp_aux_devices++;
+ i8042_aux_parent = &dev->dev;
return 0;
}
diff --git a/drivers/input/serio/i8042.c b/drivers/input/serio/i8042.c
index 020053f..86da76f 100644
--- a/drivers/input/serio/i8042.c
+++ b/drivers/input/serio/i8042.c
@@ -87,6 +87,8 @@ MODULE_PARM_DESC(debug, "Turn i8042 debugging mode on and off");
#endif
static bool i8042_bypass_aux_irq_test;
+static struct device *i8042_kbd_parent;
+static struct device *i8042_aux_parent;
#include "i8042.h"
@@ -1215,7 +1217,10 @@ static int __init i8042_create_kbd_port(void)
serio->stop = i8042_stop;
serio->close = i8042_port_close;
serio->port_data = port;
- serio->dev.parent = &i8042_platform_device->dev;
+ if (i8042_kbd_parent)
+ serio->dev.parent = i8042_kbd_parent;
+ else
+ serio->dev.parent = &i8042_platform_device->dev;
strlcpy(serio->name, "i8042 KBD port", sizeof(serio->name));
strlcpy(serio->phys, I8042_KBD_PHYS_DESC, sizeof(serio->phys));
@@ -1240,7 +1245,10 @@ static int __init i8042_create_aux_port(int idx)
serio->start = i8042_start;
serio->stop = i8042_stop;
serio->port_data = port;
- serio->dev.parent = &i8042_platform_device->dev;
+ if (i8042_aux_parent)
+ serio->dev.parent = i8042_aux_parent;
+ else
+ serio->dev.parent = &i8042_platform_device->dev;
if (idx < 0) {
strlcpy(serio->name, "i8042 AUX port", sizeof(serio->name));
strlcpy(serio->phys, I8042_AUX_PHYS_DESC, sizeof(serio->phys));
--
1.8.5.3
^ permalink raw reply related
* Messenger from Administrator
From: Technical Support Team @ 2014-02-23 22:38 UTC (permalink / raw)
Our records indicate that your E-mail® Account could not be automatically
updated with our F-Secure R-HTK4S new(2014) version
anti-spam/anti-virus/anti-spyware. Please click this link below to update
manually
http://www.contactme.com/5308b7ab5becae0002004e69
We Are Sorry For Any Inconvenience.
Verification Code: SQP4039VE
Regards,
Technical Support Team
--
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: [patch] Input: remove a duplicative NULL test
From: Jingoo Han @ 2014-02-23 23:23 UTC (permalink / raw)
To: fugang.duan@freescale.com, Dan Carpenter, Dmitry Torokhov
Cc: Paul Gortmaker, Benson Leung, Daniel Kurtz,
linux-input@vger.kernel.org, kernel-janitors@vger.kernel.org,
Jingoo Han
On Friday, February 21, 2014 6:15 PM, fugang.duan@freescale.com wrote:
>
> From: Dan Carpenter <dan.carpenter@oracle.com>
> Data: Friday, February 21, 2014 4:55 PM
>
> >To: Dmitry Torokhov
> >Cc: Paul Gortmaker; Jingoo Han; Duan Fugang-B38611; Benson Leung; Daniel Kurtz;
> >linux-input@vger.kernel.org; kernel-janitors@vger.kernel.org
> >Subject: [patch] Input: remove a duplicative NULL test
> >
> >"pdata" is non-NULL here. We verified that at the start of the function.
> >
> >Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
> >
> >diff --git a/drivers/input/touchscreen/atmel_mxt_ts.c
> >b/drivers/input/touchscreen/atmel_mxt_ts.c
> >index a70400754e92..40abe90cc924 100644
> >--- a/drivers/input/touchscreen/atmel_mxt_ts.c
> >+++ b/drivers/input/touchscreen/atmel_mxt_ts.c
> >@@ -1146,7 +1146,7 @@ static int mxt_probe(struct i2c_client *client,
> > goto err_free_mem;
> > }
> >
> >- data->is_tp = pdata && pdata->is_tp;
> >+ data->is_tp = pdata->is_tp;
> >
> > input_dev->name = (data->is_tp) ? "Atmel maXTouch Touchpad" :
> > "Atmel maXTouch Touchscreen";
> >
> Agree, it is redundant. And if you have free time, you can convert the driver to support devicetree.
>
> Acked-by: Fugang Duan <B38611@freescale.com>
Reviewed-by: Jingoo Han <jg1.han@samsung.com>
Best regards,
Jingoo Han
^ 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