Trigger (drdy) on st-sensor lis331dlh - how to question

Trigger (drdy) on st-sensor lis331dlh - how to question

[Branko Karaklajic]

Hi to everyone,

This question is a bit long, but please bear with me for a moment, as
we need your help to understand if we are doing something wrong (first
time IIO usage on our side).

We are working on project with SAMA5D3 board and accelerometer
(lis331dlh) sensor and linux 3.17-rc5. We successfully connected
lis331dlh to board via SPI interface, and we are able to read sensor
through spidev and also through IIO interface by reading raw values.

But there is a problem with IIO buffer, as we are not able to get any
data through buffer.
Our understanding is that we should define interrupt which will be
triggered outside (by sensor data-ready-int output), and this
interrupt will trigger IIO to read data and store it to buffer.

Sensor <data ready> output is connected to Port D, pin 21 of CPU, and
device tree looks like:

spi1: spi@f8008000 {
  cs-gpios = <&pioC 25 0>;
  status = "okay";

  lis331dlh@0 {
      compatible = "st,lis331dlh-accel";
      spi-max-frequency = <10000000>;
      reg = <0>;
      interrupt-parent = <&pioD>;
      interrupts = <21 IRQ_TYPE_LEVEL_HIGH>;
      st,drdy-int-pin = <1>;
    };
};

and on boot up we got these messages:

st-accel-spi spi32765.0: st_sensors_of_spi_probe() - lis331dlh.
iio iio:device0: st_sensors_check_device_support() - lis331dlh.
iio iio:device0: st_sensors_init_sensor().
iio iio:device0: st_sensors_set_drdy_int_pin() - drdy_int_pin=1.
iio iio:device0: st_accel_allocate_ring()
iio iio:device0: st_accel_common_probe() - irq: 172.
iio iio:device0: registered accelerometer lis331dlh

As you can see, accelerometer is succesfully registered, and we are
able to read raw data with:

    $ cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw

this is how our directory looks like:
    $ ls -al /sys/bus/iio/devices/
lrwxrwxrwx    1 root     root             0 Jan  1 00:17 iio:device0
-> ../../../devices/ahb/ahb:apb/f8008000.spi/spi_master/spi32765/spi32765.0/iio:device0
lrwxrwxrwx    1 root     root             0 Jan  1 00:17 trigger0 ->
../../../devices/ahb/ahb:apb/f8008000.spi/spi_master/spi32765/spi32765.0/trigger0

So trigger is also registred with name lis331dlh-trigger.

dmsg line:
...
iio iio:device0: st_accel_common_probe() - irq: 172.
...
indicates that irq 172 (which is IRQ for Port D, pin 21) is registered
(which is also checked in /proc/irq).

So, with all this set, we are not successful to get data from buffer.
Our first guess is to use generic_buffer.c, which we successfully
tried on internal ADC, but there is no data in buffer.

Steps we are using are:
Enable channel in_accel_x_en in iio:device0/scan_elements
Write <lis331dlh-trigger> in iio:device0/trigger/current_trigger
Write length of 16 in iio:device0/buffer/length
Write 1 in iio:device0/buffer/enable

That should be enough to get data into buffer by driver and than to
read it from buffer. Is that true? Did we missed something.

>From HW point of view, we could see transition on interrupt pin when
we enable buffer, but no reading of data.

Our understanding is that function <irqreturn_t
st_sensors_trigger_handler(int irq, void *p)> from file
linux/drivers/iio/common/st_sensors/st_sensors_buffer.c should be
called when interrupt is generated. Is this assumption correct? In our
case it's never called.

Thanks in advance
Branko

Re: Trigger (drdy) on st-sensor lis331dlh - how to question

[Denis CIOCCA]

SGkgQnJhbmtvLA0KDQpJdCBzZWVtcyB0aGUgcHJvYmxlbSBpcyByZWxhdGVkIHRvIHRoZSBncGlv
IGNvbmZpZ3VyYXRpb24uDQoNCj4gU2Vuc29yIDxkYXRhIHJlYWR5PiBvdXRwdXQgaXMgY29ubmVj
dGVkIHRvIFBvcnQgRCwgcGluIDIxIG9mIENQVSwgYW5kDQo+IGRldmljZSB0cmVlIGxvb2tzIGxp
a2U6DQo+DQo+IHNwaTE6IHNwaUBmODAwODAwMCB7DQo+ICAgIGNzLWdwaW9zID0gPCZwaW9DIDI1
IDA+Ow0KPiAgICBzdGF0dXMgPSAib2theSI7DQo+DQo+ICAgIGxpczMzMWRsaEAwIHsNCj4gICAg
ICAgIGNvbXBhdGlibGUgPSAic3QsbGlzMzMxZGxoLWFjY2VsIjsNCj4gICAgICAgIHNwaS1tYXgt
ZnJlcXVlbmN5ID0gPDEwMDAwMDAwPjsNCj4gICAgICAgIHJlZyA9IDwwPjsNCj4gICAgICAgIGlu
dGVycnVwdC1wYXJlbnQgPSA8JnBpb0Q+Ow0KPiAgICAgICAgaW50ZXJydXB0cyA9IDwyMSBJUlFf
VFlQRV9MRVZFTF9ISUdIPjsNCmludGVycnVwdHMgPSA8MjEgMHgwPjsNCg0KVGhlIElSUSBpcyB1
c2VkIGluIFJJU0lORy4NCj4gICAgICAgIHN0LGRyZHktaW50LXBpbiA9IDwxPjsNCj4gICAgICB9
Ow0KPiB9Ow0KDQpCUiwNCkRlbmlzDQoNCg0KDQo+IGFuZCBvbiBib290IHVwIHdlIGdvdCB0aGVz
ZSBtZXNzYWdlczoNCj4NCj4gc3QtYWNjZWwtc3BpIHNwaTMyNzY1LjA6IHN0X3NlbnNvcnNfb2Zf
c3BpX3Byb2JlKCkgLSBsaXMzMzFkbGguDQo+IGlpbyBpaW86ZGV2aWNlMDogc3Rfc2Vuc29yc19j
aGVja19kZXZpY2Vfc3VwcG9ydCgpIC0gbGlzMzMxZGxoLg0KPiBpaW8gaWlvOmRldmljZTA6IHN0
X3NlbnNvcnNfaW5pdF9zZW5zb3IoKS4NCj4gaWlvIGlpbzpkZXZpY2UwOiBzdF9zZW5zb3JzX3Nl
dF9kcmR5X2ludF9waW4oKSAtIGRyZHlfaW50X3Bpbj0xLg0KPiBpaW8gaWlvOmRldmljZTA6IHN0
X2FjY2VsX2FsbG9jYXRlX3JpbmcoKQ0KPiBpaW8gaWlvOmRldmljZTA6IHN0X2FjY2VsX2NvbW1v
bl9wcm9iZSgpIC0gaXJxOiAxNzIuDQo+IGlpbyBpaW86ZGV2aWNlMDogcmVnaXN0ZXJlZCBhY2Nl
bGVyb21ldGVyIGxpczMzMWRsaA0KPg0KPiBBcyB5b3UgY2FuIHNlZSwgYWNjZWxlcm9tZXRlciBp
cyBzdWNjZXNmdWxseSByZWdpc3RlcmVkLCBhbmQgd2UgYXJlDQo+IGFibGUgdG8gcmVhZCByYXcg
ZGF0YSB3aXRoOg0KPg0KPiAgICAgICQgY2F0IC9zeXMvYnVzL2lpby9kZXZpY2VzL2lpbzpkZXZp
Y2UwL2luX2FjY2VsX3hfcmF3DQo+DQo+IHRoaXMgaXMgaG93IG91ciBkaXJlY3RvcnkgbG9va3Mg
bGlrZToNCj4gICAgICAkIGxzIC1hbCAvc3lzL2J1cy9paW8vZGV2aWNlcy8NCj4gbHJ3eHJ3eHJ3
eCAgICAxIHJvb3QgICAgIHJvb3QgICAgICAgICAgICAgMCBKYW4gIDEgMDA6MTcgaWlvOmRldmlj
ZTANCj4gLT4gLi4vLi4vLi4vZGV2aWNlcy9haGIvYWhiOmFwYi9mODAwODAwMC5zcGkvc3BpX21h
c3Rlci9zcGkzMjc2NS9zcGkzMjc2NS4wL2lpbzpkZXZpY2UwDQo+IGxyd3hyd3hyd3ggICAgMSBy
b290ICAgICByb290ICAgICAgICAgICAgIDAgSmFuICAxIDAwOjE3IHRyaWdnZXIwIC0+DQo+IC4u
Ly4uLy4uL2RldmljZXMvYWhiL2FoYjphcGIvZjgwMDgwMDAuc3BpL3NwaV9tYXN0ZXIvc3BpMzI3
NjUvc3BpMzI3NjUuMC90cmlnZ2VyMA0KPg0KPiBTbyB0cmlnZ2VyIGlzIGFsc28gcmVnaXN0cmVk
IHdpdGggbmFtZSBsaXMzMzFkbGgtdHJpZ2dlci4NCj4NCj4gZG1zZyBsaW5lOg0KPiAuLi4NCj4g
aWlvIGlpbzpkZXZpY2UwOiBzdF9hY2NlbF9jb21tb25fcHJvYmUoKSAtIGlycTogMTcyLg0KPiAu
Li4NCj4gaW5kaWNhdGVzIHRoYXQgaXJxIDE3MiAod2hpY2ggaXMgSVJRIGZvciBQb3J0IEQsIHBp
biAyMSkgaXMgcmVnaXN0ZXJlZA0KPiAod2hpY2ggaXMgYWxzbyBjaGVja2VkIGluIC9wcm9jL2ly
cSkuDQo+DQo+IFNvLCB3aXRoIGFsbCB0aGlzIHNldCwgd2UgYXJlIG5vdCBzdWNjZXNzZnVsIHRv
IGdldCBkYXRhIGZyb20gYnVmZmVyLg0KPiBPdXIgZmlyc3QgZ3Vlc3MgaXMgdG8gdXNlIGdlbmVy
aWNfYnVmZmVyLmMsIHdoaWNoIHdlIHN1Y2Nlc3NmdWxseQ0KPiB0cmllZCBvbiBpbnRlcm5hbCBB
REMsIGJ1dCB0aGVyZSBpcyBubyBkYXRhIGluIGJ1ZmZlci4NCj4NCj4gU3RlcHMgd2UgYXJlIHVz
aW5nIGFyZToNCj4gRW5hYmxlIGNoYW5uZWwgaW5fYWNjZWxfeF9lbiBpbiBpaW86ZGV2aWNlMC9z
Y2FuX2VsZW1lbnRzDQo+IFdyaXRlIDxsaXMzMzFkbGgtdHJpZ2dlcj4gaW4gaWlvOmRldmljZTAv
dHJpZ2dlci9jdXJyZW50X3RyaWdnZXINCj4gV3JpdGUgbGVuZ3RoIG9mIDE2IGluIGlpbzpkZXZp
Y2UwL2J1ZmZlci9sZW5ndGgNCj4gV3JpdGUgMSBpbiBpaW86ZGV2aWNlMC9idWZmZXIvZW5hYmxl
DQo+DQo+IFRoYXQgc2hvdWxkIGJlIGVub3VnaCB0byBnZXQgZGF0YSBpbnRvIGJ1ZmZlciBieSBk
cml2ZXIgYW5kIHRoYW4gdG8NCj4gcmVhZCBpdCBmcm9tIGJ1ZmZlci4gSXMgdGhhdCB0cnVlPyBE
aWQgd2UgbWlzc2VkIHNvbWV0aGluZy4NCj4NCj4gIEZyb20gSFcgcG9pbnQgb2Ygdmlldywgd2Ug
Y291bGQgc2VlIHRyYW5zaXRpb24gb24gaW50ZXJydXB0IHBpbiB3aGVuDQo+IHdlIGVuYWJsZSBi
dWZmZXIsIGJ1dCBubyByZWFkaW5nIG9mIGRhdGEuDQo+DQo+IE91ciB1bmRlcnN0YW5kaW5nIGlz
IHRoYXQgZnVuY3Rpb24gPGlycXJldHVybl90DQo+IHN0X3NlbnNvcnNfdHJpZ2dlcl9oYW5kbGVy
KGludCBpcnEsIHZvaWQgKnApPiBmcm9tIGZpbGUNCj4gbGludXgvZHJpdmVycy9paW8vY29tbW9u
L3N0X3NlbnNvcnMvc3Rfc2Vuc29yc19idWZmZXIuYyBzaG91bGQgYmUNCj4gY2FsbGVkIHdoZW4g
aW50ZXJydXB0IGlzIGdlbmVyYXRlZC4gSXMgdGhpcyBhc3N1bXB0aW9uIGNvcnJlY3Q/IEluIG91
cg0KPiBjYXNlIGl0J3MgbmV2ZXIgY2FsbGVkLg0KPg0KPiBUaGFua3MgaW4gYWR2YW5jZQ0KPiBC
cmFua28NCj4gLS0NCj4gVG8gdW5zdWJzY3JpYmUgZnJvbSB0aGlzIGxpc3Q6IHNlbmQgdGhlIGxp
bmUgInVuc3Vic2NyaWJlIGxpbnV4LWlpbyIgaW4NCj4gdGhlIGJvZHkgb2YgYSBtZXNzYWdlIHRv
IG1ham9yZG9tb0B2Z2VyLmtlcm5lbC5vcmcNCj4gTW9yZSBtYWpvcmRvbW8gaW5mbyBhdCAgaHR0
cDovL3ZnZXIua2VybmVsLm9yZy9tYWpvcmRvbW8taW5mby5odG1sDQo=

Re: Trigger (drdy) on st-sensor lis331dlh - how to question

[Branko Karaklajic]

Hi Denis,

thanks for fast response. I forget to say that we tried with all
possible configurations on interrupt. So, no luck with any setting. No
bump on irq handler at all.

Branko
On 23 September 2014 18:12, Denis CIOCCA <denis.ciocca@st.com> wrote:
> Hi Branko,
>
> It seems the problem is related to the gpio configuration.
>
>> Sensor <data ready> output is connected to Port D, pin 21 of CPU, and
>> device tree looks like:
>>
>> spi1: spi@f8008000 {
>>    cs-gpios = <&pioC 25 0>;
>>    status = "okay";
>>
>>    lis331dlh@0 {
>>        compatible = "st,lis331dlh-accel";
>>        spi-max-frequency = <10000000>;
>>        reg = <0>;
>>        interrupt-parent = <&pioD>;
>>        interrupts = <21 IRQ_TYPE_LEVEL_HIGH>;
> interrupts = <21 0x0>;
>
> The IRQ is used in RISING.
>>        st,drdy-int-pin = <1>;
>>      };
>> };
>
> BR,
> Denis
>
>
>
>> and on boot up we got these messages:
>>
>> st-accel-spi spi32765.0: st_sensors_of_spi_probe() - lis331dlh.
>> iio iio:device0: st_sensors_check_device_support() - lis331dlh.
>> iio iio:device0: st_sensors_init_sensor().
>> iio iio:device0: st_sensors_set_drdy_int_pin() - drdy_int_pin=1.
>> iio iio:device0: st_accel_allocate_ring()
>> iio iio:device0: st_accel_common_probe() - irq: 172.
>> iio iio:device0: registered accelerometer lis331dlh
>>
>> As you can see, accelerometer is succesfully registered, and we are
>> able to read raw data with:
>>
>>      $ cat /sys/bus/iio/devices/iio:device0/in_accel_x_raw
>>
>> this is how our directory looks like:
>>      $ ls -al /sys/bus/iio/devices/
>> lrwxrwxrwx    1 root     root             0 Jan  1 00:17 iio:device0
>> -> ../../../devices/ahb/ahb:apb/f8008000.spi/spi_master/spi32765/spi32765.0/iio:device0
>> lrwxrwxrwx    1 root     root             0 Jan  1 00:17 trigger0 ->
>> ../../../devices/ahb/ahb:apb/f8008000.spi/spi_master/spi32765/spi32765.0/trigger0
>>
>> So trigger is also registred with name lis331dlh-trigger.
>>
>> dmsg line:
>> ...
>> iio iio:device0: st_accel_common_probe() - irq: 172.
>> ...
>> indicates that irq 172 (which is IRQ for Port D, pin 21) is registered
>> (which is also checked in /proc/irq).
>>
>> So, with all this set, we are not successful to get data from buffer.
>> Our first guess is to use generic_buffer.c, which we successfully
>> tried on internal ADC, but there is no data in buffer.
>>
>> Steps we are using are:
>> Enable channel in_accel_x_en in iio:device0/scan_elements
>> Write <lis331dlh-trigger> in iio:device0/trigger/current_trigger
>> Write length of 16 in iio:device0/buffer/length
>> Write 1 in iio:device0/buffer/enable
>>
>> That should be enough to get data into buffer by driver and than to
>> read it from buffer. Is that true? Did we missed something.
>>
>>  From HW point of view, we could see transition on interrupt pin when
>> we enable buffer, but no reading of data.
>>
>> Our understanding is that function <irqreturn_t
>> st_sensors_trigger_handler(int irq, void *p)> from file
>> linux/drivers/iio/common/st_sensors/st_sensors_buffer.c should be
>> called when interrupt is generated. Is this assumption correct? In our
>> case it's never called.
>>
>> Thanks in advance
>> Branko
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html