[Letux-kernel] accelerometer bridge madness
H. Nikolaus Schaller
hns at goldelico.com
Fri Jul 27 19:08:37 CEST 2018
> Am 27.07.2018 um 18:49 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Fri, 27 Jul 2018 16:58:08 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>>> But I will first check how often open() is called.
>> Yes, that is the important thing. And when it is called. You might add some
>> printk to the probe function to identify the sequence.
> only one time! I moved away that /lib/udev/accelerometer thing
> and did xxd /dev/input/eventX after the boot fully finished.
> No accel_open() caused by udev anymore!
> So this is definitively not a race condition regarding the work struct
> (but of course that should be fixed).
> I tested
> diff --git a/drivers/iio/industrialio-inputbridge.c b/drivers/iio/industrialio-inputbridge.c
> index bd5807f31767..77bd9bb352f7 100644
> --- a/drivers/iio/industrialio-inputbridge.c
> +++ b/drivers/iio/industrialio-inputbridge.c
> @@ -89,7 +89,7 @@ static int accel_open(struct input_dev *input)
> struct iio_dev *iiodev = input_get_drvdata(input);
> -#if 0
> +#if 1
> @@ -98,7 +98,7 @@ printk("accel_open()\n");
> #if POLLING
> - msecs_to_jiffies(0)); // start now
> + msecs_to_jiffies(100)); // start now
> int iio_channel_start_all_cb(struct iio_cb_buffer *cb_buff);
> having the 100 there at least causes at least the cpu usage to be sane.
Ah, that could be part of the problem.
I have studied https://github.com/lu-zero/udev/blob/master/src/accelerometer/accelerometer.c
again and it looks as if it can even be called from the command-line...
What it does is to open the event device, read one value and close, then do its
calculations and return a value.
This means if this /lib/udev/accelerometer is called quickly we have a (very)
quick succession of calls to accel_open() and access_close(). Also with many
schedule_delayed_work() and cancels.
Another question: which rule makes /lib/udev/accelerometer run? Is it being
run by every change of accelerometer? Then, there should be some mechanism
that waits for accelerometer changes, notifies udevd which then call
/lib/udev/accelerometer which does an accel_open()+read+close. So access events
could indirectly end in accel_open()...
AFAIK only uevents trigger udevd - but does /dev/input/event have an uevent?
for(i=1; i<10; i++) head->scratch();
> ok, next step probably is to monitor input_work.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Letux-kernel