Hi, well currently I am working on other projects. To get the invensens driver up and running was a matter of either filling the data necessary for the driver in the platform data (old school) or make the driver aware of device tree information. I have quickly had a look at the current implementation of the driver in the current 3.17-rc7 kernel and it still does not support the device tree information, so you will have to do that bit for yourself. Take my patch as a first startup and that should get you working :)
have fun, Thomas Am Mittwoch, 1. Oktober 2014 15:22:37 UTC+2 schrieb [email protected]: > > Hi, > did you pursue your work on the mpu6050 ? > I have a hard time figuring how to use the invensense driver. Is it worth > it ? > > thanks > > Le mardi 13 mai 2014 22:46:55 UTC+2, [email protected] a écrit : >> >> Hi, >> I have got a small project at home running the inv_mpu6050 driver on a >> 3.8.13 kernel. To get it working I had to modify the driver, so that it >> accepts device tree parameters, then I wrote a cape configuration for the >> i2c and the mpu6050 device and voila it worked. I added the driver to the >> kernel and then add the cape to the device tree by echoing the cape name to >> /sys/devices/bone_capemgr.8/slots. So then I had: >> >> cat /sys/devices/bone_capemgr.8/slots >> 0: 54:PF--- >> 1: 55:PF--- >> 2: 56:PF--- >> 3: 57:PF--- >> 4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-MPU6050 >> >> lsmod >> Module Size Used by >> inv_mpu6050 7868 0 >> g_multi 47670 0 >> libcomposite 14299 1 g_multi >> mt7601Usta 601404 0 >> >> ls /sys/bus/iio/devices/iio:device0/ >> buffer in_accel_scale in_accel_z_raw in_anglvel_y_raw >> in_temp_offset name sampling_frequency_available trigger >> dev in_accel_x_raw in_anglvel_scale in_anglvel_z_raw >> in_temp_raw power scan_elements uevent >> in_accel_matrix in_accel_y_raw in_anglvel_x_raw in_gyro_matrix >> in_temp_scale sampling_frequency subsystem >> >> cat /sys/bus/iio/devices/iio:device0/*raw >> -8202 >> -458 >> 11288 >> 10 >> 51 >> 109 >> -4967 >> >> But now to the downside of it all. If I try to access the values, e.g. >> /sys/bus/iio/devices/iio:device0/in_accel_x_raw it takes more than 100ms? >> Well I am still working on some improvements in the driver's device tree >> (the parameters can be negative, but the dtc version I have got can not >> handle unary parameters yet), but when I am finished I will commit the >> driver back to the community. >> >> My work so far: >> -) The Cape File: >> /* >> * Copyright (C) 2014 Thomas Grazadei >> * >> * Make use of the Invensense MPU6050 >> * >> * This program is free software; you can redistribute it and/or modify >> * it under the terms of the GNU General Public License version 2 as >> * published by the Free Software Foundation. >> */ >> /dts-v1/; >> /plugin/; >> >> / { >> compatible = "ti,beaglebone", "ti,beaglebone-black"; >> >> /* identification */ >> part-number = "BB-MPU6050"; >> version = "00A0"; >> >> /* state the resources this cape uses */ >> exclusive-use = >> /* the pin header uses */ >> "P9.18", /* i2c1_sda */ >> "P9.17", /* i2c1_scl */ >> /* the hardware ip uses */ >> "i2c1"; >> >> fragment@0 { >> target = <&am33xx_pinmux>; >> __overlay__ { >> bb_i2c1_pins: pinmux_bb_i2c1_pins { >> pinctrl-single,pins = < >> 0x158 0x72 /* >> spi0_d1.i2c1_sda, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */ >> 0x15c 0x72 /* >> spi0_cs0.i2c1_scl, SLEWCTRL_SLOW | INPUT_PULLUP | MODE2 */ >> >; >> }; >> }; >> }; >> >> fragment@1 { >> target = <&i2c1>; /* i2c1 is numbered correctly */ >> __overlay__ { >> status = "okay"; >> pinctrl-names = "default"; >> pinctrl-0 = <&bb_i2c1_pins>; >> >> /* this is the configuration part */ >> clock-frequency = <400000>; >> >> #address-cells = <1>; >> #size-cells = <0>; >> >> /* add any i2c devices on the bus here */ >> >> mpu6050@68 { >> compatible = "inv,mpu6050"; >> reg = <0x68>; >> orientation = <0xff 0 0 0 1 0 0 0 0xff>; >> }; >> }; >> }; >> }; >> >> -) and the changes in the driver: >> diff --git a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c >> b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c >> index 37ca05b..d101a0c 100644 >> --- a/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c >> +++ b/drivers/iio/imu/inv_mpu6050/inv_mpu_core.c >> @@ -648,6 +648,31 @@ static int inv_check_and_setup_chip(struct >> inv_mpu6050_state *st, >> return 0; >> } >> >> +static struct inv_mpu6050_platform_data* >> + mpu6050_parse_dt(struct device* dev) >> +{ >> + struct device_node *np = dev->of_node; >> + struct inv_mpu6050_platform_data *pdata; >> + >> + if (!np) { >> + dev_err(dev, "no device tree or platform data\n"); >> + return ERR_PTR(-EINVAL); >> + } >> + >> + pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL); >> + if (!pdata) >> + return ERR_PTR(-ENOMEM); >> + >> + >> + if (of_property_read_u8_array(np, "orientation", >> + pdata->orientation, sizeof(pdata->orientation)) != 0) { >> + dev_err(dev, "no valid orientation property found\n"); >> + return ERR_PTR(-EINVAL); >> + } >> + >> + return pdata; >> +} >> + >> /** >> * inv_mpu_probe() - probe function. >> * @client: i2c client. >> @@ -660,6 +685,7 @@ static int inv_mpu_probe(struct i2c_client *client, >> { >> struct inv_mpu6050_state *st; >> struct iio_dev *indio_dev; >> + struct inv_mpu6050_platform_data* pdata; >> int result; >> >> if (!i2c_check_functionality(client->adapter, >> @@ -675,8 +701,21 @@ static int inv_mpu_probe(struct i2c_client *client, >> } >> st = iio_priv(indio_dev); >> st->client = client; >> - st->plat_data = *(struct inv_mpu6050_platform_data >> - *)dev_get_platdata(&client->dev); >> + pdata = (struct inv_mpu6050_platform_data*) >> + dev_get_platdata(&client->dev); >> + >> + if (pdata == NULL) { >> + /* check of devicetree */ >> + // printk(KERN_ERR "checking device tree for parameter infos"); >> + pdata = mpu6050_parse_dt(&client->dev); >> + } >> + >> + if (IS_ERR(pdata)) { >> + return PTR_ERR(pdata); >> + } >> + >> + st->plat_data = *pdata; >> + >> /* power is turned on inside check chip type*/ >> result = inv_check_and_setup_chip(st, id); >> if (result) >> @@ -777,14 +816,22 @@ static const struct i2c_device_id inv_mpu_id[] = { >> >> MODULE_DEVICE_TABLE(i2c, inv_mpu_id); >> >> +static struct of_device_id inv_mpu6050_i2c_of_match[] = { >> + { .compatible = "inv,mpu6050", }, >> + { } >> +}; >> + >> +MODULE_DEVICE_TABLE(of, inv_mpu6050_i2c_of_match); >> + >> static struct i2c_driver inv_mpu_driver = { >> .probe = inv_mpu_probe, >> .remove = inv_mpu_remove, >> .id_table = inv_mpu_id, >> .driver = { >> - .owner = THIS_MODULE, >> - .name = "inv-mpu6050", >> - .pm = INV_MPU6050_PMOPS, >> + .owner = THIS_MODULE, >> + .name = "inv-mpu6050", >> + .pm = INV_MPU6050_PMOPS, >> + .of_match_table = inv_mpu6050_i2c_of_match, >> }, >> }; >> >> cheers, >> gardi >> >> >> Am Mittwoch, 7. Mai 2014 02:16:57 UTC+2 schrieb [email protected]: >>> >>> No we never got this (the Invensense driver) working. We just stuck it >>> out with reading /dev/i2c. This is costing us a 20% time penalty which >>> really really hurts. We couldn't get anyone to take on fixing the >>> unbelievably long read times (~1msec) on /dev/i2c either. >>> Some of us are hoping the up coming move to Debian from Angstrom will >>> bring us an Invensense driver in the distro that will somehow work. >>> On Tuesday, May 6, 2014 10:42:41 AM UTC-7, [email protected] wrote: >>>> >>>> Knowing this discussion is old, i have to ask did you get it working? >>>> And my experience is with the bbw, not the bbb. but the i2c buss on my >>>> device is 100khz. maximum is 400khz. I was able to get the accelerometer >>>> and gyro values at a rate of 200hz without issue, which isn't the max the >>>> chip can provide, but it's more than suitable for most applications. All >>>> through accessing /dev/i2c-#. If you havent got the driver to work yet, I >>>> can send you my tiny little C program that prints the data to the shell. >>>> >>>> On Tuesday, October 15, 2013 5:02:59 PM UTC-5, [email protected] >>>> wrote: >>>>> >>>>> We are using the Invensense MPU6050 IMU on I2C with Beaglebone Black >>>>> (Angstrom 3.8.13). We can use I2C-tools and file I/O thru /dev/i2c but >>>>> the >>>>> read speed is disappointingly slow. We only read the 3x gyros and 3x >>>>> accels (each one byte at a time plus the 2 byte temperature reading) and >>>>> it >>>>> takes ~2msecs. My estimate of the I2C bus cycles for a block read >>>>> suggests this should take ~160 bus cycles or .38msec on a 400kHz I2C bus. >>>>> >>>>> The distribution includes the Invensense driver inv-mpu6050.ko but >>>>> there is no indication that reading through /dev/i2c invokes it. This >>>>> is a very popular IMU and Invensense widely distributes the driver over >>>>> many Linux platforms. The driver source includes “successful >>>>> installation will create two directories under /sys/bus/iio/devices” and >>>>> lists the files there (aka functions). I can never get these to show up. >>>>> >>>>> I can “insmod >>>>> /lib/modules/3.8.13/kernel/drivers/iio/imu/inv_mpu6050/inv-mpu6050.ko” >>>>> and >>>>> “echo inv-mpu6050 0x68 > /sys/class/i2c-adapter/i2c-1/new_device”. This >>>>> causes a new directory named 1-0068 to show in >>>>> /sys/class/i2c-adapter/i2c-1with entries like name and modalias but no >>>>> functions. It never shows in /sys/bus/iio/devices. >>>>> >>>>> What constitutes “successful installation”? >>>>> >>>>> What else is needed to get the inv-mpu6050 to expose functions in >>>>> /sys/bus/iio/devices like the driver sources says? >>>>> >>>>> Beaglebone Black uses bone_capemgr for exposing driver functions for >>>>> many devices. “echo inv-mpu6050 0x68 > >>>>> /sys/devices/bone_capmgr.9/slots” raises the gripe “write error: no such >>>>> file or directory”. (I can successfully load the am33xx_pwm driver >>>>> this way.) Is this because there is no matching DT fragment in >>>>> /lib/firmware? Is the inv-mpu6050 driver supposed to be invoked thru cape >>>>> manager? >>>>> Then, most importantly, if I did read and write through the /sys tree >>>>> using the Invensense driver would it be faster than /dev/i2c? >>>>> Help on sorting this out would be much appreciated. >>>>> >>>> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
