Re: [PATCH v3 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

igned-off-by: Pradeep Goudagunta <pgoudagu...@nvidia.com> > Signed-off-by: H. Nikolaus Schaller <h...@goldelico.com> > Signed-off-by: Marek Belisko <ma...@goldelico.com> > Acked-by: Laxman Dewangan <ldewan...@nvidia.com> > Reviewed-by: Jonathan Cameron <j

Re: [PATCH v3 2/3] iio:adc:palmas: add DT support

On 16/10/15 13:53, H. Nikolaus Schaller wrote: > From: Marek Belisko > > Code was found at: > https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1 > > Signed-off-by: Laxman Dewangan > Signed-off-by: Marek

Re: [PATCH 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

On 04/10/15 17:04, H. Nikolaus Schaller wrote: > > Am 27.09.2015 um 17:21 schrieb Jonathan Cameron <ji...@kernel.org>: > >> On 23/09/15 13:48, H. Nikolaus Schaller wrote: >>> This driver code was found as: >>> >>&g

Re: [PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

d device however so I guess this is fine from that point of view. Reviewed-by: Jonathan Cameron <ji...@kernel.org> > --- > drivers/iio/adc/Kconfig| 9 + > drivers/iio/adc/Makefile | 1 + > drivers/iio/adc/palmas_gpadc.c | 818 > +++

Re: [PATCH 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

On 23/09/15 13:48, H. Nikolaus Schaller wrote: > This driver code was found as: > > https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc > > Fixed various compilation issues and test this driver on omap5 evm. > > Signed-off-by: Pradeep

Re: [PATCH 2/3] iio:adc:palmas: add DT support

On 23/09/15 13:49, H. Nikolaus Schaller wrote: > From: Marek Belisko > > Code was found at: > https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1 > > Signed-off-by: Laxman Dewangan > [Fixed minor typos +

Re: [V4] [TWL4030 MADC] Fix ADC[3:6] readings

isn't going to reply. As such I've just applied it as is to the fixes-togreg branch of iio.git (with some editing of the patch description!) Thanks, Jonathan > > > > On Sat, Aug 8, 2015 at 8:15 AM Jonathan Cameron <ji...@kernel.org > <mailto:ji...@kernel.org>> wrote:

Re: [V4] [TWL4030 MADC] Fix ADC[3:6] readings

On 04/08/15 19:15, Adam YH Lee wrote: MADC[3:6] reads incorrect values without these two following changes: - enable the 3v1 bias regulator for ADC[3:6] - configure ADC[3:6] lines as input, not as USB Signed-off-by: Adam YH Lee adam.yh@gmail.com I'd ideally like an ack from the driver

Re: [V3] [TWL4030 MADC] Fix ADC[3:6] readings

On 21/07/15 01:49, Adam YH Lee wrote: MADC[3:6] reads incorrect values without these two following changes: - enable the 3v1 bias regulator for ADC[3:6] - configure ADC[3:6] lines as input, not as USB Signed-off-by: Adam YH Lee adam.yh@gmail.com --- drivers/iio/adc/twl4030-madc.c |

Re: [PATCH] [TWL4030 MADC] Fix ADC[3:6] readings

On 20/07/15 18:47, Adam Lee wrote: Hello, here is some more context from the TPS65950's TRM [1]. Quoting from section 15.3.1.2.1 VUSB3V1 section: VUSB3V1 is also used to bias analog multiplexers on the four MCPC pins between the carkit and the MADC (supplied by VINTANA2). And from

Re: [PATCH 1/5] input: touchscreen: ti_am335x_tsc Interchange touchscreen and ADC steps

in the order Y-Z-X. Signed-off-by: Brad Griffis bgrif...@ti.com [vigne...@ti.com: Ported the patch from v3.12 to v3.18rc2] Signed-off-by: Vignesh R vigne...@ti.com For the tiny bit in IIO Acked-by: Jonathan Cameron ji...@kernel.org All yours Lee/Dmitry. Jonathan --- drivers/iio/adc

Re: [PATCH v3 4/6] iio: Add ABI docs for pulse capture devices

On 05/02/14 19:01, Matt Porter wrote: Add standard ABI entries for pulse capture devices. Also add a separate ABI entry for the TI ECAP driver polarity option. Signed-off-by: Matt Porter mpor...@linaro.org Lars, I've cc'd you for the various Analog devices dds and frequency devices. Ideally we

Re: [PATCH v3 3/6] iio: enable selection and build of pulse drivers

On 05/02/14 19:01, Matt Porter wrote: Add the pulse driver subdirectory when configuring and building IIO. Signed-off-by: Matt Porter mpor...@linaro.org Hi Matt, This wants rolling into the driver patch before it. No point it giving it it's own patch. This will just lead to confusion on git

Re: [PATCH v3 6/6] ARM: dts: AM33XX: Add ecap interrupt properties

On 05/02/14 19:01, Matt Porter wrote: Add missing interrupt properties to the ecap0, ecap1, and ecap2 nodes. Signed-off-by: Matt Porter mpor...@linaro.org This one is unconnected from the rest of the series really so should go into the relevant arch tree whenever it make sense. Jonathan ---

Re: [PATCH v3 0/6] IIO pulse capture support for TI ECAP

On 05/02/14 20:23, Sergei Shtylyov wrote: Hello. On 02/05/2014 10:01 PM, Matt Porter wrote: [...] This series adds support for PWM capture devices within IIO and adds a TI ECAP IIO driver. PWM capture devices are supported using a new IIO pulse channel type. The IIO ECAP driver

Re: [PATCH v3 2/6] iio: pulse: add TI ECAP driver

On 05/02/14 19:01, Matt Porter wrote: Adds support for capturing PWM signals using the TI ECAP peripheral. This driver supports triggered buffer capture of pulses on multiple ECAP instances. In addition, the driver supports configurable polarity of the signal to be captured. Signed-off-by: Matt

Re: [PATCH v8 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

On 08/15/13 06:45, Oleksandr Kozaruk wrote: Hello Jonathan, Thank you for the review and valuable comments. Multiple authors are done by having multiple MODULE_AUTHOR lines rather as one long string. See include/linux/module.h. I fixed that up and dealt with some trivial fuzz

Re: [PATCH v8 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

On 07/25/13 14:26, Oleksandr Kozaruk wrote: The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring

Re: [PATCH v6 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

On 07/19/2013 10:27 AM, Oleksandr Kozaruk wrote: The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring

Re: [PATCH 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

Oleksandr Kozaruk oleksandr.koza...@ti.com wrote: Hello Jonathan, Two very quick comments based on quick glance as it may be a while before I can do a full review. We still have channels that are only usable for temperature being output to user space as voltage channels? Is the conversion

Re: [PATCH v3 2/2] iio: twl6030-gpadc: TWL6030, TWL6032 GPADC driver

On 07/12/2013 08:18 AM, Oleksandr Kozaruk wrote: The GPADC is general purpose ADC found on TWL6030, and TWL6032 PMIC, known also as Phoenix and PhoenixLite. The TWL6030 and TWL6032 have GPADC with 17 and 19 channels respectively. Some channels have current source and are used for measuring

Re: am335x: TSC ADC reworking including DT pieces, take 4

Samuel Ortiz sa...@linux.intel.com wrote: Hi Dmitry, On Tue, Jun 11, 2013 at 09:04:16AM -0700, Dmitry Torokhov wrote: On Tue, Jun 11, 2013 at 04:23:58PM +0200, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the

Re: am335x: TSC ADC reworking including DT pieces, take 4

On 06/11/2013 03:23 PM, Samuel Ortiz wrote: Hi Sebastian, On Tue, Jun 11, 2013 at 01:30:46PM +0200, Sebastian Andrzej Siewior wrote: I believe the whole thing should go via the MFD tree. It touches also input iio subsystem. I collected ACKs where I got some in the meantime. Please fix your

Re: [PATCH] ti_tscadc: Update with IIO map interface deal with partial activation

On 05/06/2013 01:48 PM, Jan Luebbe wrote: Hi Pantelis, while trying out your patch on a custom AM335x board, I noticed that the sysfs entries ware missing. This is fixed in the first patch, you might want to squash that into your original patch. The second one makes sure that the iio

Re: [PATCH 2/3] ti_tscadc: Match mfd sub devices to regmap interface

On 11/01/2012 03:24 PM, Pantelis Antoniou wrote: The MFD parent device now uses a regmap, instead of direct memory access. Use the same method in the sub devices to avoid nasty surprises. Please not that this driver can't really deal with the case of the regmap call failing in anyway. So

Re: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital

Arnd Bergmann a...@arndb.de wrote: On Wednesday 18 January 2012, Andi wrote: What do you mean with kernel-wide policy for accelerometer drivers? As far as I know, accelerometer drivers are written between the i2c driver and the input driver. The input driver provides already some

Re: [PATCH] lis3lv02d: Add STMicroelectronics lis33ldlh digital

Arnd Bergmann a...@arndb.de wrote: On Tuesday 17 January 2012, AnilKumar, Chimata wrote: Hi All, Recalling the patch, provide the comments if there are any if not please include this patch to v3.3 kernel. As Mark and Greg said, 3.4 would be appropriate. +static ssize_t

Realistic bandwidth to get through ehci controller on a dm3730?

Hi All, Just wondering if anyone had any figures for how much data one can expect the omap3's usb controller to handle? I'm trying to get a playstation eye (ov534) camera to run as at 60fps, but gspca is giving me payload errors at 50fps or 60fps. (50*640*480 bytes per sec, or about 122Mbits /

Build issue.

No time to look into this now, but linux next today is giving: CHK include/linux/version.h CHK include/generated/utsrelease.h make[1]: `include/generated/mach-types.h' is up to date. CALLscripts/checksyscalls.sh CHK include/generated/compile.h CC

Re: [PATCH] omap3: beagle: Use GPTIMERi 1 for clockevents

On 06/25/11 21:10, Koen Kooi wrote: Op 25 jun 2011, om 20:51 heeft Premi, Sanjeev het volgende geschreven: -Original Message- From: linux-omap-ow...@vger.kernel.org [mailto:linux-omap-ow...@vger.kernel.org] On Behalf Of Koen Kooi Sent: Saturday, June 25, 2011 1:47 PM To:

Re: PATCH V4 1/2] input: CMA3000 Accelerometer Driver

On 11/30/10 12:50, Hemanth V wrote: - Original Message - From: Dmitry Torokhov dmitry.torok...@gmail.com Yep, almost there. Hemanth, does the driver still work if you apply the patch below? Yes works pretty well, Thanks for your efforts Some minor changes as below required.

Re: PATCH V4 1/2] input: CMA3000 Accelerometer Driver

to merge to me. Signed-off-by: Hemanth V heman...@ti.com Reviewed-by: Jonathan Cameron ji...@cam.ac.uk Reviewed-by: Sergio Aguirre saagui...@ti.com Reviewed-by: Shubhrajyoti shubhrajy...@ti.com Acked-by: Jonathan Cameron ji...@cam.ac.uk (no idea if the convention is to remove the Reviewed-by when

Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

On 09/24/10 14:02, Pavel Machek wrote: Hi! So a voltmeter really makes no sense. It's not a set of keys and it doesn't give X/Y/Z style readings. Nor does a camera. But a lot of things do fit this to varying degrees. I'm actually more dubious than Linus about ALS - because ALS tends not

Re: [PATCH V3 1/2] input: CMA3000 Accelerometer driver

On 09/21/10 06:46, Hemanth V wrote: - Original Message - From: Jonathan Cameron ker...@jic23.retrosnub.co.uk To: Dmitry Torokhov dmitry.torok...@gmail.com Cc: Hemanth V heman...@ti.com; linux-in...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-omap@vger.kernel.org Sent

Re: [PATCH V3 1/2] input: CMA3000 Accelerometer driver

On 09/14/10 09:00, Dmitry Torokhov wrote: On Wed, Sep 08, 2010 at 12:37:40PM +0100, Jonathan Cameron wrote: I'm happy to see your driver go in as it is currently, what bothers me is that we will end up with incompatible interfaces for all the accelerometers Dmitry takes! This is a valid

Re: [PATCH V3 1/2] input: CMA3000 Accelerometer driver

Hi Hemanth, I know this is rather late in the process, but I thought I'd just like to make a few suggestions in for possibly clearer interfaces (sysfs) - platform data is fine as is because a board designer can look up the data sheet or documentation. I'm not particularly bothered if you do

Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

On 08/31/10 10:44, Alan Cox wrote: 1. Input transport via evdev is very convenient 2. There is no other standard alternative Once there is standard interface for such sensors they will happily use it and will not look back. I think the fact that most of the interest in IIO is how do we

Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

On 08/31/10 10:46, Alan Cox wrote: IIO which is currently in staging. Except we had ALS before that as a layer and Linus vetoed it. So there is zero faith in IIO ever going anywhere. I have more faith - those developing it have limited time, but we will get there. (another plug for anyone

Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

to uinput userspace bridge example for specific device. * * Copyright (c) 2010 Jonathan Cameron * Sometime in the past Luke Casson (or at least it is on his website) * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License

Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

On 08/31/10 18:24, Mohamed Ikbel Boulabiar wrote: IMHO I think sensors no more can be considered as non-input-devices. Things changed too much in recent years. Input sources have now a very different use as before (smartphones, Tablets and handheld devices...) They all have much inputs that

Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

) 2010 Jonathan Cameron * Sometime in the past Luke Casson (or at least it is on his website) * * 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

Re: Sensors and the input layer (was Re: [RFC] [PATCH V2 1/2] input: CMA3000 Accelerometer driver)

On 08/30/10 18:10, Felipe Balbi wrote: Hi, On Mon, 30 Aug 2010 09:28:56 -0700, Dmitry Torokhov dmitry.torok...@gmail.com wrote: When we tried to push N900's accelerometer driver as an input device you commented you didn't want sensors such as accelerometers, magnetometers, proximity, etc

[PATCH] omap2 usb-ehci: Add missing dma-mapping.h

Signed-off-by: Jonathan Cameron ji...@cam.ac.uk --- I'm not a user of this code but was browsing the kautobuild logs and saw the igep0020 build error that has been there since 24th of May using the defconfig. Looks like a trivial missing header to me. I can not verify the resulting build

Re: [PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver

On 06/01/10 21:12, Andrew Morton wrote: I re-added your reviewers to the cc... On Mon, 24 May 2010 16:34:25 +0530 (IST) Hemanth V heman...@ti.com wrote: This patch adds support for ROHM BH1780GLI Ambient light sensor. BH1780 supports I2C interface. Driver supports read/update of power

Re: [PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver

On 06/01/10 21:27, Daniel Mack wrote: On Tue, Jun 01, 2010 at 01:12:44PM -0700, Andrew Morton wrote: On Mon, 24 May 2010 16:34:25 +0530 (IST) Hemanth V heman...@ti.com wrote: This patch adds support for ROHM BH1780GLI Ambient light sensor. BH1780 supports I2C interface. Driver supports

Re: [PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver

On 06/01/10 21:54, Andrew Morton wrote: On Tue, 01 Jun 2010 21:39:10 +0100 Jonathan Cameron ker...@jic23.retrosnub.co.uk wrote: It would be most useful if the changelog were to fully describe the proposed kernel-userspace interface. That's the most important part of the driver, because

Re: [PATCH V2] misc : ROHM BH1780GLI Ambient light sensor Driver

-by: Jonathan Cameron ji...@cam.ac.uk --- drivers/misc/Kconfig | 10 ++ drivers/misc/Makefile|1 + drivers/misc/bh1780gli.c | 273 ++ 3 files changed, 284 insertions(+), 0 deletions(-) create mode 100644 drivers/misc/bh1780gli.c diff

Re: [RFC] [PATCH] misc : ROHM BH1780GLI Ambient light sensor Driver

drivers at somepoint given Linus isn't happy with them having their own subsystem. Acked-by: Jonathan Cameron ji...@cam.ac.uk Signed-off-by: Hemanth V heman...@ti.com --- drivers/misc/Kconfig | 11 ++ drivers/misc/Makefile|1 + drivers/misc/bh1780gli.c | 278

Re: [RFC] [PATCH] TMP105 : Driver support for the temperature sensor

cc'ing lm-sensors (where this should have gone, this has nothing to do with input). On 05/21/10 13:17, Datta, Shubhrajyoti wrote: Adds the driver support for the TMP105 temperature sensor device. The interface is I2C.The driver supports the read of the temperature values. Signed-off-by:

Re: [RFC] [PATCH 1/2] CMA3000 Accelerometer Driver

On 05/13/10 08:53, Hemanth V wrote: - Original Message - From: Jonathan Cameron ji...@cam.ac.uk Hi Hemanth, Quick comments below. I haven't commented much on the input aspects, just stuck to the more general driver aspects. Thanks for the comments, responses inline. I am hoping

Re: [RFC][PATCHv3 1/2] SFH7741: proximity sensor driver support

Hi, I was wondering if you could provide a bit more detail on what this driver is actually doing? My appologies if I have missed a previous explanation. If so, please add a Documentation file to explain what is going on. The driver you have here does virtually nothing itself. It takes both

Re: [RFC] [PATCH 1/2] CMA3000 Accelerometer Driver

Hi Hemanth, Quick comments below. I haven't commented much on the input aspects, just stuck to the more general driver aspects. As ever at the moment, the should this be in input question is open, but if Dmitry is happy to take it then that's fine with me. Jonathan From

Re: [PATCH 3/8] Freescale MMA7455 accelerometer driver

Hi Gregoire, Couple of minor style type comments you are welcome to ignore Bigger ones are that I don't understand your signed 10 bit conversion functions and the bits of the probe function that don't seem to have been written (error handling etc). Jonathan Gregoire Gentil wrote:

Re: [lm-sensors] [RFC PATCH 1/3] hwmon:driver support for Kionix kxte9 accelerometer

Hi Chris, Obviously a few things will change with your move over to input, but as I have a few mins and might not then, here are a few comments. The ones I'd really like to see acted upon are *removing the global pointer that restricts you to one device (all hell will break loose if you add a

Re: [lm-sensors] [RFC PATCH 1/3] hwmon:driver support for Kionix kxte9 accelerometer

Chris Hudson wrote: Jean Delvare wrote: On Tue, 10 Nov 2009 15:32:50 -0500, Chris Hudson wrote: Thank you for your insight Jonathan. The driver was originally written for the 2.6.29 omap-android kernel to facilitate integration of the kxte9 into customer projects. Unfortunately, it seems

Re: [PATCH 1/2] staging: iio: tsl2563 ambient light sensor driver

on the IIO subsystem. Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com Cc: Jonathan Cameron ji...@cam.ac.uk Cc: Greg Kroah-Hartman gre...@suse.de Cc: linux-omap@vger.kernel.org --- drivers/staging/iio/light/Kconfig | 11 + drivers/staging/iio/light/Makefile |1 + drivers

Re: [PATCH 1/2] staging: iio: tsl2563 ambient light sensor driver

light conditions. The only real reason for submitting this to staging is that it is dependent on the IIO subsystem. Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com Cc: Jonathan Cameron ji...@cam.ac.uk Cc: Greg Kroah-Hartman gre...@suse.de Cc: linux-omap@vger.kernel.org

Re: [PATCH 1/2] staging: iio: tsl2563 ambient light sensor driver

Amit Kucheria wrote: On 09 Nov 09, Jonathan Cameron wrote: Hi Amit, Normally I'd welcome this in IIO, except that all ambient light sensors are in the process of moving to the new ALS subsystem. There are still some issues to resolve in that subsystem (mainly to do with naming

Re: [PATCH 1/2] staging: iio: tsl2563 ambient light sensor driver

. The only real reason for submitting this to staging is that it is dependent on the IIO subsystem. :) Need to work on that. Seems like staging is doing one of it's jobs and getting more eyes on the code which is great. Signed-off-by: Amit Kucheria amit.kuche...@verdurent.com Cc: Jonathan