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-iio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
