[Letux-kernel] accelerometer bridge madness
H. Nikolaus Schaller
hns at goldelico.com
Fri Jul 27 19:19:43 CEST 2018
> Am 27.07.2018 um 19:08 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>> 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...
I tried to cross-check if that is the real source code. It is.
I have found it here:
=> download the source from
=> 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?
> for(i=1; i<10; i++) head->scratch();
>> ok, next step probably is to monitor input_work.
> Letux-kernel mailing list
> Letux-kernel at openphoenux.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Letux-kernel