Re: [PATCH v4 3/3] iio: magnetometer: Add driver support for PNI RM3100

[Song Qiang]

On 2018/11/2 äå5:24, Jonathan Cameron wrote:
> On Fri, 2 Nov 2018 15:55:27 +0800
> Song Qiang <songqiang1304521@xxxxxxxxx> wrote:
>
> > On 2018/10/21 äå10:14, Jonathan Cameron wrote:
> > > On Thu, 18 Oct 2018 16:24:15 +0800
> > > Song Qiang <songqiang1304521@xxxxxxxxx> wrote:
> > >
> > > ...
> > > > > > +static irqreturn_t rm3100_trigger_handler(int irq, void *p)
> > > > > > +{
> > > > > > +	struct iio_poll_func *pf = p;
> > > > > > +	struct iio_dev *indio_dev = pf->indio_dev;
> > > > > > +	unsigned long scan_mask = *indio_dev->active_scan_mask;
> > > > > > +	unsigned int mask_len = indio_dev->masklength;
> > > > > > +	struct rm3100_data *data = iio_priv(indio_dev);
> > > > > > +	struct regmap *regmap = data->regmap;
> > > > > > +	int ret, i, bit;
> > > > > > +
> > > > > > +	mutex_lock(&data->lock);
> > > > > > +	switch (scan_mask) {
> > > > > > +	case BIT(0) | BIT(1) | BIT(2):
> > > > > > +		ret = regmap_bulk_read(regmap, RM3100_REG_MX2, data->buffer, 9);
> > > > > > +		mutex_unlock(&data->lock);
> > > > > > +		if (ret < 0)
> > > > > > +			goto done;
> > > > > > +	break;
> > > > > > +	case BIT(0) | BIT(1):
> > > > > > +		ret = regmap_bulk_read(regmap, RM3100_REG_MX2, data->buffer, 6);
> > > > > > +		mutex_unlock(&data->lock);
> > > > > > +		if (ret < 0)
> > > > > > +			goto done;
> > > > > > +	break;
> > > > > > +	case BIT(1) | BIT(2):
> > > > > > +		ret = regmap_bulk_read(regmap, RM3100_REG_MY2, data->buffer, 6);
> > > > > > +		mutex_unlock(&data->lock);
> > > > > > +		if (ret < 0)
> > > > > > +			goto done;
> > > > > > +	break;
> > > > > What about BIT(0) | BIT(2)?
> > > > >
> > > > > Now you can do it like you have here and on that one corner case let the iio core
> > > > > demux code take care of it, but then you will need to provide available_scan_masks
> > > > > so the core knows it needs to handle this case.
> > > > >      
> > > > This confused me a little. The available_scan_masks I was using is {BIT(0) |
> > > > BIT(1) | BIT(2), 0x0}. Apparently in this version of patch I would like it to
> > > > handle every circumstances like BIT(0), BIT(0) | BIT(2), BIT(1) | BIT(2), etc.
> > > > Since Phil mentioned he would like this to reduce bus usage as much as we can
> > > > and I want it, too, I think these three circumstances can be read consecutively
> > > > while others can be read one axis at a time. So I plan to let BIT(0) | BIT(2)
> > > > fall into the 'default' section, which reads axis one by one.
> > > >
> > > > My question is, since this handles every possible combination, do I still need
> > > > to list every available scan masks in available_scan_masks?
> > > Ah. I see, I'd missed that the default was picking up that case as well as the
> > > single axes.   It would be interesting to sanity check if it is quicker on
> > > a 'typical' platform to do the all axis read for the BIT(0) | BIT(2) case
> > > and drop the middle value (which would be done using available scan_masks)
> > > or to just do two independent reads.
> > >
> > > (I would guess it is worth reading the 'dead' axis).
> > >   
> > > > All other problems will be fixed in the next patch.
> > > >
> > > > yours,
> > > >
> > > > Song Qiang
> > > >
> > > >
> > > > ...
> > > Thanks,
> > >
> > > Jonathan
> > I tested this two ways of getting data with the following code snippet:
> >
> >
> >   ÂÂÂ u8 buffer[9];
> >   ÂÂÂ struct timeval timebefore, timeafter;
> >
> >   ÂÂÂ do_gettimeofday(&timebefore);
> >   ÂÂÂ ret = regmap_bulk_read(regmap, RM3100_REG_MX2, buffer, 9);
> >   ÂÂÂ if (ret < 0)
> >   ÂÂÂ ÂÂÂ goto unlock_return;
> >   ÂÂÂ do_gettimeofday(&timeafter);
> >   ÂÂÂ printk(KERN_INFO "read with dead axis time: %ld",
> >   ÂÂÂ ÂÂÂÂÂÂ timeafter.tv_sec * 1000000 + timeafter.tv_usec -
> >   ÂÂÂ ÂÂÂÂÂÂ timebefore.tv_sec * 1000000 - timebefore.tv_usec);
> >   ÂÂÂ do_gettimeofday(&timebefore);
> >
> >   ÂÂÂ ret = regmap_bulk_read(regmap, RM3100_REG_MX2, buffer, 3);
> >   ÂÂÂ if (ret < 0)
> >   ÂÂÂ ÂÂÂ goto unlock_return;
> >   ÂÂÂ ret = regmap_bulk_read(regmap, RM3100_REG_MZ2, buffer + 6, 3);
> >   ÂÂÂ if (ret < 0)
> >   ÂÂÂ ÂÂÂ goto unlock_return;
> >   ÂÂÂ do_gettimeofday(&timeafter);
> >   ÂÂÂ printk(KERN_INFO "read two single axis time: %ld",
> >   ÂÂÂ ÂÂÂÂÂÂ timeafter.tv_sec * 1000000 + timeafter.tv_usec -
> >   ÂÂÂ ÂÂÂÂÂÂ timebefore.tv_sec * 1000000 - timebefore.tv_usec);
> >
> >
> > And get this result:
> >
> > [Â 161.264777] read with dead axis time: 883
> > [Â 161.270621] read two single axis time: 1359
> > [Â 161.575134] read with dead axis time: 852
> > [Â 161.580973] read two single axis time: 1356
> > [Â 161.895704] read with dead axis time: 854
> > [Â 161.903744] read two single axis time: 3540
> > [Â 162.223600] read with dead axis time: 853
> > [Â 162.229451] read two single axis time: 1363
> > [Â 162.591227] read with dead axis time: 850
> > [Â 162.597630] read two single axis time: 1555
> > [Â 162.920102] read with dead axis time: 852
> > [Â 162.926467] read two single axis time: 1534
> > [Â 163.303121] read with dead axis time: 881
> > [Â 163.308997] read two single axis time: 1390
> > [Â 163.711004] read with dead axis time: 861
> >
> >
> > It seems like you're right! Reading consecutively 9 bytes does save a lot time
> > compared to read 3 bytes twice.
> I've done this stuff before ;)  We had this on the adis16365 parts back
> in the early days of IIO.  A worse case as it has a lot more channels,
> but otherwise similar from what I recall.
>
> It would be an interesting exercise to trace those paths and find out the
> balance between real hardware stuff we can't change and potential software
> overheads.
>
> Chances are this is mostly 'real' stuff though but would be great to
> confirm this. It's been on my list of things to do for years (not on
> this driver obviously but in general)...
>
> Jonathan
I think I can try to use ftrace to trace it's flow path on my platform. I don't 
familiar with it, may need some time.

yours,

Song Qiang