Re: [PATCH v3 4/5] iio: imu: st_lsm6dsx: add support for accel/gyro unit of lsm9sd1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On Sun, 28 Jul 2019 08:04:51 +0200
> Martin Kepplinger <martin.kepplinger@xxxxxxx> wrote:
> 
> > On 27.07.19 19:48, Jonathan Cameron wrote:
> > > On Thu, 25 Jul 2019 07:31:31 +0200
> > > Martin Kepplinger <martin.kepplinger@xxxxxxx> wrote:
> > >   
> > >> The LSM9DS1's accelerometer / gyroscope unit and it's magnetometer (separately
> > >> supported in iio/magnetometer/st_magn*) are located on a separate i2c addresses
> > >> on the bus.
> > >>
> > >> For the datasheet, see https://www.st.com/resource/en/datasheet/lsm9ds1.pdf
> > >>
> > >> Treat it just like the LSM6* devices and, despite it's name, hook it up
> > >> to the st_lsm6dsx driver, using it's basic functionality.
> > >>
> > >> Signed-off-by: Martin Kepplinger <martin.kepplinger@xxxxxxx>  
> > > I'm a little confused on this hardware.
> > > 
> > > How does buffered output work if these are independently clocked?
> > > 
> > > I took a quick look at the datasheet, and 'suspect' the answer is that
> > > it runs at the gyro frequencies if both are enable. Is that right?
> > >   
> > 
> > Thanks for reviewing, Jonathan,
> > 
> > Correct. It says so in chapter 7.12. But that's a "problem" with all
> > these imu devices, not specific to this addition right?
> It's not a problem as such, but there is a related difference in this
> device to the others supported by this driver.
> 
> The other parts seem to allow for independent data rate setting, with
> streaming to the buffer that isn't in 'lock step'.  I.e you can get
> 
> Ax_1, Ay_1, Az_1, Gx_1, Gy_1, Gz_1, Gx_2, Gy_2, Gz_2, Ax_2, Ay_2, Az_2, Gy_3...

correct

> 
> That required us to split them up into two devices and means that, to fuse
> data from these two source, userspace has to do the harder job of
> aligning the two datasets.
> 
> For this device, things are simpler in that you always a 'scan' that goes
> across both accelerometer and gyroscope channels.  That allows us to
> represent it as a single IIO device with a single buffer.
> 
> I'm not seeing any reference in the lsm9ds1 to the pattern registers
> that are used to handle difference in frequency for the other
> parts by letting us know what is actually present in each data set
> in the fifo.
> 
> Now, that doesn't meant we can't still handle them separately given
> we already do that for other parts.

what about reusing st_lsm6dsx_read_fifo() for lsm6ds0/lsm9ds1 but setting hw->sip to:
- hw->sip = 1 (acc_sip = 1, gyro_sip = 0) when just the acc is enabled
- hw->sip = 2 (acc_sip = 1, gyro_sip = 1) when both devices are enabled

I guess it is just a matter of adding a 'bool fixed_pattern' in
st_lsm6dsx_settings. What do you think?

Regards,
Lorenzo

> 
> Anyhow, is my understanding correct?
> 
> Jonathan
> 
> > 
> > Sidenote: I thought about renaming things to "lsm6ds0" here just because
> > of the name and because the registers are (almost) the same as for my
> > lsm9ds1. But I'm not a fan of blindly doing that without being able to
> > test. When the current patchset looks good to you, let's keep it that way.
> > 
> >                             martin
> 

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]


  Powered by Linux