Acked-by: Denis Ciocca
-Original Message-
From: linux-iio-ow...@vger.kernel.org On
Behalf Of Mario Tesi
Sent: Monday, January 14, 2019 9:24 AM
To: ji...@kernel.org
Cc: linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Mario TESI
Subject: [PATCH] iio:st_pressure:initial
Hi Jian,
Not clear to me why should be + instead of *.
ODR is expressed in Hz, so (1/Hz) = period in seconds (1 sample sampling time)
[s]
1000 * (1/Hz) = period in milliseconds (1 sample sampling time) [ms]
n * 1000 * (1/Hz) = n times period in milliseconds (n times sample sampling
time) [ms]
Hi Leonard,
On |19 Apr 16 @ 12:53|, Crestez Dan Leonard wrote:
> On 04/19/2016 08:10 AM, Lucas De Marchi wrote:
> > On Mon, Apr 18, 2016 at 4:51 PM, Jonathan Cameron wrote:
> >> On 18/04/16 11:25, Crestez Dan Leonard wrote:
> >>> On 04/18/2016 09:07 AM, Denis Cioc
Hi Lucas,
yup. Just need to add the lsm9ds0_gyro entry in the same table of l3gd20.
Thanks,
Denis
On |19 Apr 16 @ 07:10|, Lucas De Marchi wrote:
> On Mon, Apr 18, 2016 at 4:51 PM, Jonathan Cameron wrote:
> > On 18/04/16 11:25, Crestez Dan Leonard wrote:
> >> On 04/18/20
Hi Leonard and Jonathan,
basically the patch can not work.
Current ST infrastructure needs to use one i2c slave per driver (accel or magn
or gyro).
All sensors currently supported (including lsm303agr) have one i2c address per
sensor type (for example in lsm303agr, accel has one i2c address, mag
Hi Arnd,
yup, my fault. Thanks.
Acked-by: Denis Ciocca
On |29 Mar 16 @ 22:27|, Arnd Bergmann wrote:
> When CONFIG_IIO_TRIGGER is enabled but CONFIG_IIO_BUFFER is
> not, we get a build error in the st_magn driver:
>
> drivers/iio/magnetometer/st_magn_core.c:5
Hi Alban,
after several months I'm finally back. I already did this patch, but I
had no time to submit. Thanks to your support it is ok for me!
We need to propagate also the patch to fix previous kernel versions...
Acked-by: Denis Ciocca
Denis
On 04/20/2015 07:57 PM, Alban Bedel
>> I've tried with real device...Unfortunately, you are right for name on
>> the package...
>> So, are you using the LSM303DLHC?
> According to my datasheet [1], I have the LSM303DLH.
>
> [1]
> http://www.calao-systems.com/repository/pub/EMBEDDED%20COMPUTERS/SKY-S9500-ULP-XXX/C12-SDK/SCH-00103-B11
Hi Lee,
> The driver mentions that the first group of sensors have a WAI of
> 0x3c: #define ST_MAGN_1_WAI_EXP 0x3c And when I print out the WAI read
> from the device: Requested device: lsm303dlh_magn - read WAI: 0x3c I
> guess I could have been lied to again by the board's datasheet again
> a
Hi Lee,
> That's what the datasheet for the board says. Perhaps it's that that's
> incorrect? Annoyingly, instead of printing the device name on the
> package, ST put some non-Googleable nonsense is there instead
> (probably the serial number). Nevertheless, I'll revert the patch and
> work so
Hi Lee,
> index 12e7e79..b2e2917 100644
> --- a/drivers/iio/magnetometer/st_magn_core.c
> +++ b/drivers/iio/magnetometer/st_magn_core.c
> @@ -151,7 +151,8 @@ static const struct st_sensors st_magn_sensors[] = {
> .wai = ST_MAGN_1_WAI_EXP,
> .sensors_supported = {
>
Hi Lars,
> On 09/14/2013 02:27 PM, Jonathan Cameron wrote:
>> On 09/14/13 13:14, Jonathan Cameron wrote:
>>> On 09/10/13 13:49, Lee Jones wrote:
Some of ST's sensors are appended with their sensor type and some
are not. For consistency we're extending the same naming convention
throu
Hi Lee,
>> On 09/10/13 13:49, Lee Jones wrote:
>>> The LSM303DLH's WAI (WhoAmI) is 0x33, meaning it should be enabled by
>>> Accel Sensor group one. For the device to probe without error, we'll
>>> need to ensure it's registered with the correct WAI.
>>>
>>> Signed-off-by: Lee Jones
>> You clearly
Lee, I got your point. For me is ok...
Denis
> On Thu, 05 Sep 2013, Denis CIOCCA wrote:
>
>>>>> Due to the MACRO used, the task of reading, understanding and maintaining
>>>>> the LPS331AP's channel descriptor is substantially difficult. This patch
>&
>>> Due to the MACRO used, the task of reading, understanding and maintaining
>>> the LPS331AP's channel descriptor is substantially difficult. This patch
>>> is based on the view that it's better to have easy to read, maintainable
>>> code than to save a few lines here and there. For that reason
Hi Lee,
> They're currently named *_1_*, for 'Sensor 1', but the code will be much
> more readable if we use the naming convention *_LPS331AP_* instead.
You are right, but the reason is to maintain the same structure of the
other sensors drivers (like accel, gyro and magn). Often some sensors
can
Acked-by: Denis Ciocca
> At the moment the number of channels specified is dictated by the first
> sensor supported by the driver. As we add support for more sensors this
> is likely to vary. Instead of using the ARRAY_SIZE() of the LPS331AP's
> channel specifier we'll use a
Acked-by: Denis Ciocca
> Some chips either don't support it or fail to provide adequate documentation,
> so sometimes it's impossible to enable the feature even if it is supported.
>
> Signed-off-by: Lee Jones
> ---
> drivers/iio/common/st_sensors/st_sensors_core.c
> Due to the MACRO used, the task of reading, understanding and maintaining
> the LPS331AP's channel descriptor is substantially difficult. This patch
> is based on the view that it's better to have easy to read, maintainable
> code than to save a few lines here and there. For that reason we're
> e
Hi Paul,
Acked-by: Denis Ciocca
Thanks,
Denis
On Tuesday, May 14, 2013 11:05:50 AM Paul Bolle wrote:
> Drivers for STMicroelectronics accelerometers, gyroscopes, and
> magnetometers were added in v3.9. They all have a (similar) select
> statement in their Kconfig files for a non
20 matches
Mail list logo
