Letux Kernel

Issue 583: Create iio-input-bridge to use BMA180 or BMC150_ACCEL iio driver as /dev/input device

Reported by Nikolaus Schaller, Apr 10, 2014

-

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 11 by Nikolaus Schaller, Aug 17, 2014

Status: Accepted
Owner: hns

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

Created: 6 years 1 month ago by Nikolaus Schaller

Updated: 1 year 3 months ago

Status: Duplicate

Owner: Nikolaus Schaller

Followed by: 2 persons

Labels:
Type:Defect
Priority:Medium
Milestone:3.15

This issue is related to
877 - Accelerometer orientation