From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Cameron Subject: Re: [PATCH v1 1/2] iio:iio-interrupt-trigger: device-tree support Date: Sat, 12 Mar 2016 12:08:48 +0000 Message-ID: <56E406D0.5090902@kernel.org> References: <56CA162C.5010406@kernel.org> <20160222190521.GA30054@rob-hp-laptop> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: In-Reply-To: <20160222190521.GA30054@rob-hp-laptop> Sender: linux-iio-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Rob Herring Cc: Gregor Boirie , linux-iio-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Hartmut Knaack , Lars-Peter Clausen , Peter Meerwald , "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org" , Pawel Moll , Mark Rutland , Ian Campbell , Kumar Gala List-Id: devicetree@vger.kernel.org On 22/02/16 19:05, Rob Herring wrote: > On Sun, Feb 21, 2016 at 07:55:24PM +0000, Jonathan Cameron wrote: >> On 19/02/16 19:18, Gregor Boirie wrote: >>> From: Gr=E9gor Boirie >>> >>> Signed-off-by: Gregor Boirie >> Snag here is that iio_interrupt_trigger is a very linux specific >> name and device tree bindings should be just about the hardware. >> >> Not entirely sure how we avoid this though as the use is rather >> hard to describe generically. >> >> cc'd device tree list and bindings maintainers. >> >> As a brief summary - this IIO trigger driver takes a generic >> interrupt (from whatever) and uses it to drive sampling of IIO devic= es. >> The interrupt might be associated with particularly simple sensors d= irectly >> but is more commonly a gpio interrupt line used cause samples to be = captured >> from unrelated devices. Sometimes the source of that interrupt can = be a convoluted >> external mux setup over which linux has no control for example. >=20 > If linux has no control of the setup, then do we care? It's just some= =20 > blackbox driving a signal. >=20 >> Any suggestions on appropriate naming? >=20 > I would think of it outside of IIO perhaps. We already have gpio-keys= =20 > which is kind of similar. Maybe just "external interrupt"? Is it alwa= ys=20 > a GPIO interrupt or could be polled GPIO or some other mechanism? The challenge is that we need to be able to capture it's use. >=20 > Could you add "trigger-gpios" to every device that uses it and allow = for=20 > it to appear multiple times? It somewhat depends on how static settin= g=20 > the trigger source is whether that would be appropriate. Right now we don't have a device - the interrupt trigger is only soft associated (via sysfs) with it's users at a later date. I think we just have 'make up a device' for this to represent the use c= ase so we can probe the interrupt trigger driver in iio. sensor sampling trigger perhaps? >=20 >> We aren't really describing hardware here, rather a policy decision = on what >> a given interrupt is to be used for. >> >> I suppose ultimately we could take the view this should be handled v= ia another >> route (from userspace via an appropriate configfs interface for exam= ple). >=20 > You would still need to know which GPIOs you could use or assign, so = I=20 > think we need something in DT. Absolutely. Short of allowing completely generic grabbing from a config= fs call of an interrupt, definitely need to specify which interrupts are suitab= le for use like this.=20 I think a 'fictional' device is going to have to exist to allow this.. Jonathan