[Letux-kernel] accelerometer bridge madness

[H. Nikolaus Schaller]

Hi,

> Am 27.07.2018 um 18:49 schrieb Andreas Kemnade <andreas at kemnade.info>:
> 
> Hi,
> 
> 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
> printk("accel_open()\n");
> #endif
> 
> @@ -98,7 +98,7 @@ printk("accel_open()\n");
> 
> #if POLLING
>        schedule_delayed_work(&input_work,
> -               msecs_to_jiffies(0));   // start now
> +               msecs_to_jiffies(100)); // start now
> #else
>        int iio_channel_start_all_cb(struct iio_cb_buffer *cb_buff);
> #endif
> 
> 
> 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?

> 
> head->scratch();

for(i=1; i<10; i++) head->scratch();

> 
> ok, next step probably is to monitor input_work.

BR,
Nikolaus

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180727/64793a58/attachment.asc>