On 5/11/2012 8:43 AM, Jonathan Cameron wrote:
On 5/11/2012 8:41 AM, Michael Hennerich wrote:
On 05/10/2012 02:36 PM, Jonathan Cameron wrote:
On 5/8/2012 4:34 PM, Michael Hennerich wrote:
On 05/08/2012 04:51 PM, Jonathan Cameron wrote:
On 5/7/2012 2:49 PM, michael.hennerich@xxxxxxxxxx wrote:
From: Michael Hennerich<michael.hennerich@xxxxxxxxxx>
+
+static const struct iio_chan_spec_ext_info adf4350_ext_info[] = {
+ /* Ideally we use IIO_CHAN_INFO_FREQUENCY, but there are
+ * values> 2^32 in order to support the entire frequency range
+ * in Hz. Using scale is a bit ugly.
+ */
hmm.. Add IIO_VAL_MEGA_PLUS_INT.. We were always going to need a
bigger
version at somepoint...
Well - we then need an s64, however read|write_raw feature s32 for
val and val2. So shall we pass low word in val and high word in val2?
I was thinking
val*1e6 + val2 would fit with what we have done elsewhere? Is that
enough room?
Hi Jonathan,
IIO_VAL_MEGA_PLUS_INT versus IIO_VAL_LONG_LONG
It is enough room. But I wonder why we would do costly divide and
modulus operations, when we can do sifts and ANDs? Splitting a s64 would
give is the maximum available room with very little overhead.
human readability. I'm anti breaking that if we can possibly avoid it.
That an consistency with the others. There it makes sense because of
breaking round the decimal point.
Thoughts?
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-iio" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
