Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/16/13 10:29, Oleksandr Kravchenko wrote:
> On Thu, Aug 15, 2013 at 8:57 PM, Jonathan Cameron wrote:
>> On 08/15/13 14:41, Oleksandr Kravchenko wrote:
>>> On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron wrote:
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
> This patch adds IIO driver for Bosch BMA180 triaxial
> acceleration sensor.
> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
> Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
>
> Signed-off-by: Oleksandr Kravchenko
Hi,
Firstly, just a thought (I haven't made up my mind whether it is a good
idea or
not!) but you could use devm_kzalloc for data->buff and hence avoid having
to care about freeing it in the remove function. Update scan mode isn't
a particularly fast path so I doubt the small overhead will matter.
>>> Thanks, it is a good idea.
>>>
Otherwise, the abi additions need documenting iff they don't fit within
existing ABI. If they do then they need to match existing ABI.
Of those, 'mode' is rather device specific and could probably do with
a more detailed name. The only 'generic' way to do it would be to make the
channel type attributes writable and treat it as a resolution control
rather
than a noise/power trade off. Uggly though so perhaps what you have makes
sense. We can always add a more generic way of controlling this if it
starts turning up in lots of devices (keeping this method of course to
avoid
breaking ABI).
>>> Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
> Can I use ext_info and iio_chan_spec_ext_info to provide my "power_mode"
> in my driver like "powerdown_mode" in some other drivers?
Yes.
>
'bandwidth' is already (I think) covered by the ABI. For the bandwidth
optoins you have enabled we are talking low pass
filters and presumably their 3db point.
In Documentation/ABI/testing/sysfs-bus-iio you will find
in_accel_filter_low_pass_3db_frequency. My filter theory is
rather rusty (not sure it was
every anything else ;). Hence I'm not entirely sure how to work
out the 3db frequency from the 'pole frequency' if they are not infact
the same thing..
>>> You are right. In my case 'bandwidth' is low path filter. I'll change my
>>> driver
>>> accordingly. But how can I declare available values?
>>> If I do it in next way:
>>> static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
>>> BMA180_BW_AVAILABLE);
>> Not shared across all channels? If it is then
>> in_accel_filter_low_pass_3db_frequency_available it is...
>>> it will lock so ugly in the code and sysfs...
>>
>> yeah. There are plans to clean that sort of thing up. I keep mentioning
>> them
>> and never getting them done though.
>>
>> In brief drivers will be able to provide and additional callback
>> which will then return pointers to arrays containing all the numbers to
>> specify the 'range' of values any parameter in info_mask can take
>> (note this includes the raw and processed values as well as the other bits).
>>
>> I sketch out how we could do this from time to time and dont' quite get
>> around to
>> doing it.
>>>
Otherwise, the driver looks good to me.
Jonathan
> ---
> .../devicetree/bindings/iio/accel/bma180.txt | 24 +
> drivers/iio/accel/Kconfig | 12 +
> drivers/iio/accel/Makefile |2 +
> drivers/iio/accel/bma180.c | 689
>
> 4 files changed, 727 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
> create mode 100644 drivers/iio/accel/bma180.c
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
> b/Documentation/devicetree/bindings/iio/accel/bma180.txt
> new file mode 100644
> index 000..c593357
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
> @@ -0,0 +1,24 @@
> +* Bosch BMA180 triaxial acceleration sensor
> +
> +http://omapworld.com/BMA180_111_1002839.pdf
> +
> +Required properties:
> +
> + - compatible : should be "bosch,bma180"
> + - reg : the I2C address of the sensor
> +
> +Optional properties:
> +
> + - interrupt-parent : should be the phandle for the interrupt controller
> +
> + - interrupts : interrupt mapping for GPIO IRQ, it should by configured
> with
> + flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
> +
> +Example:
> +
> +bma180@40 {
> + compatible = "bosch,bma180";
> + reg = <0x40>;
> + interrupt-parent = <>;
> + interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
> +};
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On Thu, Aug 15, 2013 at 8:57 PM, Jonathan Cameron wrote:
> On 08/15/13 14:41, Oleksandr Kravchenko wrote:
>> On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron wrote:
>>> On 08/13/13 16:44, Oleksandr Kravchenko wrote:
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Signed-off-by: Oleksandr Kravchenko
>>> Hi,
>>>
>>> Firstly, just a thought (I haven't made up my mind whether it is a good
>>> idea or
>>> not!) but you could use devm_kzalloc for data->buff and hence avoid having
>>> to care about freeing it in the remove function. Update scan mode isn't
>>> a particularly fast path so I doubt the small overhead will matter.
>> Thanks, it is a good idea.
>>
>>>
>>> Otherwise, the abi additions need documenting iff they don't fit within
>>> existing ABI. If they do then they need to match existing ABI.
>>>
>>> Of those, 'mode' is rather device specific and could probably do with
>>> a more detailed name. The only 'generic' way to do it would be to make the
>>> channel type attributes writable and treat it as a resolution control rather
>>> than a noise/power trade off. Uggly though so perhaps what you have makes
>>> sense. We can always add a more generic way of controlling this if it
>>> starts turning up in lots of devices (keeping this method of course to avoid
>>> breaking ABI).
>> Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
Can I use ext_info and iio_chan_spec_ext_info to provide my "power_mode"
in my driver like "powerdown_mode" in some other drivers?
>>>
>>> 'bandwidth' is already (I think) covered by the ABI. For the bandwidth
>>> optoins you have enabled we are talking low pass
>>> filters and presumably their 3db point.
>>> In Documentation/ABI/testing/sysfs-bus-iio you will find
>>> in_accel_filter_low_pass_3db_frequency. My filter theory is
>>> rather rusty (not sure it was
>>> every anything else ;). Hence I'm not entirely sure how to work
>>> out the 3db frequency from the 'pole frequency' if they are not infact
>>> the same thing..
>> You are right. In my case 'bandwidth' is low path filter. I'll change my
>> driver
>> accordingly. But how can I declare available values?
>> If I do it in next way:
>> static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
>> BMA180_BW_AVAILABLE);
> Not shared across all channels? If it is then
> in_accel_filter_low_pass_3db_frequency_available it is...
>> it will lock so ugly in the code and sysfs...
>
> yeah. There are plans to clean that sort of thing up. I keep mentioning
> them
> and never getting them done though.
>
> In brief drivers will be able to provide and additional callback
> which will then return pointers to arrays containing all the numbers to
> specify the 'range' of values any parameter in info_mask can take
> (note this includes the raw and processed values as well as the other bits).
>
> I sketch out how we could do this from time to time and dont' quite get
> around to
> doing it.
>>
>>>
>>> Otherwise, the driver looks good to me.
>>>
>>> Jonathan
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 689
4 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be "bosch,bma180"
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured
with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = "bosch,bma180";
+ reg = <0x40>;
+ interrupt-parent = <>;
+ interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu "Accelerometers"
+config BMA180
+
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On Thu, Aug 15, 2013 at 8:57 PM, Jonathan Cameron ji...@kernel.org wrote:
On 08/15/13 14:41, Oleksandr Kravchenko wrote:
On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron ji...@kernel.org wrote:
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Signed-off-by: Oleksandr Kravchenko o.v.kravche...@globallogic.com
Hi,
Firstly, just a thought (I haven't made up my mind whether it is a good
idea or
not!) but you could use devm_kzalloc for data-buff and hence avoid having
to care about freeing it in the remove function. Update scan mode isn't
a particularly fast path so I doubt the small overhead will matter.
Thanks, it is a good idea.
Otherwise, the abi additions need documenting iff they don't fit within
existing ABI. If they do then they need to match existing ABI.
Of those, 'mode' is rather device specific and could probably do with
a more detailed name. The only 'generic' way to do it would be to make the
channel type attributes writable and treat it as a resolution control rather
than a noise/power trade off. Uggly though so perhaps what you have makes
sense. We can always add a more generic way of controlling this if it
starts turning up in lots of devices (keeping this method of course to avoid
breaking ABI).
Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
Can I use ext_info and iio_chan_spec_ext_info to provide my power_mode
in my driver like powerdown_mode in some other drivers?
'bandwidth' is already (I think) covered by the ABI. For the bandwidth
optoins you have enabled we are talking low pass
filters and presumably their 3db point.
In Documentation/ABI/testing/sysfs-bus-iio you will find
in_accel_filter_low_pass_3db_frequency. My filter theory is
rather rusty (not sure it was
every anything else ;). Hence I'm not entirely sure how to work
out the 3db frequency from the 'pole frequency' if they are not infact
the same thing..
You are right. In my case 'bandwidth' is low path filter. I'll change my
driver
accordingly. But how can I declare available values?
If I do it in next way:
static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
BMA180_BW_AVAILABLE);
Not shared across all channels? If it is then
in_accel_filter_low_pass_3db_frequency_available it is...
it will lock so ugly in the code and sysfs...
yeah. There are plans to clean that sort of thing up. I keep mentioning
them
and never getting them done though.
In brief drivers will be able to provide and additional callback
which will then return pointers to arrays containing all the numbers to
specify the 'range' of values any parameter in info_mask can take
(note this includes the raw and processed values as well as the other bits).
I sketch out how we could do this from time to time and dont' quite get
around to
doing it.
Otherwise, the driver looks good to me.
Jonathan
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 689
4 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be bosch,bma180
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured
with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = bosch,bma180;
+ reg = 0x40;
+ interrupt-parent = gpio6;
+ interrupts = 18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING);
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu Accelerometers
+config BMA180
+ tristate Bosch BMA180 3-Axis Accelerometer Driver
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/16/13 10:29, Oleksandr Kravchenko wrote:
On Thu, Aug 15, 2013 at 8:57 PM, Jonathan Cameron ji...@kernel.org wrote:
On 08/15/13 14:41, Oleksandr Kravchenko wrote:
On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron ji...@kernel.org wrote:
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Signed-off-by: Oleksandr Kravchenko o.v.kravche...@globallogic.com
Hi,
Firstly, just a thought (I haven't made up my mind whether it is a good
idea or
not!) but you could use devm_kzalloc for data-buff and hence avoid having
to care about freeing it in the remove function. Update scan mode isn't
a particularly fast path so I doubt the small overhead will matter.
Thanks, it is a good idea.
Otherwise, the abi additions need documenting iff they don't fit within
existing ABI. If they do then they need to match existing ABI.
Of those, 'mode' is rather device specific and could probably do with
a more detailed name. The only 'generic' way to do it would be to make the
channel type attributes writable and treat it as a resolution control
rather
than a noise/power trade off. Uggly though so perhaps what you have makes
sense. We can always add a more generic way of controlling this if it
starts turning up in lots of devices (keeping this method of course to
avoid
breaking ABI).
Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
Can I use ext_info and iio_chan_spec_ext_info to provide my power_mode
in my driver like powerdown_mode in some other drivers?
Yes.
'bandwidth' is already (I think) covered by the ABI. For the bandwidth
optoins you have enabled we are talking low pass
filters and presumably their 3db point.
In Documentation/ABI/testing/sysfs-bus-iio you will find
in_accel_filter_low_pass_3db_frequency. My filter theory is
rather rusty (not sure it was
every anything else ;). Hence I'm not entirely sure how to work
out the 3db frequency from the 'pole frequency' if they are not infact
the same thing..
You are right. In my case 'bandwidth' is low path filter. I'll change my
driver
accordingly. But how can I declare available values?
If I do it in next way:
static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
BMA180_BW_AVAILABLE);
Not shared across all channels? If it is then
in_accel_filter_low_pass_3db_frequency_available it is...
it will lock so ugly in the code and sysfs...
yeah. There are plans to clean that sort of thing up. I keep mentioning
them
and never getting them done though.
In brief drivers will be able to provide and additional callback
which will then return pointers to arrays containing all the numbers to
specify the 'range' of values any parameter in info_mask can take
(note this includes the raw and processed values as well as the other bits).
I sketch out how we could do this from time to time and dont' quite get
around to
doing it.
Otherwise, the driver looks good to me.
Jonathan
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 689
4 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be bosch,bma180
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured
with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = bosch,bma180;
+ reg = 0x40;
+ interrupt-parent = gpio6;
+ interrupts = 18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING);
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu Accelerometers
+config BMA180
+ tristate Bosch BMA180 3-Axis Accelerometer Driver
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/15/13 14:41, Oleksandr Kravchenko wrote:
> On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron wrote:
>> On 08/13/13 16:44, Oleksandr Kravchenko wrote:
>>> This patch adds IIO driver for Bosch BMA180 triaxial
>>> acceleration sensor.
>>> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
>>> Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
>>>
>>> Signed-off-by: Oleksandr Kravchenko
>> Hi,
>>
>> Firstly, just a thought (I haven't made up my mind whether it is a good idea
>> or
>> not!) but you could use devm_kzalloc for data->buff and hence avoid having
>> to care about freeing it in the remove function. Update scan mode isn't
>> a particularly fast path so I doubt the small overhead will matter.
> Thanks, it is a good idea.
>
>>
>> Otherwise, the abi additions need documenting iff they don't fit within
>> existing ABI. If they do then they need to match existing ABI.
>>
>> Of those, 'mode' is rather device specific and could probably do with
>> a more detailed name. The only 'generic' way to do it would be to make the
>> channel type attributes writable and treat it as a resolution control rather
>> than a noise/power trade off. Uggly though so perhaps what you have makes
>> sense. We can always add a more generic way of controlling this if it
>> starts turning up in lots of devices (keeping this method of course to avoid
>> breaking ABI).
> Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
>>
>> 'bandwidth' is already (I think) covered by the ABI. For the bandwidth
>> optoins you have enabled we are talking low pass
>> filters and presumably their 3db point.
>> In Documentation/ABI/testing/sysfs-bus-iio you will find
>> in_accel_filter_low_pass_3db_frequency. My filter theory is
>> rather rusty (not sure it was
>> every anything else ;). Hence I'm not entirely sure how to work
>> out the 3db frequency from the 'pole frequency' if they are not infact
>> the same thing..
> You are right. In my case 'bandwidth' is low path filter. I'll change my
> driver
> accordingly. But how can I declare available values?
> If I do it in next way:
> static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
> BMA180_BW_AVAILABLE);
Not shared across all channels? If it is then
in_accel_filter_low_pass_3db_frequency_available it is...
> it will lock so ugly in the code and sysfs...
yeah. There are plans to clean that sort of thing up. I keep mentioning them
and never getting them done though.
In brief drivers will be able to provide and additional callback
which will then return pointers to arrays containing all the numbers to
specify the 'range' of values any parameter in info_mask can take
(note this includes the raw and processed values as well as the other bits).
I sketch out how we could do this from time to time and dont' quite get around
to
doing it.
>
>>
>> Otherwise, the driver looks good to me.
>>
>> Jonathan
>>> ---
>>> .../devicetree/bindings/iio/accel/bma180.txt | 24 +
>>> drivers/iio/accel/Kconfig | 12 +
>>> drivers/iio/accel/Makefile |2 +
>>> drivers/iio/accel/bma180.c | 689
>>>
>>> 4 files changed, 727 insertions(+)
>>> create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
>>> create mode 100644 drivers/iio/accel/bma180.c
>>>
>>> diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
>>> b/Documentation/devicetree/bindings/iio/accel/bma180.txt
>>> new file mode 100644
>>> index 000..c593357
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
>>> @@ -0,0 +1,24 @@
>>> +* Bosch BMA180 triaxial acceleration sensor
>>> +
>>> +http://omapworld.com/BMA180_111_1002839.pdf
>>> +
>>> +Required properties:
>>> +
>>> + - compatible : should be "bosch,bma180"
>>> + - reg : the I2C address of the sensor
>>> +
>>> +Optional properties:
>>> +
>>> + - interrupt-parent : should be the phandle for the interrupt controller
>>> +
>>> + - interrupts : interrupt mapping for GPIO IRQ, it should by configured
>>> with
>>> + flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
>>> +
>>> +Example:
>>> +
>>> +bma180@40 {
>>> + compatible = "bosch,bma180";
>>> + reg = <0x40>;
>>> + interrupt-parent = <>;
>>> + interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
>>> +};
>>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>>> index 719d83f..bd9d581 100644
>>> --- a/drivers/iio/accel/Kconfig
>>> +++ b/drivers/iio/accel/Kconfig
>>> @@ -3,6 +3,18 @@
>>> #
>>> menu "Accelerometers"
>>>
>>> +config BMA180
>>> + tristate "Bosch BMA180 3-Axis Accelerometer Driver"
>>> + depends on I2C
>>> + select IIO_BUFFER
>>> + select IIO_TRIGGERED_BUFFER
>>> + help
>>> + Say Y here if you want to build a driver for the Bosch BMA180
>>> + triaxial acceleration sensor.
>>> +
>>> + To compile this driver as a
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron wrote:
> On 08/13/13 16:44, Oleksandr Kravchenko wrote:
>> This patch adds IIO driver for Bosch BMA180 triaxial
>> acceleration sensor.
>> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
>> Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
>>
>> Signed-off-by: Oleksandr Kravchenko
> Hi,
>
> Firstly, just a thought (I haven't made up my mind whether it is a good idea
> or
> not!) but you could use devm_kzalloc for data->buff and hence avoid having
> to care about freeing it in the remove function. Update scan mode isn't
> a particularly fast path so I doubt the small overhead will matter.
Thanks, it is a good idea.
>
> Otherwise, the abi additions need documenting iff they don't fit within
> existing ABI. If they do then they need to match existing ABI.
>
> Of those, 'mode' is rather device specific and could probably do with
> a more detailed name. The only 'generic' way to do it would be to make the
> channel type attributes writable and treat it as a resolution control rather
> than a noise/power trade off. Uggly though so perhaps what you have makes
> sense. We can always add a more generic way of controlling this if it
> starts turning up in lots of devices (keeping this method of course to avoid
> breaking ABI).
Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
>
> 'bandwidth' is already (I think) covered by the ABI. For the bandwidth
> optoins you have enabled we are talking low pass
> filters and presumably their 3db point.
> In Documentation/ABI/testing/sysfs-bus-iio you will find
> in_accel_filter_low_pass_3db_frequency. My filter theory is
> rather rusty (not sure it was
> every anything else ;). Hence I'm not entirely sure how to work
> out the 3db frequency from the 'pole frequency' if they are not infact
> the same thing..
You are right. In my case 'bandwidth' is low path filter. I'll change my driver
accordingly. But how can I declare available values?
If I do it in next way:
static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
BMA180_BW_AVAILABLE);
it will lock so ugly in the code and sysfs...
>
> Otherwise, the driver looks good to me.
>
> Jonathan
>> ---
>> .../devicetree/bindings/iio/accel/bma180.txt | 24 +
>> drivers/iio/accel/Kconfig | 12 +
>> drivers/iio/accel/Makefile |2 +
>> drivers/iio/accel/bma180.c | 689
>>
>> 4 files changed, 727 insertions(+)
>> create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
>> create mode 100644 drivers/iio/accel/bma180.c
>>
>> diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
>> b/Documentation/devicetree/bindings/iio/accel/bma180.txt
>> new file mode 100644
>> index 000..c593357
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
>> @@ -0,0 +1,24 @@
>> +* Bosch BMA180 triaxial acceleration sensor
>> +
>> +http://omapworld.com/BMA180_111_1002839.pdf
>> +
>> +Required properties:
>> +
>> + - compatible : should be "bosch,bma180"
>> + - reg : the I2C address of the sensor
>> +
>> +Optional properties:
>> +
>> + - interrupt-parent : should be the phandle for the interrupt controller
>> +
>> + - interrupts : interrupt mapping for GPIO IRQ, it should by configured
>> with
>> + flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
>> +
>> +Example:
>> +
>> +bma180@40 {
>> + compatible = "bosch,bma180";
>> + reg = <0x40>;
>> + interrupt-parent = <>;
>> + interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
>> +};
>> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
>> index 719d83f..bd9d581 100644
>> --- a/drivers/iio/accel/Kconfig
>> +++ b/drivers/iio/accel/Kconfig
>> @@ -3,6 +3,18 @@
>> #
>> menu "Accelerometers"
>>
>> +config BMA180
>> + tristate "Bosch BMA180 3-Axis Accelerometer Driver"
>> + depends on I2C
>> + select IIO_BUFFER
>> + select IIO_TRIGGERED_BUFFER
>> + help
>> + Say Y here if you want to build a driver for the Bosch BMA180
>> + triaxial acceleration sensor.
>> +
>> + To compile this driver as a module, choose M here: the
>> + module will be called bma180.
>> +
>> config HID_SENSOR_ACCEL_3D
>> depends on HID_SENSOR_HUB
>> select IIO_BUFFER
>> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
>> index 87d8fa2..eb09d72 100644
>> --- a/drivers/iio/accel/Makefile
>> +++ b/drivers/iio/accel/Makefile
>> @@ -2,6 +2,8 @@
>> # Makefile for industrial I/O accelerometer drivers
>> #
>>
>> +obj-$(CONFIG_BMA180) += bma180.o
>> +
>> obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>>
>> obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
>> diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
>> new file mode 100644
>> index 000..23c738f
>> --- /dev/null
>> +++ b/drivers/iio/accel/bma180.c
>> @@ -0,0
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
> This patch adds IIO driver for Bosch BMA180 triaxial
> acceleration sensor.
> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
> Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
>
> Signed-off-by: Oleksandr Kravchenko
Hi,
Firstly, just a thought (I haven't made up my mind whether it is a good idea or
not!) but you could use devm_kzalloc for data->buff and hence avoid having
to care about freeing it in the remove function. Update scan mode isn't
a particularly fast path so I doubt the small overhead will matter.
Otherwise, the abi additions need documenting iff they don't fit within
existing ABI. If they do then they need to match existing ABI.
Of those, 'mode' is rather device specific and could probably do with
a more detailed name. The only 'generic' way to do it would be to make the
channel type attributes writable and treat it as a resolution control rather
than a noise/power trade off. Uggly though so perhaps what you have makes
sense. We can always add a more generic way of controlling this if it
starts turning up in lots of devices (keeping this method of course to avoid
breaking ABI).
'bandwidth' is already (I think) covered by the ABI. For the bandwidth optoins
you have enabled we are talking low pass
filters and presumably their 3db point.
In Documentation/ABI/testing/sysfs-bus-iio you will find
in_accel_filter_low_pass_3db_frequency. My filter theory is
rather rusty (not sure it was
every anything else ;). Hence I'm not entirely sure how to work
out the 3db frequency from the 'pole frequency' if they are not infact
the same thing..
Otherwise, the driver looks good to me.
Jonathan
> ---
> .../devicetree/bindings/iio/accel/bma180.txt | 24 +
> drivers/iio/accel/Kconfig | 12 +
> drivers/iio/accel/Makefile |2 +
> drivers/iio/accel/bma180.c | 689
>
> 4 files changed, 727 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
> create mode 100644 drivers/iio/accel/bma180.c
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
> b/Documentation/devicetree/bindings/iio/accel/bma180.txt
> new file mode 100644
> index 000..c593357
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
> @@ -0,0 +1,24 @@
> +* Bosch BMA180 triaxial acceleration sensor
> +
> +http://omapworld.com/BMA180_111_1002839.pdf
> +
> +Required properties:
> +
> + - compatible : should be "bosch,bma180"
> + - reg : the I2C address of the sensor
> +
> +Optional properties:
> +
> + - interrupt-parent : should be the phandle for the interrupt controller
> +
> + - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
> + flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
> +
> +Example:
> +
> +bma180@40 {
> + compatible = "bosch,bma180";
> + reg = <0x40>;
> + interrupt-parent = <>;
> + interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
> +};
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 719d83f..bd9d581 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -3,6 +3,18 @@
> #
> menu "Accelerometers"
>
> +config BMA180
> + tristate "Bosch BMA180 3-Axis Accelerometer Driver"
> + depends on I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say Y here if you want to build a driver for the Bosch BMA180
> + triaxial acceleration sensor.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called bma180.
> +
> config HID_SENSOR_ACCEL_3D
> depends on HID_SENSOR_HUB
> select IIO_BUFFER
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 87d8fa2..eb09d72 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -2,6 +2,8 @@
> # Makefile for industrial I/O accelerometer drivers
> #
>
> +obj-$(CONFIG_BMA180) += bma180.o
> +
> obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>
> obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
> diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
> new file mode 100644
> index 000..23c738f
> --- /dev/null
> +++ b/drivers/iio/accel/bma180.c
> @@ -0,0 +1,689 @@
> +/*
> + * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
> + *
> + * Copyright 2013 Oleksandr Kravchenko
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License. See the file COPYING in the main
> + * directory of this archive for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BMA180_DRV_NAME "bma180"
> +#define BMA180_IRQ_NAME
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Signed-off-by: Oleksandr Kravchenko o.v.kravche...@globallogic.com
Hi,
Firstly, just a thought (I haven't made up my mind whether it is a good idea or
not!) but you could use devm_kzalloc for data-buff and hence avoid having
to care about freeing it in the remove function. Update scan mode isn't
a particularly fast path so I doubt the small overhead will matter.
Otherwise, the abi additions need documenting iff they don't fit within
existing ABI. If they do then they need to match existing ABI.
Of those, 'mode' is rather device specific and could probably do with
a more detailed name. The only 'generic' way to do it would be to make the
channel type attributes writable and treat it as a resolution control rather
than a noise/power trade off. Uggly though so perhaps what you have makes
sense. We can always add a more generic way of controlling this if it
starts turning up in lots of devices (keeping this method of course to avoid
breaking ABI).
'bandwidth' is already (I think) covered by the ABI. For the bandwidth optoins
you have enabled we are talking low pass
filters and presumably their 3db point.
In Documentation/ABI/testing/sysfs-bus-iio you will find
in_accel_filter_low_pass_3db_frequency. My filter theory is
rather rusty (not sure it was
every anything else ;). Hence I'm not entirely sure how to work
out the 3db frequency from the 'pole frequency' if they are not infact
the same thing..
Otherwise, the driver looks good to me.
Jonathan
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 689
4 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be bosch,bma180
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = bosch,bma180;
+ reg = 0x40;
+ interrupt-parent = gpio6;
+ interrupts = 18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING);
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu Accelerometers
+config BMA180
+ tristate Bosch BMA180 3-Axis Accelerometer Driver
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bma180.
+
config HID_SENSOR_ACCEL_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 87d8fa2..eb09d72 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -2,6 +2,8 @@
# Makefile for industrial I/O accelerometer drivers
#
+obj-$(CONFIG_BMA180) += bma180.o
+
obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
new file mode 100644
index 000..23c738f
--- /dev/null
+++ b/drivers/iio/accel/bma180.c
@@ -0,0 +1,689 @@
+/*
+ * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko x0199...@ti.com
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include linux/module.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/of.h
+#include linux/bitops.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+#include linux/iio/buffer.h
+#include linux/iio/trigger.h
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron ji...@kernel.org wrote:
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Signed-off-by: Oleksandr Kravchenko o.v.kravche...@globallogic.com
Hi,
Firstly, just a thought (I haven't made up my mind whether it is a good idea
or
not!) but you could use devm_kzalloc for data-buff and hence avoid having
to care about freeing it in the remove function. Update scan mode isn't
a particularly fast path so I doubt the small overhead will matter.
Thanks, it is a good idea.
Otherwise, the abi additions need documenting iff they don't fit within
existing ABI. If they do then they need to match existing ABI.
Of those, 'mode' is rather device specific and could probably do with
a more detailed name. The only 'generic' way to do it would be to make the
channel type attributes writable and treat it as a resolution control rather
than a noise/power trade off. Uggly though so perhaps what you have makes
sense. We can always add a more generic way of controlling this if it
starts turning up in lots of devices (keeping this method of course to avoid
breaking ABI).
Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
'bandwidth' is already (I think) covered by the ABI. For the bandwidth
optoins you have enabled we are talking low pass
filters and presumably their 3db point.
In Documentation/ABI/testing/sysfs-bus-iio you will find
in_accel_filter_low_pass_3db_frequency. My filter theory is
rather rusty (not sure it was
every anything else ;). Hence I'm not entirely sure how to work
out the 3db frequency from the 'pole frequency' if they are not infact
the same thing..
You are right. In my case 'bandwidth' is low path filter. I'll change my driver
accordingly. But how can I declare available values?
If I do it in next way:
static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
BMA180_BW_AVAILABLE);
it will lock so ugly in the code and sysfs...
Otherwise, the driver looks good to me.
Jonathan
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 689
4 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be bosch,bma180
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured
with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = bosch,bma180;
+ reg = 0x40;
+ interrupt-parent = gpio6;
+ interrupts = 18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING);
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu Accelerometers
+config BMA180
+ tristate Bosch BMA180 3-Axis Accelerometer Driver
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bma180.
+
config HID_SENSOR_ACCEL_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 87d8fa2..eb09d72 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -2,6 +2,8 @@
# Makefile for industrial I/O accelerometer drivers
#
+obj-$(CONFIG_BMA180) += bma180.o
+
obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
new file mode 100644
index 000..23c738f
--- /dev/null
+++ b/drivers/iio/accel/bma180.c
@@ -0,0 +1,689 @@
+/*
+ * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko x0199...@ti.com
+ *
+ * This file is
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/15/13 14:41, Oleksandr Kravchenko wrote:
On Thu, Aug 15, 2013 at 1:22 PM, Jonathan Cameron ji...@kernel.org wrote:
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Signed-off-by: Oleksandr Kravchenko o.v.kravche...@globallogic.com
Hi,
Firstly, just a thought (I haven't made up my mind whether it is a good idea
or
not!) but you could use devm_kzalloc for data-buff and hence avoid having
to care about freeing it in the remove function. Update scan mode isn't
a particularly fast path so I doubt the small overhead will matter.
Thanks, it is a good idea.
Otherwise, the abi additions need documenting iff they don't fit within
existing ABI. If they do then they need to match existing ABI.
Of those, 'mode' is rather device specific and could probably do with
a more detailed name. The only 'generic' way to do it would be to make the
channel type attributes writable and treat it as a resolution control rather
than a noise/power trade off. Uggly though so perhaps what you have makes
sense. We can always add a more generic way of controlling this if it
starts turning up in lots of devices (keeping this method of course to avoid
breaking ABI).
Ok, I'll change 'mode' to 'power_mode' and document it in ABI.
'bandwidth' is already (I think) covered by the ABI. For the bandwidth
optoins you have enabled we are talking low pass
filters and presumably their 3db point.
In Documentation/ABI/testing/sysfs-bus-iio you will find
in_accel_filter_low_pass_3db_frequency. My filter theory is
rather rusty (not sure it was
every anything else ;). Hence I'm not entirely sure how to work
out the 3db frequency from the 'pole frequency' if they are not infact
the same thing..
You are right. In my case 'bandwidth' is low path filter. I'll change my
driver
accordingly. But how can I declare available values?
If I do it in next way:
static IIO_CONST_ATTR(in_accel0_filter_low_pass_3db_frequency_available,
BMA180_BW_AVAILABLE);
Not shared across all channels? If it is then
in_accel_filter_low_pass_3db_frequency_available it is...
it will lock so ugly in the code and sysfs...
yeah. There are plans to clean that sort of thing up. I keep mentioning them
and never getting them done though.
In brief drivers will be able to provide and additional callback
which will then return pointers to arrays containing all the numbers to
specify the 'range' of values any parameter in info_mask can take
(note this includes the raw and processed values as well as the other bits).
I sketch out how we could do this from time to time and dont' quite get around
to
doing it.
Otherwise, the driver looks good to me.
Jonathan
---
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 689
4 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be bosch,bma180
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured
with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = bosch,bma180;
+ reg = 0x40;
+ interrupt-parent = gpio6;
+ interrupts = 18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING);
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu Accelerometers
+config BMA180
+ tristate Bosch BMA180 3-Axis Accelerometer Driver
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bma180.
+
config HID_SENSOR_ACCEL_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On Tue, Aug 13, 2013 at 9:28 PM, Jonathan Cameron wrote: > On 08/13/13 16:44, Oleksandr Kravchenko wrote: >> This patch adds IIO driver for Bosch BMA180 triaxial >> acceleration sensor. >> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/ >> Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf >> >> Signed-off-by: Oleksandr Kravchenko >> --- > To play the lazy / busy maintainer. What changed since v2? > > This is where that information should be. In general: fixed problem with possible not unlocked mutex in bma180_trigger_handler() and moved range, bandwidth and mode from devtree to sysfs attributes. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/13/2013 09:44 AM, Oleksandr Kravchenko wrote: > This patch adds IIO driver for Bosch BMA180 triaxial > acceleration sensor. > http://dlnmh9ip6v2uc.cloudfront.net/datasheets/ > Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf The binding document, Acked-by: Stephen Warren -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
> This patch adds IIO driver for Bosch BMA180 triaxial
> acceleration sensor.
> http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
> Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
>
> Signed-off-by: Oleksandr Kravchenko
> ---
To play the lazy / busy maintainer. What changed since v2?
This is where that information should be.
> .../devicetree/bindings/iio/accel/bma180.txt | 24 +
> drivers/iio/accel/Kconfig | 12 +
> drivers/iio/accel/Makefile |2 +
> drivers/iio/accel/bma180.c | 689
>
> 4 files changed, 727 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
> create mode 100644 drivers/iio/accel/bma180.c
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
> b/Documentation/devicetree/bindings/iio/accel/bma180.txt
> new file mode 100644
> index 000..c593357
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
> @@ -0,0 +1,24 @@
> +* Bosch BMA180 triaxial acceleration sensor
> +
> +http://omapworld.com/BMA180_111_1002839.pdf
> +
> +Required properties:
> +
> + - compatible : should be "bosch,bma180"
> + - reg : the I2C address of the sensor
> +
> +Optional properties:
> +
> + - interrupt-parent : should be the phandle for the interrupt controller
> +
> + - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
> + flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
> +
> +Example:
> +
> +bma180@40 {
> + compatible = "bosch,bma180";
> + reg = <0x40>;
> + interrupt-parent = <>;
> + interrupts = <18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING)>;
> +};
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index 719d83f..bd9d581 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -3,6 +3,18 @@
> #
> menu "Accelerometers"
>
> +config BMA180
> + tristate "Bosch BMA180 3-Axis Accelerometer Driver"
> + depends on I2C
> + select IIO_BUFFER
> + select IIO_TRIGGERED_BUFFER
> + help
> + Say Y here if you want to build a driver for the Bosch BMA180
> + triaxial acceleration sensor.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called bma180.
> +
> config HID_SENSOR_ACCEL_3D
> depends on HID_SENSOR_HUB
> select IIO_BUFFER
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 87d8fa2..eb09d72 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -2,6 +2,8 @@
> # Makefile for industrial I/O accelerometer drivers
> #
>
> +obj-$(CONFIG_BMA180) += bma180.o
> +
> obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
>
> obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
> diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
> new file mode 100644
> index 000..23c738f
> --- /dev/null
> +++ b/drivers/iio/accel/bma180.c
> @@ -0,0 +1,689 @@
> +/*
> + * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
> + *
> + * Copyright 2013 Oleksandr Kravchenko
> + *
> + * This file is subject to the terms and conditions of version 2 of
> + * the GNU General Public License. See the file COPYING in the main
> + * directory of this archive for more details.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define BMA180_DRV_NAME "bma180"
> +#define BMA180_IRQ_NAME "bma180_event"
> +
> +/* Register set */
> +#define BMA180_CHIP_ID 0x00 /* Need to distinguish BMA180 from
> other */
> +#define BMA180_ACC_X_LSB 0x02 /* First of 6 registers of accel data */
> +#define BMA180_CTRL_REG0 0x0d
> +#define BMA180_RESET 0x10
> +#define BMA180_BW_TCS0x20
> +#define BMA180_CTRL_REG3 0x21
> +#define BMA180_TCO_Z 0x30
> +#define BMA180_OFFSET_LSB1 0x35
> +
> +/* BMA180_CTRL_REG0 bits */
> +#define BMA180_DIS_WAKE_UP BIT(0) /* Disable wake up mode */
> +#define BMA180_SLEEP BIT(1) /* 1 - chip will sleep */
> +#define BMA180_EE_W BIT(4) /* Unlock writing to addr from 0x20 */
> +#define BMA180_RESET_INT BIT(6) /* Reset pending interrupts */
> +
> +/* BMA180_CTRL_REG3 bits */
> +#define BMA180_NEW_DATA_INT BIT(1) /* Intr every new accel data is ready */
> +
> +/* BMA180_OFFSET_LSB1 skipping mode bit */
> +#define BMA180_SMP_SKIP BIT(0)
> +
> +/* Bit masks for registers bit fields */
> +#define BMA180_RANGE 0x0e /* Range of measured accel values*/
> +#define BMA180_BW0xf0 /* Accel bandwidth */
> +#define BMA180_MODE_CONFIG 0x03 /* Config operation modes */
> +
> +/* We have to write this value in reset register to do soft reset */
> +#define
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/13/13 16:44, Oleksandr Kravchenko wrote:
This patch adds IIO driver for Bosch BMA180 triaxial
acceleration sensor.
http://dlnmh9ip6v2uc.cloudfront.net/datasheets/
Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf
Signed-off-by: Oleksandr Kravchenko o.v.kravche...@globallogic.com
---
To play the lazy / busy maintainer. What changed since v2?
This is where that information should be.
.../devicetree/bindings/iio/accel/bma180.txt | 24 +
drivers/iio/accel/Kconfig | 12 +
drivers/iio/accel/Makefile |2 +
drivers/iio/accel/bma180.c | 689
4 files changed, 727 insertions(+)
create mode 100644 Documentation/devicetree/bindings/iio/accel/bma180.txt
create mode 100644 drivers/iio/accel/bma180.c
diff --git a/Documentation/devicetree/bindings/iio/accel/bma180.txt
b/Documentation/devicetree/bindings/iio/accel/bma180.txt
new file mode 100644
index 000..c593357
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/accel/bma180.txt
@@ -0,0 +1,24 @@
+* Bosch BMA180 triaxial acceleration sensor
+
+http://omapworld.com/BMA180_111_1002839.pdf
+
+Required properties:
+
+ - compatible : should be bosch,bma180
+ - reg : the I2C address of the sensor
+
+Optional properties:
+
+ - interrupt-parent : should be the phandle for the interrupt controller
+
+ - interrupts : interrupt mapping for GPIO IRQ, it should by configured with
+ flags IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING
+
+Example:
+
+bma180@40 {
+ compatible = bosch,bma180;
+ reg = 0x40;
+ interrupt-parent = gpio6;
+ interrupts = 18 (IRQ_TYPE_LEVEL_HIGH | IRQ_TYPE_EDGE_RISING);
+};
diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
index 719d83f..bd9d581 100644
--- a/drivers/iio/accel/Kconfig
+++ b/drivers/iio/accel/Kconfig
@@ -3,6 +3,18 @@
#
menu Accelerometers
+config BMA180
+ tristate Bosch BMA180 3-Axis Accelerometer Driver
+ depends on I2C
+ select IIO_BUFFER
+ select IIO_TRIGGERED_BUFFER
+ help
+ Say Y here if you want to build a driver for the Bosch BMA180
+ triaxial acceleration sensor.
+
+ To compile this driver as a module, choose M here: the
+ module will be called bma180.
+
config HID_SENSOR_ACCEL_3D
depends on HID_SENSOR_HUB
select IIO_BUFFER
diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
index 87d8fa2..eb09d72 100644
--- a/drivers/iio/accel/Makefile
+++ b/drivers/iio/accel/Makefile
@@ -2,6 +2,8 @@
# Makefile for industrial I/O accelerometer drivers
#
+obj-$(CONFIG_BMA180) += bma180.o
+
obj-$(CONFIG_HID_SENSOR_ACCEL_3D) += hid-sensor-accel-3d.o
obj-$(CONFIG_IIO_ST_ACCEL_3AXIS) += st_accel.o
diff --git a/drivers/iio/accel/bma180.c b/drivers/iio/accel/bma180.c
new file mode 100644
index 000..23c738f
--- /dev/null
+++ b/drivers/iio/accel/bma180.c
@@ -0,0 +1,689 @@
+/*
+ * bma180.c - IIO driver for Bosch BMA180 triaxial acceleration sensor
+ *
+ * Copyright 2013 Oleksandr Kravchenko x0199...@ti.com
+ *
+ * This file is subject to the terms and conditions of version 2 of
+ * the GNU General Public License. See the file COPYING in the main
+ * directory of this archive for more details.
+ */
+
+#include linux/module.h
+#include linux/i2c.h
+#include linux/interrupt.h
+#include linux/delay.h
+#include linux/of.h
+#include linux/bitops.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/iio/iio.h
+#include linux/iio/sysfs.h
+#include linux/iio/buffer.h
+#include linux/iio/trigger.h
+#include linux/iio/trigger_consumer.h
+#include linux/iio/triggered_buffer.h
+
+#define BMA180_DRV_NAME bma180
+#define BMA180_IRQ_NAME bma180_event
+
+/* Register set */
+#define BMA180_CHIP_ID 0x00 /* Need to distinguish BMA180 from
other */
+#define BMA180_ACC_X_LSB 0x02 /* First of 6 registers of accel data */
+#define BMA180_CTRL_REG0 0x0d
+#define BMA180_RESET 0x10
+#define BMA180_BW_TCS0x20
+#define BMA180_CTRL_REG3 0x21
+#define BMA180_TCO_Z 0x30
+#define BMA180_OFFSET_LSB1 0x35
+
+/* BMA180_CTRL_REG0 bits */
+#define BMA180_DIS_WAKE_UP BIT(0) /* Disable wake up mode */
+#define BMA180_SLEEP BIT(1) /* 1 - chip will sleep */
+#define BMA180_EE_W BIT(4) /* Unlock writing to addr from 0x20 */
+#define BMA180_RESET_INT BIT(6) /* Reset pending interrupts */
+
+/* BMA180_CTRL_REG3 bits */
+#define BMA180_NEW_DATA_INT BIT(1) /* Intr every new accel data is ready */
+
+/* BMA180_OFFSET_LSB1 skipping mode bit */
+#define BMA180_SMP_SKIP BIT(0)
+
+/* Bit masks for registers bit fields */
+#define BMA180_RANGE 0x0e /* Range of measured accel values*/
+#define BMA180_BW0xf0 /* Accel bandwidth */
+#define BMA180_MODE_CONFIG 0x03 /*
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On 08/13/2013 09:44 AM, Oleksandr Kravchenko wrote: This patch adds IIO driver for Bosch BMA180 triaxial acceleration sensor. http://dlnmh9ip6v2uc.cloudfront.net/datasheets/ Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf The binding document, Acked-by: Stephen Warren swar...@nvidia.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] iio: add Bosch BMA180 acceleration sensor driver
On Tue, Aug 13, 2013 at 9:28 PM, Jonathan Cameron ji...@kernel.org wrote: On 08/13/13 16:44, Oleksandr Kravchenko wrote: This patch adds IIO driver for Bosch BMA180 triaxial acceleration sensor. http://dlnmh9ip6v2uc.cloudfront.net/datasheets/ Sensors/Accelerometers/BST-BMA180-DS000-07_2.pdf Signed-off-by: Oleksandr Kravchenko o.v.kravche...@globallogic.com --- To play the lazy / busy maintainer. What changed since v2? This is where that information should be. In general: fixed problem with possible not unlocked mutex in bma180_trigger_handler() and moved range, bandwidth and mode from devtree to sysfs attributes. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
