From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Herring Subject: Re: [PATCH v1 1/2] iio:iio-interrupt-trigger: device-tree support Date: Mon, 22 Feb 2016 13:05:21 -0600 Message-ID: <20160222190521.GA30054@rob-hp-laptop> References: <56CA162C.5010406@kernel.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Content-Disposition: inline In-Reply-To: <56CA162C.5010406-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> Sender: linux-iio-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Jonathan Cameron 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 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 > >=20 > > 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. >=20 > Not entirely sure how we avoid this though as the use is rather > hard to describe generically. >=20 > cc'd device tree list and bindings maintainers. >=20 > As a brief summary - this IIO trigger driver takes a generic > interrupt (from whatever) and uses it to drive sampling of IIO device= s. > The interrupt might be associated with particularly simple sensors di= rectly > but is more commonly a gpio interrupt line used cause samples to be c= aptured > from unrelated devices. Sometimes the source of that interrupt can b= e a convoluted > external mux setup over which linux has no control for example. If linux has no control of the setup, then do we care? It's just some=20 blackbox driving a signal. > Any suggestions on appropriate naming? 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 always= =20 a GPIO interrupt or could be polled GPIO or some other mechanism? Could you add "trigger-gpios" to every device that uses it and allow fo= r=20 it to appear multiple times? It somewhat depends on how static setting=20 the trigger source is whether that would be appropriate. > We aren't really describing hardware here, rather a policy decision o= n what > a given interrupt is to be used for. >=20 > I suppose ultimately we could take the view this should be handled vi= a another > route (from userspace via an appropriate configfs interface for examp= le). You would still need to know which GPIOs you could use or assign, so I=20 think we need something in DT. Rob