From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752421AbdF3QSn convert rfc822-to-8bit (ORCPT ); Fri, 30 Jun 2017 12:18:43 -0400 Received: from mail1.ams.com ([212.166.112.31]:15123 "EHLO mail1.ams.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752244AbdF3QSl (ORCPT ); Fri, 30 Jun 2017 12:18:41 -0400 X-Greylist: delayed 629 seconds by postgrey-1.27 at vger.kernel.org; Fri, 30 Jun 2017 12:18:40 EDT From: Jon Brenner To: Brian Masney , "jic23@kernel.org" , "linux-iio@vger.kernel.org" CC: "devel@driverdev.osuosl.org" , "lars@metafoo.de" , "gregkh@linuxfoundation.org" , "linux-kernel@vger.kernel.org" , "pmeerw@pmeerw.net" , "knaack.h@gmx.de" Subject: RE: [PATCH 0/6] staging: iio: tsl2x7x: staging cleanups Thread-Topic: [PATCH 0/6] staging: iio: tsl2x7x: staging cleanups Thread-Index: AQHS8Pm1hpyjsoEarEu7GATVej1PnKI9ZYsAgAAleaA= Date: Fri, 30 Jun 2017 16:08:09 +0000 Message-ID: <5735c3fe53e34c23a8f6fdd80d5e87b5@SUX5072.office.amsiag.com> References: <20170629170352.11264-1-masneyb@onstation.org> <20170630152114.4biwkzt43w52lalp@basecamp> In-Reply-To: <20170630152114.4biwkzt43w52lalp@basecamp> Accept-Language: en-US, de-AT Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.8.215] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Brian, Not sure about the DTS interrupt setting you mentioned but would like to know how you resolve - as I am planning on getting a Pi0w for some 'home personal projects'. Anyway (and I am sure you probably already know this - but just in case) WRT the device registers (on the TSL2771 for example); If you enable interrupts (ie. Reg#0x00= 0x37) and set the persistence register to 0x00 (is. Reg# 0x0C = 0x00), you should see interrupts occurring every integration period. That way you can see if you're at least getting them. You probably know this too - on earlier parts such as these, interrupts were cleared via use of the "command register" special function bits. (see data sheets for details). Now a day - interrupts are cleared in a more conventional manner Jon -----Original Message----- From: Brian Masney [mailto:masneyb@onstation.org] Sent: Friday, June 30, 2017 10:21 AM To: jic23@kernel.org; linux-iio@vger.kernel.org Cc: devel@driverdev.osuosl.org; lars@metafoo.de; gregkh@linuxfoundation.org; linux-kernel@vger.kernel.org; Jon Brenner ; pmeerw@pmeerw.net; knaack.h@gmx.de Subject: Re: [PATCH 0/6] staging: iio: tsl2x7x: staging cleanups On Thu, Jun 29, 2017 at 01:03:46PM -0400, Brian Masney wrote: > This begins my work to clean this driver up and eventually move it out > of staging. Driver changes were tested using a TSL2771 hooked up to a > Raspberry Pi 2. > > Thanks to Jon Brenner at AMS/TAOS for loaning me some hardware samples > to test my driver changes. > > Brian Masney (6): > staging: iio: tsl2x7x: add of_match table for device tree support > staging: iio: tsl2x7x: remove redundant power_state sysfs attribute > staging: iio: tsl2x7x: remove tsl2x7x_i2c_read() > staging: iio: tsl2x7x: cleaned up i2c calls in tsl2x7x_als_calibrate() > staging: iio: tsl2x7x: refactor {read,write}_event_value to allow > handling multiple iio_event_infos > staging: iio: tsl2x7x: use usleep_range() instead of mdelay() > > .../devicetree/bindings/trivial-devices.txt | 10 + > drivers/staging/iio/light/tsl2x7x.c | 316 ++++++++++----------- > 2 files changed, 153 insertions(+), 173 deletions(-) Hi Jonathon, Hold off on applying this series. There are several other formatting warnings from checkpatch with this series that I need to fix. Sorry about the noise. I'd appreciate it if you could at least look at the functionality of my changes and I'll resubmit next week. I held back several other changes related to the event subsystem until I'm able to properly test my changes. I'm having trouble getting the interrupts to work. I wired the interrupt pin on the sensor to GPIO pin 17 on my Raspberry Pi 2 and added the following section to arch/arm/boot/dts/bcm2836-rpi-2-b.dts for my sensor: &i2c1 { tsl2771@29 { compatible = "amstaos,tsl2771"; reg = <0x39>; interrupt-parent = <&gpio>; interrupts = <17 2>; }; }; I start up iio_event_monitor, and run these commands: echo 1 > events/in_intensity0_thresh_rising_en echo 256 > events/in_intensity0_thresh_rising_value When I shine a light on the ALS sensor, and the reading goes above 256, I do not get any events back from iio_event_monitor. I'm honestly not sure about the 2 in the 'interrupts = <17 2>;' line. I looked at how interrupts were setup in device tree overlays in the official Raspberry Pi kernel and tried several variations from there. I have more reading to do. :) Thanks, Brian