All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Matheus Tavares Bernardino <matheus.bernardino@usp.br>
Cc: Lars-Peter Clausen <lars@metafoo.de>,
	Michael Hennerich <Michael.Hennerich@analog.com>,
	Hartmut Knaack <knaack.h@gmx.de>,
	Peter Meerwald-Stadler <pmeerw@pmeerw.net>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-iio@vger.kernel.org, devel@driverdev.osuosl.org,
	linux-kernel@vger.kernel.org, kernel-usp@googlegroups.com,
	Victor Colombo <victorcolombo@gmail.com>
Subject: Re: [PATCH v2 5/6] staging:iio:ad2s90: Add IIO_CHAN_INFO_SCALE to channel spec and read_raw
Date: Sat, 3 Nov 2018 17:26:06 +0000	[thread overview]
Message-ID: <20181103172606.364fc1b0@archlinux> (raw)
In-Reply-To: <CAHd-oW4wki7am70DHFWb0GjOCtptRYRfAO2BG=32=YBBeAyASg@mail.gmail.com>

On Sat, 3 Nov 2018 13:04:04 -0300
Matheus Tavares Bernardino <matheus.bernardino@usp.br> wrote:

> On Sun, Oct 28, 2018 at 1:50 PM Jonathan Cameron <jic23@kernel.org> wrote:
> >
> > On Fri, 26 Oct 2018 23:00:04 -0300
> > Matheus Tavares <matheus.bernardino@usp.br> wrote:
> >  
> > > This patch adds the IIO_CHAN_INFO_SCALE mask to ad2s90_chan and
> > > implements the relative read behavior at ad2s90_read_raw.
> > >
> > > Signed-off-by: Victor Colombo <victorcolombo@gmail.com>
> > > Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br>  
> >
> > Hi,
> >
> > A suggestion inline.  This is a common case that we have infrastructure
> > to simplify.  + I think your scale factor is very slightly wrong.
> >
> > Jonathan
> >  
> > > ---
> > >  drivers/staging/iio/resolver/ad2s90.c | 32 ++++++++++++++++++---------
> > >  1 file changed, 22 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/staging/iio/resolver/ad2s90.c b/drivers/staging/iio/resolver/ad2s90.c
> > > index b4a6a89c11b0..52b656875ed1 100644
> > > --- a/drivers/staging/iio/resolver/ad2s90.c
> > > +++ b/drivers/staging/iio/resolver/ad2s90.c
> > > @@ -34,19 +34,31 @@ static int ad2s90_read_raw(struct iio_dev *indio_dev,
> > >       int ret;
> > >       struct ad2s90_state *st = iio_priv(indio_dev);
> > >
> > > -     mutex_lock(&st->lock);
> > > +     switch (m) {
> > > +     case IIO_CHAN_INFO_SCALE:
> > > +             /* 2 * Pi / (2^12 - 1) ~= 0.001534355 */
> > > +             *val = 0;
> > > +             *val2 = 1534355;  
> > Definitely 2^12 - 1?  That's a bit unusual if true as it would imply
> > that 2^12 - 1 and 0 were the same value.
> >
> > Imagine a smaller version with on 2^2 bits so 0, 1, 2, 3
> > Values of each are
> >
> > 0, M_PI/2, M_PI, 3*M_PI/2
> >
> > So the multiplier is 2*M_PI/(2^2) not 2*M_PI/(2^2 - 1)
> > 1/2 vs 2/3 * M_PI  
> 
> Oh, that makes a lot of sense! We used 2^12 - 1 here based on driver
> drivers/iio/resolver/ad2s1200.c, whose resolution is also 12 bits, as
> the ad2s90.c. Do you think this section is, perhaps, wrong on
> ad2s1200.c too, or maybe there is some difference between these two
> drivers that I didn't catch regarding the resolution?
Certainly seems likely to be wrong.  Difference is tiny so no one
probably ever noticed :(

Feel free to post a patch fixing that one as well!

Thanks,

Jonathan

> 
> Matheus.
> 
> > Now this is a very common case so we have the return type
> > IIO_VAL_FRACTIONAL_LOG2 to give a more obvious and potentially
> > more accurate representation.
> >  
> > > +             return IIO_VAL_INT_PLUS_NANO;
> > > +     case IIO_CHAN_INFO_RAW:
> > > +             mutex_lock(&st->lock);
> > > +
> > > +             ret = spi_read(st->sdev, st->rx, 2);
> > > +             if (ret < 0) {
> > > +                     mutex_unlock(&st->lock);
> > > +                     return ret;
> > > +             }
> > > +
> > > +             *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >> 4);
> > >
> > > -     ret = spi_read(st->sdev, st->rx, 2);
> > > -     if (ret < 0) {
> > >               mutex_unlock(&st->lock);
> > > -             return ret;
> > > -     }
> > >
> > > -     *val = (((u16)(st->rx[0])) << 4) | ((st->rx[1] & 0xF0) >> 4);
> > > -
> > > -     mutex_unlock(&st->lock);
> > > +             return IIO_VAL_INT;
> > > +     default:
> > > +             break;
> > > +     }
> > >
> > > -     return IIO_VAL_INT;
> > > +     return -EINVAL;
> > >  }
> > >
> > >  static const struct iio_info ad2s90_info = {
> > > @@ -57,7 +69,7 @@ static const struct iio_chan_spec ad2s90_chan = {
> > >       .type = IIO_ANGL,
> > >       .indexed = 1,
> > >       .channel = 0,
> > > -     .info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
> > > +     .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
> > >  };
> > >
> > >  static int ad2s90_probe(struct spi_device *spi)  
> >  


  reply	other threads:[~2018-11-03 17:26 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-27  1:59 [PATCH v2 0/6] staging:iio:ad2s90: Add scale info and improve error handling Matheus Tavares
2018-10-27  2:00 ` [PATCH v2 1/6] staging:iio:ad2s90: Make read_raw return spi_read's error code Matheus Tavares
2018-10-28 16:40   ` Jonathan Cameron
2018-11-02 13:49     ` Matheus Tavares
2018-11-03 10:41       ` Jonathan Cameron
2018-11-03 10:41         ` Jonathan Cameron
2018-10-27  2:00 ` [PATCH v2 2/6] staging:iio:ad2s90: Make probe handle spi_setup failure Matheus Tavares
2018-10-28 16:43   ` Jonathan Cameron
2018-11-02 13:59     ` Matheus Tavares
2018-11-03 10:45       ` Jonathan Cameron
2018-10-27  2:00 ` [PATCH v2 3/6] staging:iio:ad2s90: Remove always overwritten assignment Matheus Tavares
2018-10-27  2:00 ` [PATCH v2 4/6] staging:iio:ad2s90: Move device registration to the end of probe Matheus Tavares
2018-10-27  2:00 ` [PATCH v2 5/6] staging:iio:ad2s90: Add IIO_CHAN_INFO_SCALE to channel spec and read_raw Matheus Tavares
2018-10-28 16:50   ` Jonathan Cameron
2018-11-03 16:04     ` Matheus Tavares Bernardino
2018-11-03 17:26       ` Jonathan Cameron [this message]
2018-10-27  2:00 ` [PATCH v2 6/6] staging:iio:ad2s90: Check channel type at read_raw Matheus Tavares
2018-10-28 16:52 ` [PATCH v2 0/6] staging:iio:ad2s90: Add scale info and improve error handling Jonathan Cameron
2018-10-30 16:57   ` Matheus Tavares Bernardino

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181103172606.364fc1b0@archlinux \
    --to=jic23@kernel.org \
    --cc=Michael.Hennerich@analog.com \
    --cc=devel@driverdev.osuosl.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-usp@googlegroups.com \
    --cc=knaack.h@gmx.de \
    --cc=lars@metafoo.de \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matheus.bernardino@usp.br \
    --cc=pmeerw@pmeerw.net \
    --cc=victorcolombo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.