From: Jon Brenner <Jon.Brenner@ams.com>
To: Brian Masney <masneyb@onstation.org>,
"jic23@kernel.org" <jic23@kernel.org>,
"linux-iio@vger.kernel.org" <linux-iio@vger.kernel.org>
Cc: "devel@driverdev.osuosl.org" <devel@driverdev.osuosl.org>,
"lars@metafoo.de" <lars@metafoo.de>,
"gregkh@linuxfoundation.org" <gregkh@linuxfoundation.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"pmeerw@pmeerw.net" <pmeerw@pmeerw.net>,
"knaack.h@gmx.de" <knaack.h@gmx.de>
Subject: RE: [PATCH 0/6] staging: iio: tsl2x7x: staging cleanups
Date: Fri, 30 Jun 2017 16:08:09 +0000 [thread overview]
Message-ID: <5735c3fe53e34c23a8f6fdd80d5e87b5@SUX5072.office.amsiag.com> (raw)
In-Reply-To: <20170630152114.4biwkzt43w52lalp@basecamp>
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 <Jon.Brenner@ams.com>; 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
next prev parent reply other threads:[~2017-06-30 16:18 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 17:03 [PATCH 0/6] staging: iio: tsl2x7x: staging cleanups Brian Masney
2017-06-29 17:03 ` [PATCH 1/6] staging: iio: tsl2x7x: add of_match table for device tree support Brian Masney
2017-07-06 18:55 ` Rob Herring
2017-06-29 17:03 ` [PATCH 2/6] staging: iio: tsl2x7x: remove redundant power_state sysfs attribute Brian Masney
2017-06-29 17:03 ` [PATCH 3/6] staging: iio: tsl2x7x: remove tsl2x7x_i2c_read() Brian Masney
2017-06-29 19:26 ` Frans Klaver
2017-06-29 17:03 ` [PATCH 4/6] staging: iio: tsl2x7x: cleaned up i2c calls in tsl2x7x_als_calibrate() Brian Masney
2017-06-29 17:03 ` [PATCH 5/6] staging: iio: tsl2x7x: refactor {read,write}_event_value to allow handling multiple iio_event_infos Brian Masney
2017-07-01 9:40 ` Jonathan Cameron
2017-07-01 10:37 ` Brian Masney
2017-07-01 11:58 ` Jonathan Cameron
2017-06-29 17:03 ` [PATCH 6/6] staging: iio: tsl2x7x: use usleep_range() instead of mdelay() Brian Masney
2017-06-30 15:21 ` [PATCH 0/6] staging: iio: tsl2x7x: staging cleanups Brian Masney
2017-06-30 16:08 ` Jon Brenner [this message]
2017-07-01 9:42 ` Jonathan Cameron
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5735c3fe53e34c23a8f6fdd80d5e87b5@SUX5072.office.amsiag.com \
--to=jon.brenner@ams.com \
--cc=devel@driverdev.osuosl.org \
--cc=gregkh@linuxfoundation.org \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=linux-iio@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masneyb@onstation.org \
--cc=pmeerw@pmeerw.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).