Comment 1 by Marek Belisko, Apr 28, 2014
There seems to be 2 separate drivers which handle bma180 chip. One in drivers/input/misc/bma150.c and second is iio in drivers/iio/accel/bma180.c. In DT there is comment we're using one from input but I cannot see any references in driver about DT conversion (compatible string). Am I missing something?
Comment 2 by Nikolaus Schaller, Apr 28, 2014
Yes, you are right, there are two drivers. One makes the BMA a /dev/input device so that it can report events. And an udev rule maps it to /dev/input/accel. The other one is a pure iio driver which can't be used for input events - and decoding gestures etc. We use the input event driver (and it worked in the non-DT variant). Your observation appears to be right: there appears to be no DT handling in this driver yet. So it is loaded (by i2c matching) but has no platform data which is a good explanation why it hangs and does not work at all. But: in our board file we aren't providing platform data either. Just configure it for the i2c bus. So a NULL pdata should work (?).
Comment 3 by Marek Belisko, Apr 28, 2014
Following patch fix probing by compatible string + fix int number.
Anyway I still cannot get interrupt routine called (can this be
somehow measured by scope?)
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 0a1e7c8..16eff75 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -412,9 +412,9 @@
/* accelerometer */
bma180@41 {
/* we use the BMA150 Input (CONFIG_INPUT_BMA150)
driver */
- compatible = "bosch,bma180";
+ compatible = "bosch,bma150";
reg = <0x41>;
- interrupt-parent = <&gpio3>;
+ interrupt-parent = <&gpio4>;
interrupts = <19 (IRQ_TYPE_LEVEL_HIGH |
IRQ_TYPE_EDGE_RISING)>;
};
diff --git a/drivers/input/misc/bma150.c
b/drivers/input/misc/bma150.c
index b36831c..5c61d3d 100644
--- a/drivers/input/misc/bma150.c
+++ b/drivers/input/misc/bma150.c
@@ -650,6 +650,13 @@ static const struct i2c_device_id bma150_id[] =
{
{ }
};
+#ifdef CONFIG_OF
+static const struct of_device_id of_bma150_match[] = {
+ { .compatible = "bosch,bma150", },
+ {},
+};
+#endif
+
MODULE_DEVICE_TABLE(i2c, bma150_id);
static struct i2c_driver bma150_driver = {
@@ -657,6 +664,7 @@ static struct i2c_driver bma150_driver = {
.owner = THIS_MODULE,
.name = BMA150_DRIVER,
.pm = &bma150_pm,
+ .of_match_table = of_match_ptr(of_bma150_match),
},
.class = I2C_CLASS_HWMON,
.id_table = bma150_id,
Comment 4 by Nikolaus Schaller, Apr 29, 2014
I think we should keep the compatible entry to say "bosch,bma180" because it is a BMA180 and the DT should describe the hardware (and not some design decisions of drivers). Therefore I think the driver should get a second (third, fourth...) .compatible entry. For the interrupt it is GPIO115 for BMA180 (and would be 114 for LIS302 on some GTA04A3 board). So &gpio4 / 19 should be the correct specification. But is it correct to have level + edge trigger? Measuring with Oscilloscope could be possible since GPIO115 is on the (never installed) LSM303 footprint. Can you read static values (evtest /dev/input/accel)?
Comment 5 by Marek Belisko, Apr 29, 2014
In following patch I fix compatible entry as suggested (thanks) and
also ad muxing for gpio_115 (to be sure it's correct) but it still
doesn't help. And I also cannot see /dev/input/accel. I'm checking
by hexdump /dev/input/event1 (found symlink in /dev/input/by-path).
Can you please measure if IRQ pin is doing something? I'm also not
sure about level irq (I think edge should be enough).Thanks.
diff --git a/arch/arm/boot/dts/omap3-gta04.dts
b/arch/arm/boot/dts/omap3-gta04.dts
index 0a1e7c8..4a19199 100644
--- a/arch/arm/boot/dts/omap3-gta04.dts
+++ b/arch/arm/boot/dts/omap3-gta04.dts
@@ -306,6 +306,11 @@
>;
};
+ bma180_pins: pinmux_bma180_pins {
+ pinctrl-single,pins = <
+ OMAP3_CORE1_IOPAD(0x213a, PIN_INPUT_PULLUP |
MUX_MODE4) /* gpio115 */
+ >;
+ };
};
&omap3_pmx_core2 {
@@ -414,7 +419,9 @@
/* we use the BMA150 Input (CONFIG_INPUT_BMA150)
driver */
compatible = "bosch,bma180";
reg = <0x41>;
- interrupt-parent = <&gpio3>;
+ pinctrl-names = "default";
+ pintcrl-0 = <&bma180_pins>;
+ interrupt-parent = <&gpio4>;
interrupts = <19 (IRQ_TYPE_LEVEL_HIGH |
IRQ_TYPE_EDGE_RISING)>;
};
diff --git a/drivers/input/misc/bma150.c
b/drivers/input/misc/bma150.c
index b36831c..35a7bf5 100644
--- a/drivers/input/misc/bma150.c
+++ b/drivers/input/misc/bma150.c
@@ -650,6 +650,13 @@ static const struct i2c_device_id bma150_id[] =
{
{ }
};
+#ifdef CONFIG_OF
+static const struct of_device_id of_bma150_match[] = {
+ { .compatible = "bosch,bma180", },
+ {},
+};
+#endif
+
MODULE_DEVICE_TABLE(i2c, bma150_id);
static struct i2c_driver bma150_driver = {
@@ -657,6 +664,7 @@ static struct i2c_driver bma150_driver = {
.owner = THIS_MODULE,
.name = BMA150_DRIVER,
.pm = &bma150_pm,
+ .of_match_table = of_match_ptr(of_bma150_match),
},
.class = I2C_CLASS_HWMON,
.id_table = bma150_id,
Comment 6 by Nikolaus Schaller, Apr 29, 2014
/dev/accel is created by some udev-rule: http://git.goldelico.com/?p=gta04-kernel.git;a=blob;f=GTA04/udev-rule s/input.rules;h=2cc8df93f1d2a4a43ca77a5d77645cdec9b75981;hb=HEAD#l3 But it might no longer be valid for any reason... Shouldn't we have two .compatible entries? Yes, I can try to scope for the interrupt in the next days, but not immediately.
Comment 7 by Marek Belisko, Apr 30, 2014
OK. I'm using only base yocto build not debian rootfs. Yes there could be more compatible entries but this was just for testing if everything works fine. If we fix irq problem then I'll ad more an post upstream. Thanks for measuring. I'll jump to cpufreq issue for time being.
Comment 8 by Nikolaus Schaller, May 1, 2014
Some more test results: 1. it does not relate to Issue #580 or #588 2. the driver can be operated in polling mode, but still does not report realistic values (at least one dimension should be != 0) root@gta04:~# evtest /dev/input/accel [ 91.055114] bma150_report_xyz Input driver version is 1.0.1 Input device ID: bus 0x18 vendor 0x0 product 0x0 version 0x0 Input device name:[ 91.066375] bma150_report_xyz "bma150" Supported events: Event type 0 (EV_SYN) Event type 3 (EV_ABS) Event code 0 (ABS_X) Value 0 Min -511 Max 511 Event code 1 (ABS_Y) Value 0 Min -511 Max 511 Event code 2 (S_Z) Value 0 Min -511 Max 511 Properties: [ 91.105773] bma150_report_xyz [ 91.117034] bma150_report_xyz [ 91.125946] bma150_report_xyz [ 91.135833] bma150_report_xyz [ 91.145812] bma150_report_xyz [ 91.155853] bma150_report_xyz [ 91.165832] bma150_report_xyz [ 91.175811] bma150_report_xyz [ 91.185791] bma150_report_xyz [ 91.195953] bma150_report_xyz [ 91.205810] bma150_report_xyz Which means that we have two problems: a) chip programming/read out may be broken b) no interrupts (maybe because the chip isn't programmed correctly)
Comment 9 by Nikolaus Schaller, May 3, 2014
Summary of further analysis: The BMA150 driver is not really prepared to handle the BMA180. They only have the first 9 I2C registers in common and everything else is different. So it was probably big luck that it did work at all. We have to extend the driver to detect the BMA150 vs. BMA180 and then use different registers and bits for proper configuration.
Summary:
3.15: BMA150 driver should correctly program BMA180 as well
Comment 10 by Nikolaus Schaller, Jun 1, 2014
BMA150 input driver has been extended. Needs testing (and maybe some further improvements). E.g. data range and setting of sensitivity does not match. But we can reduce priority.
Labels:
Priority:Medium
Priority:Critical
Comment 12 by Nikolaus Schaller, Dec 17, 2016
A new approach seems to work, an iio-input bridge: http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/ work/hns/iio-input-bridge
Comment 13 by Nikolaus Schaller, Dec 17, 2016
changed issue title as well
Summary:
Create iio-input-bridge to use BMA180 or BMC150_ACCEL iio driver as /dev/input device
Comment 14 by Nikolaus Schaller, Feb 16, 2019
There is now a solution ready for upstream. Duplicate with 877
Status:
Duplicate
Relations: is related to 877
Relations: is related to 877
Sign in to reply to this comment.
Reported by Nikolaus Schaller, Apr 10, 2014