On Sun, Jan 12, 2020 at 5:54 PM Stephan Gerhold <stephan@xxxxxxxxxxx> wrote: > It seems to work fine on samsung,golden with gp2ap002s00f. > There are interrupts being sent when something moves in front of the > sensor and iio-event-monitor looks good too: > > Tested-by: Stephan Gerhold <stephan@xxxxxxxxxxx> Thanks! I think I'm up at v7 or something on this driver and now it looks good. > Out of curiosity: I'm not so familiar with the IIO subsystem, > is it intended that the sensor is active the whole time? > Wouldn't it be better to activate it only when something is reading > /dev/iio:device2? IMO the best way to power manage an IIO sensor is like I do in drivers/iio/gyro/mpu3050-core.c Of course I think it is excellent code since I wrote it. Beware of hubris in the driver. The idea is to take the runtime pm handle on the device whenever in use (reading values from the hardware or using the trigger), and then use autosuspend to completely shut it down (including regulators) when not in use. If the power-up time for the sensor is long, then the autosuspend timeout should be proportionally longer, like a magnitude or two above. With the proximity events I have this problem that I don't know in the driver if someone had opened the file to read events or not, only the core knows, I think. I just emit my events and be happy. Jonathan: is there a way for the driver to know if someone is listening on the event interface? > There is one problem I noticed, although I'm not sure if it is a problem > in this driver. Reading one of the files in the sysfs results in: > > $ cat /sys/bus/iio/devices/iio\:device2/events/in_proximity_thresh_either_en > Segmentation fault That looks like an ordinary bug, but that seems to be for the core? Hm... Yours, Linus Walleij
