Hi,
(your email setup is still messed up, I had to rewrap the whole email)
On Thu, Aug 07, 2014 at 05:58:57PM +0100, Jonathan Cameron wrote:
> >>> I can set low limit to 200 lux and high limit to 50 lux, then I'll
> >>> get a rising edge IRQ when I have more than 50 lux and a falling
> >>> edge when I get less than 200 lux.
> >>>
> >>> If Latch bit is set, however, then it's almost like it ignores
> >>> low/high limit altogether and I get an IRQ ever $int_time ms or
> >>> so.
> >> That would be similar to the motion triggers we have for
> >> accelerometers. They capture every sample as long as the threshold
> >> is met (during motion). No idea why you'd really want to do that on
> >> a light sensor though. Perhaps not worth capturing light info if
> >> the cover is closed on a phone?
> >
> > Yeah, but that's something else altogether. This device doesn't
> > really care about a phone cover. Sounds like policy which should be
> > in userland, or part of an iio_gpio_trigger...
> Agreed. Can you think of a use for the non latched version? :)
Sure, you might just want a notification when illuminance reaches a
certain level (rising) or drop below another (or the same) level
(falling).
> >>>>> + ret = devm_iio_device_register(dev, iio);
> >>>>> + if (ret) {
> >>>>> + dev_err(dev, "failed to register IIO device\n");
> >>>>> + return ret;
> >>>>> + }
> >>>>> +
> >>>> Normally we'd expect the devm_iio_device_register (that provides
> >>>> the userspace interfaces) to be after the irq request.
> >>>
> >>> that's wrong. By the time the IRQ is requested, an IRQ can
> >>> actually fire and you better have a valid e.g. iio_dev by then.
> >> Its very unusual to bring up a device with the IRQ already in a
> >> position to fire. Normally that would require some enabling from
> >> userspace after the driver is loaded? How can it fire here before
> >> that point?
> >
> > at the moment you call request_irq() (or any of its friends), that
> > IRQ line is unmasked and ready to fire. Remember that IRQ lines can
> > be shared and your IRQ handler will be called even if a separate
> > device triggered the IRQ. Heck, if you have a bad board design, even
> > noise can assert the IRQ line but let's not go there :-)
> IIRC Sharing is only possible if the device driver explicitly allows
> it?
not, necessarily. It can be set by the arch support code.
> Bad board design can get you in many many ways ;)
> >
> > In any case, you better have valid pointers around so that by the
> > time your IRQ is triggered, you don't crash the kernel. Another way
> > would be to mask the IRQ at your device level, but that still
> > doesn't solve shared IRQs.
> >
> > I usually request the IRQ as the last step for that very reason.
> Fair enough - easy way to be sure I guess. Though by just before the
> register of the device all relevant pointers should be available. It
> won't do anything particularly helpful but it should not crash. If it
> does then we have a bug we should probably close.
alright.
--
balbi
Attachment:
signature.asc
Description: Digital signature
