Re: Issues with Lenovo Yoga 900 IIO devices (accelerometer, etc.)

[Nish Aravamudan]

On Thu, Dec 17, 2015 at 12:41 AM, Crt Mori <cmo@xxxxxxxxxxx> wrote:
> On 17 December 2015 at 06:27, Nish Aravamudan <nish.aravamudan@xxxxxxxxx> wrote:
>> On Wed, Dec 16, 2015 at 3:05 PM, Nish Aravamudan
>> <nish.aravamudan@xxxxxxxxx> wrote:
>>> On Wed, Dec 16, 2015 at 2:55 PM, Crt Mori <cmo@xxxxxxxxxxx> wrote:
>>>>
>>>> On Dec 16, 2015 11:37 PM, "Nish Aravamudan" <nish.aravamudan@xxxxxxxxx>
>>>> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> On Wed, Dec 16, 2015 at 2:22 PM, Crt Mori <cmo@xxxxxxxxxxx> wrote:
>>>>> > On 16 December 2015 at 22:41, Nish Aravamudan
>>>>> > <nish.aravamudan@xxxxxxxxx> wrote:
>>>>> >> Hi Daniel,
>>>>> >>
>>>>> >> On Wed, Dec 16, 2015 at 1:43 AM, Daniel Baluta
>>>>> >> <daniel.baluta@xxxxxxxxx> wrote:
>>>>> >>> On Tue, Dec 15, 2015 at 9:19 PM, Nish Aravamudan
>>>>> >>> <nish.aravamudan@xxxxxxxxx> wrote:
>>>>> >>>> So, I apologize in advance for this relatively vague report, but I'm
>>>>> >>>> fairly sure
>>>>> >>>> the Yoga 900 has an accelerometer amongst other sensors (ambient
>>>>> >>>> light?)
>>>>> >>>> exported over IIO.
>>>>> >>>>
>>>>> >>>> But, these sensors seem to not be updating at all with a 4.4-rc5+
>>>>> >>>> kernel (a
>>>>> >>>> set of patches from https://lkml.org/lkml/2015/11/30/441 applied to
>>>>> >>>> Linus'
>>>>> >>>> tree).
>>>>> >>>>
>>>>> >>>> The odd part is at some point in messing with this, I'm fairly sure
>>>>> >>>> it did work!
>>>>> >>>> That is,
>>>>> >>>>
>>>>> >>>> `watch -n 0.1 cat '/sys/bus/iio/devices/iio:device'*/*raw*`
>>>>> >>>
>>>>> >>> Can you send us a sample of the output? Also, would be
>>>>> >>> good to identify the exact driver for accel.
>>>>> >>
>>>>> >> cat /sys/bus/iio/devices/iio:device*/*raw*
>>>>> >> 65478
>>>>> >> 7
>>>>> >> 1023
>>>>> >> 0
>>>>> >> 0
>>>>> >> 0
>>>>> >> 100
>>>>> >> -539062
>>>>> >> -742187
>>>>> >> 1292968
>>>>> >> 1592
>>>>> >> 64932
>>>>> >> 2
>>>>> >> 275
>>>>> >> 0 0 0 0
>>>>> >>
>>>>> >> Now, I should say that I distinctly remember at some point waving my
>>>>> >> laptop around and seeing these values change ... but now they seem to
>>>>> >> be "stuck". Maybe it's a hardware issue or something special that
>>>>> >> WIndows does to leverage the IIO sensors?
>>>>> >>
>>>>> >>> Perhaps: cat /sys/bus/iio/devices/iio:device'*/name
>>>>> >>
>>>>> >> $ cat /sys/bus/iio/devices/iio:device*/name
>>>>> >> accel_3d
>>>>> >
>>>>> > Can you list the directory of iio:device with this name (it is:
>>>>> > drivers/iio/accel/hid-sensor-accel-3d.c).
>>>>> > This is something you will be looking at for accel debugging, but it
>>>>> > seems more like
>>>>> > standard
>>>>>
>>>>> /sys/bus/iio/devices/iio:device0/name
>>>>> gyro_3d
>>>>> /sys/bus/iio/devices/iio:device1/name
>>>>> dev_rotation
>>>>> /sys/bus/iio/devices/iio:device2/name
>>>>> als
>>>>> /sys/bus/iio/devices/iio:device3/name
>>>>> magn_3d
>>>>> /sys/bus/iio/devices/iio:device4/name
>>>>> accel_3d
>>>>> /sys/bus/iio/devices/iio:device5/name
>>>>> incli_3d
>>>>>
>>>>> are all the IIO sensors, sorry about that!
>>>>>
>>>>
>>>> I was more thinking what else is in iio:device4 directory, so that we can
>>>> see if it was initialized OK. Can you also grep the dmesg for any errors?
>>>
>>> Well, I just noticed the device #s are not consistent boot-to-boot, so
>>> this time it was device0. Trimming out the directories:
>>>
>
> This is correct/intended. You need to confirm "deviceX/name" each time.

Got it!

>>> /sys/bus/iio/devices/iio:device0/buffer
>>> cat: /sys/bus/iio/devices/iio:device0/buffer: Is a directory
>>> /sys/bus/iio/devices/iio:device0/dev
>>> 250:0
>>> /sys/bus/iio/devices/iio:device0/in_accel_hysteresis
>>> cat: /sys/bus/iio/devices/iio:device0/in_accel_hysteresis: Invalid argument
>>> /sys/bus/iio/devices/iio:device0/in_accel_offset
>>> 0
>>> /sys/bus/iio/devices/iio:device0/in_accel_sampling_frequency
>>> 8.000000
>>> /sys/bus/iio/devices/iio:device0/in_accel_scale
>>> 0.009806
>>> /sys/bus/iio/devices/iio:device0/in_accel_x_raw
>>> 65478
>>> /sys/bus/iio/devices/iio:device0/in_accel_y_raw
>>> 7
>>> /sys/bus/iio/devices/iio:device0/in_accel_z_raw
>>> 1023
>
> This seems like a valid number 1023 * 0.009806 = 10,031 m/s2 but X does not.

Ok...

>>> /sys/bus/iio/devices/iio:device0/name
>>> accel_3d
>>> /sys/bus/iio/devices/iio:device0/uevent
>>> MAJOR=250
>>> MINOR=0
>>> DEVNAME=iio:device0
>>> DEVTYPE=iio_device
>>>
>>> Another thing I just noticed:
>>>
>>> /sys/bus/iio/devices/iio:device0/buffer/enable
>>> 0
>
> This is buffer enable not chip enable. You can write 1 to that so it
> will be enables
> (echo "1" > /sys/bus/iio/devices/.../buffer/enable) and see what
> happens. It might be
> that it needs buffer to update properly (I haven't checked the code).

Doesn't immediately seem to make a difference.

>>>
>>> The only error I'm getting consistently is:
>>>
>>> [    1.115327] i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report
>>> size:19 / ret_size:18
>>>
>>> which I don't think is relevant, but I might be wrong.
>
> If accel is i2c this might be a relevant error - and probe would also
> not fail, but error would
> repeat itself each time probably Maybe track where that line is in
> i2c_hid and see what it
> could mean.

i2c_hid i2c-ITE8396:00: report (len=19): 12 00 5a ff ff ff ff ff ff ff
ff ff ff ff ff ff ff ff 06
i2c_hid i2c-ITE8396:00: error in i2c_hid_init_report size:19 / ret_size:18

So it seems like the device indicates an expected return size of 18,
but actually gives 19 bytes.

I don't know anything about i2c, but i'll dig around.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/