[Letux-kernel] accelerometer bridge madness

[H. Nikolaus Schaller]

> Am 27.07.2018 um 19:08 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
> 
> 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...

I tried to cross-check if that is the real source code. It is.

I have found it here:

	https://packages.debian.org/wheezy/udev

=> download the source from

	http://http.debian.net/debian/pool/main/u/udev/udev_175.orig.tar.bz2

=> and navigate to udev-175/extras/accelerometer)

Interestingly, /lib/udev/accelerometer only exists in Wheezy! Not in Jessie or Stretch. Or did I miss something?

That may explain why I don't see issues since my test roots is usually Jessie.
But I also didn't notice it when running QtMoko on Wheezy with earlier kernels.

> 
> 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
> 
> _______________________________________________
> http://projects.goldelico.com/p/gta04-kernel/
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
> http://lists.goldelico.com/mailman/listinfo.cgi/letux-kernel

-------------- 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/05bc1e1c/attachment.asc>