On Thu, Dec 17, 2015 at 12:05 PM, Nish Aravamudan <nish.aravamudan@xxxxxxxxx> wrote: > On Thu, Dec 17, 2015 at 10:38 AM, Crt Mori <cmo@xxxxxxxxxxx> wrote: >> On 17 December 2015 at 19:10, Nish Aravamudan <nish.aravamudan@xxxxxxxxx> wrote: >>> On Thu, Dec 17, 2015 at 9:32 AM, Nish Aravamudan >>> <nish.aravamudan@xxxxxxxxx> wrote: >>>> 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. >>> >> >> There is chance to read the /sys/bus/i2c/... device (maybe see the >> address there?) directly. >> However I would expect an i2c error each time you try to read a raw >> value in driver if there would >> be some. I hope someone more experienced can chime in... >> >>> Another thought I had, reading through Google results for other Yoga >>> laptops, the sensor device showed up in lsusb. Would I expect to see >>> any such device in lsusb for the Yoga 900? I only get: >>> >>> Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub >>> Bus 001 Device 003: ID 8087:0a2b Intel Corp. >>> Bus 001 Device 002: ID 13d3:5664 IMC Networks >>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub >>> >> >> I somehow doubt that accel is an usb device (which is what lsusb would >> show), but if it >> does then it should not show in iio. >> There is however iioutils package which is around same as lsusb and >> might be worth checking >> out for you. > > Ah! So I have no idea what changed. I cloned the iioutils git tree > from SF and now the sensors are reporting values and dmesg is > reporting: > > [13872.936769] hid-sensor-hub 0018:048D:8396.0001: No report with id > 0xffffffff found Ok, well, I'm pretty confused now. Maybe lsiio probed something correctly to wake up the sensors. But now they work still after reboot! The message above was because I had incorrectly applied the Yoga/Yoga2 quirk to the 900 and it doesn't seem to be necessary. Now to get iio-sensor-proxy to work :) -Nish -- 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
