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 -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
