[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <0680EC522D0CC943BC586913CF3768C003B360338A@dbde02.ent.ti.com>
Date: Fri, 2 Jul 2010 16:23:40 +0530
From: "Datta, Shubhrajyoti" <shubhrajyoti@...com>
To: Jonathan Cameron <jic23@....ac.uk>
CC: "linux-iio@...r.kernel.org" <linux-iio@...r.kernel.org>,
"sfking@...dc.com" <sfking@...dc.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [RFC] [PATCH] digital compass hmc5843
>
> <snip>
> >
> > I think that having a Hz as units will have its own issues. First the
> decimal implementation. However I am open to the implementation.
> > Also do you know of a driver that takes care of this.
> None of the current drivers go below 1Hz so not quite the same.
> lis3l02dq (accelerometer) does the match against a list, but it
> is done numerically rather than via string matches as would be needed
> here.
> >
> >>
> >> static IIO_CONST_ATTR_SAMP_FREQ_AVAIL("0.5 1 2 5 10 20 50");
> >>
> >>
> >> Then strncmp with the options to set the value up. The rounding
> approach
> >> gets tricky with a non integer value so probably easier to only allow
> >> these
> >> values.
What is a recommended way of getting a double or float
Is there any Strict_srttod etc.
> >
> > Allowing only this value will result in default/ reject case and will
> keep the previous value, may confuse the application
> Then the application is ignoring the interface spec that says it must read
> _available files if they are there.
> This way the rounding behaviour is left to userspace and what the
> application prefers rather
> than in kernel actually making it the most flexible option.
Agree
> >
> >>
> >>> +static IIO_DEV_ATTR_AVAIL_SAMP_FREQ(show_avail_samp_freq);
> >>> +
> >>> +static s32 hmc5843_set_rate(struct i2c_client *client,
> >>> + u8 rate)
> >>> +{
> >>> + struct hmc5843_data *data = i2c_get_clientdata(client);
> >>> + u8 reg_val;
> >>> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists